diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index c2b2ea6034054848d62d00db3dc610ee8c0a04e8..85195fb76f92887f97eb72a358f23f13daa3ff97 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,9 @@
+2008-05-21  Paolo Carlini  <paolo.carlini@oracle.com>
+
+	* doc/html/ext/lwg-active.html: Update to Revision R56.
+	* doc/html/ext/lwg-closed.html: Likewise.
+	* doc/html/ext/lwg-defects.html: Likewise.
+
 2008-05-20  Paolo Carlini  <paolo.carlini@oracle.com>
 
 	PR c++/33979 (partial)
diff --git a/libstdc++-v3/doc/html/ext/lwg-active.html b/libstdc++-v3/doc/html/ext/lwg-active.html
index 29e0d775bf303607ceb2a40836af74d6e0386052..27e0ed263e44b0f8b9aad478f2f34060155791d3 100644
--- a/libstdc++-v3/doc/html/ext/lwg-active.html
+++ b/libstdc++-v3/doc/html/ext/lwg-active.html
@@ -12,11 +12,11 @@ del {background-color:#FFA0A0}
 <table>
 <tbody><tr>
 <td align="left">Doc. no.</td>
-<td align="left">N2456=07-0326</td>
+<td align="left">N2612=08-0122</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">2007-10-20</td>
+<td align="left">2008-05-18</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -27,7 +27,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 R52)</h1>
+<h1>C++ Standard Library Active Issues List (Revision R56)</h1>
 
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
@@ -94,6 +94,89 @@ del {background-color:#FFA0A0}
 
 <h2>Revision History</h2>
 <ul>
+<li>R56: 
+2008-05-16 pre-Sophia Antipolis mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>191 open issues, up by 24.</li>
+<li>647 closed issues, up by 1.</li>
+<li>838 issues total, up by 25.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="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>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>
+</li>
+<li>R55: 
+2008-03-14 post-Bellevue mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>167 open issues, down by 39.</li>
+<li>646 closed issues, up by 65.</li>
+<li>813 issues total, up by 26.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
+<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>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>
+<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</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-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</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#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
+<li>Changed the following issues from 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 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 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 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>
+<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R54: 
+2008-02-01 pre-Bellevue mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>206 open issues, up by 23.</li>
+<li>581 closed issues, up by 0.</li>
+<li>787 issues total, up by 23.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="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>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>
+<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</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#527">527</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R53: 
+2007-12-09 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>183 open issues, up by 11.</li>
+<li>581 closed issues, down by 1.</li>
+<li>764 issues total, up by 10.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="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>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>
+</ul>
+</li>
 <li>R52: 
 2007-10-19 post-Kona mailing.
 <ul>
@@ -103,16 +186,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-active.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-active.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.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-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>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-active.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-active.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-active.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-active.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-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 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-active.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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 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 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 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>
@@ -128,7 +211,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-active.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-active.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-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>
 </ul></li>
 </ul>
 </li>
@@ -141,13 +224,13 @@ del {background-color:#FFA0A0}
 <li>708 issues total, up by 12.</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#697">697</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-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</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-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</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-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</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#528">528</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#637">637</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#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</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#525">525</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#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-active.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-active.html#680">680</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 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>
@@ -168,7 +251,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-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-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 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>
@@ -185,12 +268,12 @@ 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-active.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-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-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>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-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Changed the following issues from 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>
 <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li>
-<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
+<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</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-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
 <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
 <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>
@@ -212,11 +295,11 @@ del {background-color:#FFA0A0}
 <li>656 issues total, up by 37.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#626">626</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-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 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 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-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
+<li>Changed the following issues from 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>
 </ul></li>
 </ul>
@@ -246,7 +329,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-active.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-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#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>
@@ -290,9 +373,9 @@ del {background-color:#FFA0A0}
 <li>574 issues total, up by 8.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
@@ -323,7 +406,7 @@ del {background-color:#FFA0A0}
 <li>535 issues total.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
 </ul></li>
 </ul>
 </li>
@@ -368,12 +451,12 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#
 <li>R31: 
 2004-07 mid-term mailing: reflects new proposed resolutions and
 new issues received after the post-Sydney mailing.  Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
+new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
 </li>
 <li>R30: 
 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 Voted all "Ready" issues from R29 into the working paper.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>.
 </li>
 <li>R29: 
 Pre-Sydney mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
@@ -518,7 +601,7 @@ of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3
 <li>R10: 
 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a> to
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 </li>
 <li>R9: 
@@ -537,7 +620,7 @@ pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
 </li>
 <li>R6: 
-pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
+pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>,
 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 </li>
 <li>R5: 
@@ -869,7 +952,7 @@ is assigned to <i>err</i>.</ins>
 
 <hr>
 <h3><a name="96"></a>96. Vector&lt;bool&gt; is not a container</h3>
-<p><b>Section:</b> 23.2.5 [vector] <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.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
@@ -964,6 +1047,172 @@ users who want to continue using a bit-packed container.  Alan and Beman to work
 
 
 
+<hr>
+<h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string&nbsp; buffers</h3>
+<p><b>Section:</b> 27.7 [string.streams], 27.8 [file.streams] <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> 1999-02-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>The following question came from Thorsten Herlemann:</p>
+
+<blockquote>
+  <p>You can set a mode when constructing or opening a file-stream or
+  filebuf, e.g.  ios::in, ios::out, ios::binary, ... But how can I get
+  that mode later on, e.g. in my own operator &lt;&lt; or operator
+  &gt;&gt; or when I want to check whether a file-stream or
+  file-buffer object passed as parameter is opened for input or output
+  or binary? Is there no possibility? Is this a design-error in the
+  standard C++ library? </p>
+</blockquote>
+
+<p>It is indeed impossible to find out what a stream's or stream
+buffer's open mode is, and without that knowledge you don't know
+how certain operations behave. Just think of the append mode. </p>
+
+<p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
+current open mode setting. </p>
+
+<p><i>[
+post Bellevue:  Alisdair requested to re-Open.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>For stream buffers, add a function to the base class as a non-virtual function
+qualified as const to 27.5.2 [streambuf]:</p>
+
+<p>&nbsp;&nbsp;&nbsp;&nbsp;<tt>openmode mode() const</tt>;</p>
+
+<p><b>&nbsp;&nbsp;&nbsp; Returns</b> the current open mode.</p>
+
+<p>With streams, I'm not sure what to suggest. In principle, the mode
+could already be returned by <tt>ios_base</tt>, but the mode is only
+initialized for file and string stream objects, unless I'm overlooking
+anything. For this reason it should be added to the most derived
+stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
+and would be default initialized in <tt>basic_ios&lt;&gt;::init()</tt>.</p>
+
+
+<p><b>Rationale:</b></p>
+<p>This might be an interesting extension for some future, but it is
+not a defect in the current standard. The Proposed Resolution is
+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>
+ <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>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
+constness of the iterators. The iterators only serve to give
+positioning information.</p>
+
+<p>Here's a simple and typical example problem which is currently very
+difficult or impossible to solve without the change proposed
+below.</p>
+
+<p>Wrap a standard container C in a class W which allows clients to
+find and read (but not modify) a subrange of (C.begin(), C.end()]. The
+only modification clients are allowed to make to elements in this
+subrange is to erase them from C through the use of a member function
+of W.</p>
+
+<p><i>[
+post Bellevue, Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+This issue was implemented by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>
+for everything but <tt>basic_string</tt>.
+</p>
+
+<p>
+Note that the specific example in this issue (<tt>basic_string</tt>) is the one place
+we forgot to amend in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>,
+so we might open this issue for that
+single container?
+</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>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>
+</p>
+
+
+<p><b>Rationale:</b></p>
+<p>The issue was discussed at length. It was generally agreed that 1)
+There is no major technical argument against the change (although
+there is a minor argument that some obscure programs may break), and
+2) Such a change would not break const correctness. The concerns about
+making the change were 1) it is user detectable (although only in
+boundary cases), 2) it changes a large number of signatures, and 3) it
+seems more of a design issue that an out-and-out defect.</p>
+
+<p>The LWG believes that this issue should be considered as part of a
+general review of const issues for the next revision of the
+standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>
+
+
+
+
+<hr>
+<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>
+<p>Both std::min and std::max are defined as template functions.  This
+is very different than the definition of std::plus (and similar
+structs) which are defined as function objects which inherit
+std::binary_function.<br>
+<br>
+        This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
+a function object that inherits std::binary_function.</p>
+
+<p><i>[
+post Bellevue:  Alisdair requested to re-Open.
+]</i></p>
+
+
+
+
+<p><b>Rationale:</b></p>
+<p>Although perhaps an unfortunate design decision, the omission is not a defect
+in the current standard.&nbsp; A future standard may wish to consider additional
+function objects.</p>
+
+
+
+
 <hr>
 <h3><a name="255"></a>255. Why do <tt>basic_streambuf&lt;&gt;::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
 <p><b>Section:</b> 27.5.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
@@ -1210,7 +1459,6 @@ with a return type of convertible to <tt>T</tt> and operational semantics of
 <h3><a name="309"></a>309. Does sentry catch exceptions?</h3>
 <p><b>Section:</b> 27.6 [iostream.format] <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> 2001-03-19</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iostream.format">active issues</a> in [iostream.format].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -1759,6 +2007,19 @@ think that there are cases such as some of those above where it would
 be desirable to allow implementations to include only as much as
 necessary and not more.</p>
 
+<p><i>[
+post Bellevue:
+]</i></p>
+
+
+<blockquote>
+Position taken in prior reviews is that the idea of a table of header
+dependencies is a good one. Our view is that a full paper is needed to
+do justice to this, and we've made that recommendation to the issue
+author.
+</blockquote>
+
+
 
 <p><b>Proposed resolution:</b></p>
 <p>
@@ -1982,10 +2243,10 @@ partial can only occur if (from_next != from_end)?
 
 <hr>
 <h3><a name="387"></a>387. std::complex over-encapsulated</h3>
-<p><b>Section:</b> 26.3 [complex.numbers] <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.3 [complex.numbers] <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> 2002-11-08</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 The absence of explicit description of std::complex&lt;T&gt; layout
@@ -2027,9 +2288,9 @@ of std::complex&lt;&gt; is not justified.
 <ul>
 <li>the expression reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)
 is well-formed; and</li>
-<li>reinterpret_cast&lt;cvT(&amp;)[2]&gt;(z)[0]designates the
+<li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[0]designates the
 real part of z; and</li>
-<li>reinterpret_cast&lt;cvT(&amp;)[2]&gt;(z)[1]designates the
+<li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[1]designates the
 imaginary part of z.</li>
 </ul>
 
@@ -2040,45 +2301,47 @@ i then:
 </p>
 
 <ul>
-<li>reinterpret_cast&lt;cvT*&gt;(a)[2+i] designates the real
+<li>reinterpret_cast&lt;cv T*&gt;(a)[2*i] designates the real
 part of a[i]; and</li>
-<li>reinterpret_cast&lt;cv T*&gt;(a)[2+i+1] designates the
+<li>reinterpret_cast&lt;cv T*&gt;(a)[2*i+1] designates the
 imaginary part of a[i].</li>
 </ul>
 </blockquote>
 
-<p>In the header synopsis in 26.3.1 [complex.synopsis], replace</p>
-<pre>  template&lt;class T&gt; T real(const complex&lt;T&gt;&amp;);
-  template&lt;class T&gt; T imag(const complex&lt;T&gt;&amp;);
-</pre>
+<p>
+In 26.3.2 [complex] Add the member functions
+</p>
 
-<p>with</p>
+<blockquote><pre>void real(T);
+void imag(T);
+</pre></blockquote>
 
-<pre>  template&lt;class T&gt; const T&amp; real(const complex&lt;T&gt;&amp;);
-  template&lt;class T&gt;       T&amp; real(      complex&lt;T&gt;&amp;);
-  template&lt;class T&gt; const T&amp; imag(const complex&lt;T&gt;&amp;);
-  template&lt;class T&gt;       T&amp; imag(      complex&lt;T&gt;&amp;);
-</pre>
+<p>
+Add to 26.3.4 [complex.members]
+</p>
 
-<p>In 26.3.7 [complex.value.ops] paragraph 1, change</p>
-<pre>  template&lt;class T&gt; T real(const complex&lt;T&gt;&amp;);
+<blockquote>
+<pre>T real() const;
 </pre>
-<p>to</p>
-<pre>  template&lt;class T&gt; const T&amp; real(const complex&lt;T&gt;&amp;);
-  template&lt;class T&gt;       T&amp; real(      complex&lt;T&gt;&amp;);
+<blockquote>
+<i>Returns:</i> the value of the real component
+</blockquote>
+<pre>void real(T val);
 </pre>
-<p>and change the <b>Returns</b> clause to "<b>Returns:</b> The real
-part of <i>x</i>.</p>
-
-<p>In 26.3.7 [complex.value.ops] paragraph 2, change</p>
-<pre>  template&lt;class T&gt; T imag(const complex&lt;T&gt;&amp;);
+<blockquote>
+Assigns val to the real component.
+</blockquote>
+<pre>T imag() const;
 </pre>
-<p>to</p>
-<pre>  template&lt;class T&gt; const T&amp; imag(const complex&lt;T&gt;&amp;);
-  template&lt;class T&gt;       T&amp; imag(      complex&lt;T&gt;&amp;);
+<blockquote>
+<i>Returns:</i> the value of the imaginary component
+</blockquote>
+<pre>void imag(T val);
 </pre>
-<p>and change the <b>Returns</b> clause to "<b>Returns:</b> The imaginary
-part of <i>x</i>.</p>
+<blockquote>
+Assigns val to the imaginary component.
+</blockquote>
+</blockquote>
 
 <p><i>[Kona: The layout guarantee is absolutely necessary for C
   compatibility.  However, there was disagreement about the other part
@@ -2095,6 +2358,14 @@ part of <i>x</i>.</p>
 <p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>
 
 
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Second half of proposed wording replaced and moved to Ready.
+</blockquote>
 
 
 <p><b>Rationale:</b></p>
@@ -2215,6 +2486,7 @@ functions should be changed as proposed below.
 <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>
  <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>Discussion:</b></p>
@@ -2305,6 +2577,15 @@ is <i>zero</i>. Otherwise, the element has the value 1.</p>
 
 
 
+<p><i>[
+post Bellevue:
+]</i></p>
+
+
+<blockquote>
+We are happy with the resolution as proposed, and we move this to Ready.
+</blockquote>
+
 
 
 
@@ -2348,7 +2629,7 @@ sentry::~sentry() should internally catch any exceptions it might cause.
 
 
 <p><i>[
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a> for related issues.
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues.
 ]</i></p>
 
 
@@ -2661,7 +2942,7 @@ object throws.
 
 
 <p><i>[
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a> for related issues.
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues.
 ]</i></p>
 
 
@@ -3023,88 +3304,6 @@ ostream::write().
 
 
 
-<hr>
-<h3><a name="424"></a>424. normative notes</h3>
-<p><b>Section:</b> 17.3.1.1 [structure.summary] <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> 2003-09-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-The text in 17.3.1.1, p1 says:
-<br>
-
-"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
-paragraphs are normative."
-<br>
-
-The library section makes heavy use of paragraphs labeled "Notes(s),"
-some of which are clearly intended to be normative (see list 1), while
-some others are not (see list 2). There are also those where the intent
-is not so clear (see list 3).
-<br><br>
-
-List 1 -- Examples of (presumably) normative Notes:
-<br>
-
-20.6.1.1 [allocator.members], p3,<br>
-20.6.1.1 [allocator.members], p10,<br>
-21.3.2 [string.cons], p11,<br>
-22.1.1.2 [locale.cons], p11,<br>
-23.2.2.3 [deque.modifiers], p2,<br>
-25.3.7 [alg.min.max], p3,<br>
-26.3.6 [complex.ops], p15,<br>
-27.5.2.4.3 [streambuf.virt.get], p7.<br>
-<br>
-
-List 2 -- Examples of (presumably) informative Notes:
-<br>
-
-18.5.1.3 [new.delete.placement], p3,<br>
-21.3.6.6 [string::replace], p14,<br>
-22.2.1.4.2 [locale.codecvt.virtuals], p3,<br>
-25.1.1 [alg.foreach], p4,<br>
-26.3.5 [complex.member.ops], p1,<br>
-27.4.2.5 [ios.base.storage], p6.<br>
-<br>
-
-List 3 -- Examples of Notes that are not clearly either normative
-or informative:
-<br>
-
-22.1.1.2 [locale.cons], p8,<br>
-22.1.1.5 [locale.statics], p6,<br>
-27.5.2.4.5 [streambuf.virt.put], p4.<br>
-<br>
-
-None of these lists is meant to be exhaustive.
-</p>
-
-<p><i>[Definitely a real problem.  The big problem is there's material
-  that doesn't quite fit any of the named paragraph categories
-  (e.g. <b>Effects</b>).  Either we need a new kind of named
-  paragraph, or we need to put more material in unnamed paragraphs
-  jsut after the signature.  We need to talk to the Project Editor
-  about how to do this.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p><i>[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks".
-Fixed as editorial.  This change has been in the WD since the post-Redmond mailing, in 2004.
-Recommend NAD.]</i></p>
-
-<p><i>[
-Batavia:  We feel that the references in List 2 above should be changed from <i>Remarks</i>
-to <i>Notes</i>.  We also feel that those items in List 3 need to be double checked for
-the same change.  Alan and Pete to review.
-]</i></p>
-
-
-
-
-
 <hr>
 <h3><a name="427"></a>427. stage 2 and rationale of DR 221</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>
@@ -3184,65 +3383,212 @@ object (e.g., slice (2, 1, 1) for a valarray of size 1).
   need wording to express this decision.]</i></p>
 
 
+<p><i>[
+Bellevue:
+]</i></p>
+
 
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+Please note that the standard also fails to specify the behavior of
+slice_array and gslice_array in the valid case. Bill Plauger will
+endeavor to provide revised wording for slice_array and gslice_array.
+</blockquote>
 
+<p><i>[
+post-Bellevue:  Bill provided wording.
+]</i></p>
 
 
 
-<hr>
-<h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-09-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations
-  are permitted to supply containers that are unable to cope with
-  allocator instances and that container implementations may assume
-  that all instances of an allocator type compare equal.  We gave
-  implementers this latitude as a temporary hack, and eventually we
-  want to get rid of it.  What happens when we're dealing with
-  allocators that <i>don't</i> compare equal?
+<p><b>Proposed resolution:</b></p>
+<p>
+Insert after 26.5.2.4 [valarray.sub], paragraph 1:
 </p>
 
-<p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
-  objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
-  <tt>v1.get_allocator() != v2.get_allocator()</tt>.  What happens if
-  we write <tt>v1.swap(v2)</tt>?  Informally, three possibilities:</p>
+<blockquote>
+<p>
+The member operator is overloaded to provide several ways to select
+sequences
+of elements from among those controlled by <tt>*this</tt>. The first group of five
+member operators work in conjunction with various overloads of <tt>operator=</tt>
+(and other assigning operators) to allow selective replacement (slicing) of
+the controlled sequence. The selected elements must exist.
+</p>
+<p>
+The first member operator selects element off. For example:
+</p>
 
-<p>1. This operation is illegal.  Perhaps we could say that an
-  implementation is required to check and to throw an exception, or
-  perhaps we could say it's undefined behavior.</p>
-<p>2. The operation performs a slow swap (i.e. using three
-  invocations of <tt>operator=</tt>, leaving each allocator with its
-  original container.  This would be an O(N) operation.</p>
-<p>3. The operation swaps both the vectors' contents and their
-  allocators.  This would be an O(1) operation. That is:</p>
-  <blockquote>
-  <pre>    my_alloc a1(...);
-    my_alloc a2(...);
-    assert(a1 != a2);
+<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
+v0[3] = 'A';
+// v0 == valarray&lt;char&gt;("abcAefghijklmnop", 16)
+</pre></blockquote>
 
-    vector&lt;int, my_alloc&gt; v1(a1);
-    vector&lt;int, my_alloc&gt; v2(a2);
-    assert(a1 == v1.get_allocator());
-    assert(a2 == v2.get_allocator());
+<p>
+The second member operator selects those elements of the controlled sequence
+designated by <tt>slicearr</tt>. For example:
+</p>
 
-    v1.swap(v2);
-    assert(a1 == v2.get_allocator());
-    assert(a2 == v1.get_allocator());
-  </pre>
-  </blockquote>
+<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
+valarray&lt;char&gt; v1("ABCDE", 5);
+v0[slice(2, 5, 3)] = v1;
+// v0 == valarray&lt;char&gt;("abAdeBghCjkDmnEp", 16)
+</pre></blockquote>
 
-<p><i>[Kona: This is part of a general problem.  We need a paper
-  saying how to deal with unequal allocators in general.]</i></p>
+<p>
+The third member operator selects those elements of the controlled sequence
+designated by <tt>gslicearr</tt>. For example:
+</p>
 
+<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
+valarray&lt;char&gt; v1("ABCDEF", 6);
+const size_t lv[] = {2, 3};
+const size_t dv[] = {7, 2};
+const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2);
+v0[gslice(3, len, str)] = v1;
+// v0 == valarray&lt;char&gt;("abcAeBgCijDlEnFp", 16)
+</pre></blockquote>
 
-<p><i>[pre-Sydney: Howard argues for option 3 in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
-]</i></p>
+<p>
+The fourth member operator selects those elements of the controlled sequence
+designated by <tt>boolarr</tt>. For example:
+</p>
+
+<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
+valarray&lt;char&gt; v1("ABC", 3);
+const bool vb[] = {false, false, true, true, false, true};
+v0[valarray&lt;bool&gt;(vb, 6)] = v1;
+// v0 == valarray&lt;char&gt;("abABeCghijklmnop", 16)
+</pre></blockquote>
+
+<p>
+The fifth member operator selects those elements of the controlled sequence
+designated by indarr. For example:
+</p>
+
+<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
+valarray&lt;char&gt; v1("ABCDE", 5);
+const size_t vi[] = {7, 5, 2, 3, 8};
+v0[valarray&lt;size_t&gt;(vi, 5)] = v1;
+// v0 == valarray&lt;char&gt;("abCDeBgAEjklmnop", 16)
+</pre></blockquote>
+
+<p>
+The second group of five member operators each construct an object that
+represents the value(s) selected. The selected elements must exist.
+</p>
+
+<p>
+The sixth member operator returns the value of element off. For example:
+</p>
+
+<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
+// v0[3] returns 'd'
+</pre></blockquote>
+
+<p>
+The seventh member operator returns an object of class <tt>valarray&lt;Ty&gt;</tt>
+containing those elements of the controlled sequence designated by <tt>slicearr</tt>.
+For example:
+</p>
+
+<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
+// v0[slice(2, 5, 3)] returns valarray&lt;char&gt;("cfilo", 5)
+</pre></blockquote>
+
+<p>
+The eighth member operator selects those elements of the controlled sequence
+designated by <tt>gslicearr</tt>. For example:
+</p>
+
+<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
+const size_t lv[] = {2, 3};
+const size_t dv[] = {7, 2};
+const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2);
+// v0[gslice(3, len, str)] returns
+// &nbsp;&nbsp;&nbsp;valarray&lt;char&gt;("dfhkmo", 6)
+</pre></blockquote>
+
+<p>
+The ninth member operator selects those elements of the controlled sequence
+designated by <tt>boolarr</tt>. For example:
+</p>
+
+<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
+const bool vb[] = {false, false, true, true, false, true};
+// v0[valarray&lt;bool&gt;(vb, 6)] returns
+// &nbsp;&nbsp;&nbsp;valarray&lt;char&gt;("cdf", 3)
+</pre></blockquote>
+
+<p>
+The last member operator selects those elements of the controlled sequence
+designated by <tt>indarr</tt>. For example:
+</p>
+
+<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
+const size_t vi[] = {7, 5, 2, 3, 8};
+// v0[valarray&lt;size_t&gt;(vi, 5)] returns
+//    valarray&lt;char&gt;("hfcdi", 5)
+</pre></blockquote>
+
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
+<p><b>Section:</b> 20.1.2 [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-09-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations
+  are permitted to supply containers that are unable to cope with
+  allocator instances and that container implementations may assume
+  that all instances of an allocator type compare equal.  We gave
+  implementers this latitude as a temporary hack, and eventually we
+  want to get rid of it.  What happens when we're dealing with
+  allocators that <i>don't</i> compare equal?
+</p>
+
+<p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
+  objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
+  <tt>v1.get_allocator() != v2.get_allocator()</tt>.  What happens if
+  we write <tt>v1.swap(v2)</tt>?  Informally, three possibilities:</p>
+
+<p>1. This operation is illegal.  Perhaps we could say that an
+  implementation is required to check and to throw an exception, or
+  perhaps we could say it's undefined behavior.</p>
+<p>2. The operation performs a slow swap (i.e. using three
+  invocations of <tt>operator=</tt>, leaving each allocator with its
+  original container.  This would be an O(N) operation.</p>
+<p>3. The operation swaps both the vectors' contents and their
+  allocators.  This would be an O(1) operation. That is:</p>
+  <blockquote>
+  <pre>    my_alloc a1(...);
+    my_alloc a2(...);
+    assert(a1 != a2);
+
+    vector&lt;int, my_alloc&gt; v1(a1);
+    vector&lt;int, my_alloc&gt; v2(a2);
+    assert(a1 == v1.get_allocator());
+    assert(a2 == v2.get_allocator());
+
+    v1.swap(v2);
+    assert(a1 == v2.get_allocator());
+    assert(a2 == v1.get_allocator());
+  </pre>
+  </blockquote>
+
+<p><i>[Kona: This is part of a general problem.  We need a paper
+  saying how to deal with unequal allocators in general.]</i></p>
+
+
+<p><i>[pre-Sydney: Howard argues for option 3 in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
+]</i></p>
 
 
 <p><i>[
@@ -3312,6 +3658,7 @@ reachability.
 <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>
 <p><b>Discussion:</b></p>
 <pre>    basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
 </pre>
@@ -3421,6 +3768,33 @@ std::basic_string? (3) We might want to wait until we see Beman's
 filesystem library; we might decide that it obviates this.]</i></p>
 
 
+<p><i>[
+post Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Move again to Ready.
+</p>
+<p>
+There is a timing issue here. Since the filesystem library will not be
+in C++0x, this should be brought forward. This solution would remain
+valid in the context of the proposed filesystem.
+</p>
+<p>
+This issue has been kicking around for a while, and the wchar_t addition
+alone would help many users. Thus, we suggest putting this on the
+reflector list with an invitation for someone to produce proposed
+wording that covers basic_fstream. In the meantime, we suggest that the
+proposed wording be adopted as-is.
+</p>
+<p>
+If more of the Lillehammer questions come back, they should be
+introduced as separate issues.
+</p>
+</blockquote>
+
 
 
 
@@ -3563,236 +3937,523 @@ technique to perform the comparison:</p>
 
 
 <hr>
-<h3><a name="462"></a>462. Destroying objects with static storage duration</h3>
-<p><b>Section:</b> 3.6.3 [basic.start.term], 18.3 [cstdint] <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-03-23</p>
+<h3><a name="463"></a>463. auto_ptr usability issues</h3>
+<p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
+
 <p>
-3.6.3 Termination spells out in detail the interleaving of static
-destructor calls and calls to functions registered with atexit. To
-match this behavior requires intimate cooperation between the code
-that calls destructors and the exit/atexit machinery. The former
-is tied tightly to the compiler; the latter is a primitive mechanism
-inherited from C that traditionally has nothing to do with static
-construction and destruction. The benefits of intermixing destructor
-calls with atexit handler calls is questionable at best, and <i>very</i>
-difficult to get right, particularly when mixing third-party C++
-libraries with different third-party C++ compilers and C libraries
-supplied by still other parties.
+TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
+member of auto_ptr (20.4.5.3/4) obsolete.
 </p>
 
 <p>
-I believe the right thing to do is defer all static destruction
-until after all atexit handlers are called. This is a change in
-behavior, but one that is likely visible only to perverse test
-suites. At the very least, we should <i>permit</i> deferred destruction
-even if we don't require it.
+The sole purpose of this obsolete conversion member is to enable copy
+initialization base from r-value derived (or any convertible types like
+cv-types) case:
 </p>
+<pre>#include &lt;memory&gt;
+using std::auto_ptr;
 
-<p><i>[If this is to be changed, it should probably be changed by CWG.
-  At this point, however, the LWG is leaning toward NAD.  Implementing
-  what the standard says is hard work, but it's not impossible and
-  most vendors went through that pain years ago.  Changing this
-  behavior would be a user-visible change, and would break at least
-  one real application.]</i></p>
+struct B {};
+struct D : B {};
 
+auto_ptr&lt;D&gt; source();
+int sink(auto_ptr&lt;B&gt;);
+int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
+</pre>
 
-<p><i>[
-Batavia:  Send to core with our recommendation that we should permit deferred
-destruction but not require it.
-]</i></p>
+<p>
+The excellent analysis of conversion operations that was given in the final
+auto_ptr proposal
+(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
+explicitly specifies this case analysis (case 4). DR #84 makes the analysis
+wrong and actually comes to forbid the loophole that was exploited by the
+auto_ptr designers.
+</p>
 
+<p>
+I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
+ever allowed this case. This is probably because it requires 3 user defined
+conversions and in fact current compilers conform to DR #84.
+</p>
 
-<p><i>[
-Howard:  The course of action recommended in Batavia would undo LWG
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a> and break current code implementing the "phoenix
-singleton". Search the net for "phoenix singleton atexit" to get a feel
-for the size of the adverse impact this change would have.  Below is
-sample code which implements the phoenix singleton and would break if
-<tt>atexit</tt> is changed in this way:
-]</i></p>
+<p>
+I was surprised to discover that the obsolete conversion member actually has
+negative impact of the copy initialization base from l-value derived
+case:</p>
+<pre>auto_ptr&lt;D&gt; dp;
+int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
+</pre>
 
+<p>
+I'm sure that the original intention was allowing this initialization using
+the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; a) constructor (20.4.5.1/4) but
+since in this copy initialization it's merely user defined conversion (UDC)
+and the obsolete conversion member is UDC with the same rank (for the early
+overloading stage) there is an ambiguity between them.
+</p>
 
-<blockquote><pre>#include &lt;cstdlib&gt;
-#include &lt;iostream&gt;
-#include &lt;type_traits&gt;
-#include &lt;new&gt;
+<p>
+Removing the obsolete member will have impact on code that explicitly
+invokes it:
+</p>
+<pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
+</pre>
 
-class A
-{
-    bool alive_;
-    A(const A&amp;);
-    A&amp; operator=(const A&amp;);
-public:
-    A() : alive_(true) {std::cout &lt;&lt; "A()\n";}
-    ~A() {alive_ = false; std::cout &lt;&lt; "~A()\n";}
-    void use()
-    {
-        if (alive_)
-            std::cout &lt;&lt; "A is alive\n";
-        else
-            std::cout &lt;&lt; "A is dead\n";
-    }
-};
+<p>
+IMHO no one ever wrote such awkward code and the reasonable workaround for
+#1 is:
+</p>
+<pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
+</pre>
 
-void deallocate_resource();
+<p>
+I was even more surprised to find out that after removing the obsolete
+conversion member the initialization was still ill-formed:
+int x3 = sink(dp); // #3 EDG - no suitable copy constructor
+</p>
 
-// This is the phoenix singleton pattern
-A&amp; get_resource(bool create = true)
-{
-    static std::aligned_storage&lt;sizeof(A), std::alignment_of&lt;A&gt;::value&gt;::type buf;
-    static A* a;
-    if (create)
-    {
-        if (a != (A*)&amp;buf)
-        {
-            a = ::new (&amp;buf) A;
-            std::atexit(deallocate_resource);
-        }
-    }
-    else
-    {
-        a-&gt;~A();
-        a = (A*)&amp;buf + 1;
-    }
-    return *a;
-}
+<p>
+This copy initialization semantically requires copy constructor which means
+that both template conversion constructor and the auto_ptr_ref conversion
+member (20.4.5.3/3) are required which is what was explicitly forbidden in
+DR #84. This is a bit amusing case in which removing ambiguity results with
+no candidates.
+</p>
 
-void deallocate_resource()
-{
-    get_resource(false);
-}
+<p>
+I also found exception safety issue with auto_ptr related to auto_ptr_ref:
+</p>
+<pre>int f(auto_ptr&lt;B&gt;, std::string);
+auto_ptr&lt;B&gt; source2();
 
-void use_A(const char* message)
-{
-    A&amp; a = get_resource();
-    std::cout &lt;&lt; "Using A " &lt;&lt; message &lt;&lt; "\n";
-    a.use();
-}
+// string constructor throws while auto_ptr_ref
+// "holds" the pointer
+int x4 = f(source2(), "xyz"); // #4
+</pre>
 
-struct B
-{
-    ~B() {use_A("from ~B()");}
-};
+<p>
+The theoretic execution sequence that will cause a leak:
+</p>
+<ol>
+<li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
+<li>call string::string(char const*) and throw</li>
+</ol>
 
-B b;
+<p>
+According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
+returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
+the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
+library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; with Y* as member which
+is much more reasonable. Other vendor implemented auto_ptr_ref as
+defectively required and it results with awkward and catastrophic code:
+int oops = sink(auto_ptr&lt;B&gt;(source())); // warning recursive on all control
+paths
+</p>
 
-int main()
-{
-    use_A("from main()");
-}
-</pre></blockquote>
+<p>
+Dave Abrahams noticed that there is no specification saying that
+auto_ptr_ref copy constructor can't throw.
+</p>
 
 <p>
-The correct output is:
+My proposal comes to solve all the above issues and significantly simplify
+auto_ptr implementation. One of the fundamental requirements from auto_ptr
+is that it can be constructed in an intuitive manner (i.e. like ordinary
+pointers) but with strict ownership semantics which yield that source
+auto_ptr in initialization must be non-const. My idea is to add additional
+constructor template with sole propose to generate ill-formed, diagnostic
+required, instance for const auto_ptr arguments during instantiation of
+declaration. This special constructor will not be instantiated for other
+types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
+in hand makes the constructor template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
+legitimate since the actual argument can't be const yet non const r-value
+are acceptable.
 </p>
 
-<blockquote><pre>A()
-Using A from main()
-A is alive
-~A()
-A()
-Using A from ~B()
-A is alive
-~A()
-</pre></blockquote>
+<p>
+This implementation technique makes the "private auxiliary class"
+auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
+GCC and VC) consume the new implementation as expected and allow all
+intuitive initialization and assignment cases while rejecting illegal cases
+that involve const auto_ptr arguments.
+</p>
 
+<p>The proposed auto_ptr interface:</p>
 
+<pre>namespace std {
+    template&lt;class X&gt; class auto_ptr {
+    public:
+        typedef X element_type;
+
+        // 20.4.5.1 construct/copy/destroy:
+        explicit auto_ptr(X* p=0) throw();
+        auto_ptr(auto_ptr&amp;) throw();
+        template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
+        auto_ptr&amp; operator=(auto_ptr&amp;) throw();
+        template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
+        ~auto_ptr() throw();
+
+        // 20.4.5.2 members:
+        X&amp; operator*() const throw();
+        X* operator-&gt;() const throw();
+        X* get() const throw();
+        X* release() throw();
+        void reset(X* p=0) throw();
+
+    private:
+        template&lt;class U&gt;
+        auto_ptr(U&amp; rhs, typename
+unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
+    };
+}
+</pre>
 
-<p><b>Proposed resolution:</b></p>
 <p>
+One compliant technique to implement the unspecified_error_on_const_auto_ptr
+helper class is using additional private auto_ptr member class template like
+the following:
 </p>
+<pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
 
+template&lt;typename T&gt;
+struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
+{ typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
+</pre>
 
+<p>
+There are other techniques to implement this helper class that might work
+better for different compliers (i.e. better diagnostics) and therefore I
+suggest defining its semantic behavior without mandating any specific
+implementation. IMO, and I didn't found any compiler that thinks otherwise,
+14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
+verifying this with core language experts.
+</p>
 
+<p><b>Further changes in standard text:</b></p>
+<p>Remove section 20.4.5.3</p>
 
+<p>Change 20.4.5/2 to read something like:
+Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
+ill-formed declaration that will require unspecified diagnostic.</p>
 
-<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#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#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<p>Change 20.4.5.1/4,5,6 to read:</p>
 
-<p>[lib.exception] specifies the following:</p>
-<pre>    exception (const exception&amp;) throw();
-    exception&amp; operator= (const exception&amp;) throw();
+<pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
+<p> 4 Requires: Y* can be implicitly converted to X*.</p>
+<p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
+<p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
 
-    -4- Effects: Copies an exception object.
-    -5- Notes: The effects of calling what() after assignment
-        are implementation-defined.
+<p>Change 20.4.5.1/10</p>
+<pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
 </pre>
+<p>
+10 Requires: Y* can be implicitly converted to X*. The expression delete
+get() is well formed.
+</p>
+
+<p>LWG TC DR #127 is obsolete.</p>
 
 <p>
-First, does the Note only apply to the assignment operator? If so,
-what are the effects of calling what() on a copy of an object? Is
-the returned pointer supposed to point to an identical copy of
-the NTBS returned by what() called on the original object or not?
+Notice that the copy constructor and copy assignment operator should remain
+as before and accept non-const auto_ptr&amp; since they have effect on the form
+of the implicitly declared copy constructor and copy assignment operator of
+class that contains auto_ptr as member per 12.8/5,10:
 </p>
+<pre>struct X {
+    // implicit X(X&amp;)
+    // implicit X&amp; operator=(X&amp;)
+    auto_ptr&lt;D&gt; aptr_;
+};
+</pre>
 
 <p>
-Second, is this Note intended to extend to all the derived classes
-in section 19? I.e., does the standard provide any guarantee for
-the effects of what() called on a copy of any of the derived class
-described in section 19?
+In most cases this indicates about sloppy programming but preserves the
+current auto_ptr behavior.
 </p>
 
 <p>
-Finally, if the answer to the first question is no, I believe it
-constitutes a defect since throwing an exception object typically
-implies invoking the copy ctor on the object. If the answer is yes,
-then I believe the standard ought to be clarified to spell out
-exactly what the effects are on the copy (i.e., after the copy
-ctor was called).
+Dave Abrahams encouraged me to suggest fallback implementation in case that
+my suggestion that involves removing of auto_ptr_ref will not be accepted.
+In this case removing the obsolete conversion member to auto_ptr&lt;Y&gt; and
+20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
+cases. The two constructors that I suggested will co exist with the current
+members but will make auto_ptr_ref obsolete in initialization contexts.
+auto_ptr_ref will be effective in assignment contexts as suggested in DR
+#127 and I can't see any serious exception safety issues in those cases
+(although it's possible to synthesize such). auto_ptr_ref&lt;X&gt; semantics will
+have to be revised to say that it strictly holds pointer of type X and not
+reference to an auto_ptr for the favor of cases in which auto_ptr_ref&lt;Y&gt; is
+constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
+from r-value derived to base).
 </p>
 
-<p><i>[Redmond: Yes, this is fuzzy.  The issue of derived classes is
-  fuzzy too.]</i></p>
+<p><i>[Redmond: punt for the moment. We haven't decided yet whether we
+  want to fix auto_ptr for C++-0x, or remove it and replace it with
+  move_ptr and unique_ptr.]</i></p>
 
 
 <p><i>[
-Batavia: Howard provided wording.
+Oxford 2007: Recommend NAD.  We're just going to deprecate it.  It still works for simple use cases
+and people know how to deal with it.  Going forward <tt>unique_ptr</tt> is the recommended
+tool.
+]</i></p>
+
+
+<p><i>[
+2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
 ]</i></p>
 
 
 
 
 <p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in D.9.1 [auto.ptr]:
+</p>
+
+<blockquote><pre>namespace std { 
+  <del>template &lt;class Y&gt; struct auto_ptr_ref {};</del>
+
+  <ins>// exposition only</ins>
+  <ins>template &lt;class T&gt; struct constant_object;</ins>
+
+  <ins>// exposition only</ins>
+  <ins>template &lt;class T&gt;</ins>
+  <ins>struct cannot_transfer_ownership_from</ins>
+    <ins>: constant_object&lt;T&gt; {};</ins>
+
+  template &lt;class X&gt; class auto_ptr { 
+  public: 
+    typedef X element_type; 
+
+    // D.9.1.1 construct/copy/destroy: 
+    explicit auto_ptr(X* p =0) throw(); 
+    auto_ptr(auto_ptr&amp;) throw(); 
+    template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp;) throw(); 
+    auto_ptr&amp; operator=(auto_ptr&amp;) throw(); 
+    template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del>) throw();
+    <del>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</del>
+    ~auto_ptr() throw(); 
+
+    // D.9.1.2 members: 
+    X&amp; operator*() const throw();
+    X* operator-&gt;() const throw();
+    X* get() const throw();
+    X* release() throw();
+    void reset(X* p =0) throw();
+
+    <del>// D.9.1.3 conversions:</del>
+    <del>auto_ptr(auto_ptr_ref&lt;X&gt;) throw();</del>
+    <del>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() throw();</del>
+    <del>template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;() throw();</del>
+
+    <ins>// exposition only</ins>
+    <ins>template&lt;class U&gt;</ins>
+    <ins>auto_ptr(U&amp; rhs, typename cannot_transfer_ownership_from&lt;U&gt;::error = 0);</ins>
+  }; 
+
+  template &lt;&gt; class auto_ptr&lt;void&gt; 
+  { 
+  public: 
+    typedef void element_type; 
+  }; 
+
+}
+</pre></blockquote>
 
 <p>
-Change 18.7.1 [exception] to:
+Remove D.9.1.3 [auto.ptr.conv].
+</p>
+
+<p>
+Change D.9.1 [auto.ptr], p3:
 </p>
 
 <blockquote>
-<pre>exception(const exception&amp; <ins><i>e</i></ins>) throw();
-exception&amp; operator=(const exception&amp; <ins><i>e</i></ins>) throw();</pre>
-<blockquote>
+The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
+<tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an
+<tt>auto_ptr</tt> copies the pointer and transfers ownership to the
+destination. If more than one <tt>auto_ptr</tt> owns the same object at
+the same time the behavior of the program is undefined. <ins>Templates
+<tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>,
+and the final constructor of <tt>auto_ptr</tt> are for exposition only.
+For any types <tt>X</tt> and <tt>Y</tt>, initializing
+<tt>auto_ptr&lt;X&gt;</tt> from <tt>const auto_ptr&lt;Y&gt;</tt> is
+ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of
+<tt>auto_ptr</tt> include providing temporary exception-safety for
+dynamically allocated memory, passing ownership of dynamically allocated
+memory to a function, and returning dynamically allocated memory from a
+function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt>
+and <tt>Assignable</tt> requirements for Standard Library container
+elements and thus instantiating a Standard Library container with an
+<tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>]
+</blockquote>
+
 <p>
--4- <i>Effects:</i> Copies an exception object.
+Change D.9.1.1 [auto.ptr.cons], p5:
 </p>
+
+<blockquote>
+<pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp; a) throw();
+</pre>
+<blockquote>
 <p>
-<del> -5- <i>Remarks:</i> The effects of calling what() after assignment are implementation-defined.</del>
+<i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
 </p>
 <p>
-<ins>-5- <i>Throws:</i> Nothing.  This also applies
-to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
+<i>Effects:</i> Calls <ins><tt>const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(</tt></ins><tt>a</tt><ins><tt>)</tt></ins><tt>.release()</tt>.
 </p>
 <p>
-<ins>-7- <i>Postcondition:</i> <tt>strcmp(what(), <i>e</i>.what()) == 0</tt>.  This also applies
-to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
+<i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>.
 </p>
-
 </blockquote>
 </blockquote>
 
+<p>
+Change D.9.1.1 [auto.ptr.cons], p10:
+</p>
 
-
-
-<hr>
-<h3><a name="473"></a>473. underspecified ctype calls</h3>
-<p><b>Section:</b> 22.2.1.1 [locale.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<blockquote>
+<pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del> a) throw();
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
+The expression <tt>delete get()</tt> is well formed.
+</p>
+<p>
+<i>Effects:</i> Calls <tt>reset(a.release())</tt>.
+</p>
+<p>
+<i>Returns:</i> <tt>*this</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="471"></a>471. result of what() implementation-defined</h3>
+<p><b>Section:</b> 18.6.1 [type.info] <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> 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>Discussion:</b></p>
+
+<p>[lib.exception] specifies the following:</p>
+<pre>    exception (const exception&amp;) throw();
+    exception&amp; operator= (const exception&amp;) throw();
+
+    -4- Effects: Copies an exception object.
+    -5- Notes: The effects of calling what() after assignment
+        are implementation-defined.
+</pre>
+
+<p>
+First, does the Note only apply to the assignment operator? If so,
+what are the effects of calling what() on a copy of an object? Is
+the returned pointer supposed to point to an identical copy of
+the NTBS returned by what() called on the original object or not?
+</p>
+
+<p>
+Second, is this Note intended to extend to all the derived classes
+in section 19? I.e., does the standard provide any guarantee for
+the effects of what() called on a copy of any of the derived class
+described in section 19?
+</p>
+
+<p>
+Finally, if the answer to the first question is no, I believe it
+constitutes a defect since throwing an exception object typically
+implies invoking the copy ctor on the object. If the answer is yes,
+then I believe the standard ought to be clarified to spell out
+exactly what the effects are on the copy (i.e., after the copy
+ctor was called).
+</p>
+
+<p><i>[Redmond: Yes, this is fuzzy.  The issue of derived classes is
+  fuzzy too.]</i></p>
+
+
+<p><i>[
+Batavia: Howard provided wording.
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Eric concerned this is unimplementable, due to nothrow guarantees.
+Suggested implementation would involve reference counting.
+</p>
+<p>
+Is the implied reference counting subtle enough to call out a note on
+implementation? Probably not.
+</p>
+<p>
+If reference counting required, could we tighten specification further
+to require same pointer value? Probably an overspecification, especially
+if exception classes defer evalutation of final string to calls to
+what().
+</p>
+<p>
+Remember issue moved open and not resolved at Batavia, but cannot
+remember who objected to canvas a disenting opinion - please speak up if
+you disagree while reading these minutes!
+</p>
+<p>
+Move to Ready as we are accepting words unmodified.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change 18.7.1 [exception] to:
+</p>
+
+<blockquote>
+<pre>exception(const exception&amp; <ins><i>e</i></ins>) throw();
+exception&amp; operator=(const exception&amp; <ins><i>e</i></ins>) throw();</pre>
+<blockquote>
+<p>
+-4- <i>Effects:</i> Copies an exception object.
+</p>
+<p>
+<del> -5- <i>Remarks:</i> The effects of calling what() after assignment are implementation-defined.</del>
+</p>
+<p>
+<ins>-5- <i>Throws:</i> Nothing.  This also applies
+to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
+</p>
+<p>
+<ins>-7- <i>Postcondition:</i> <tt>strcmp(what(), <i>e</i>.what()) == 0</tt>.  This also applies
+to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
+</p>
+
+</blockquote>
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="473"></a>473. underspecified ctype calls</h3>
+<p><b>Section:</b> 22.2.1.1 [locale.ctype] <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-07-01</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -3980,6 +4641,7 @@ wording (I believe) x,a,b,c could be written to in any order.
 <h3><a name="492"></a>492. Invalid iterator arithmetic expressions</h3>
 <p><b>Section:</b> 23 [containers], 24 [iterators], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
  <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</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>
@@ -4142,6 +4804,16 @@ See DR 237. The resolution could then also read "Linear in last -
 first".
 </p>
 
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Keep open and ask Bill to provide wording.
+</blockquote>
+
+
 <p><b>Proposed resolution:</b></p>
 
 <p><i>[Lillehammer: Minor issue, but real. We have a blanket statement
@@ -4388,11 +5060,10 @@ 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#Review">Review</a>
+<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 other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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>
 Issue 371 deals with stability of multiset/multimap under insert and erase
@@ -4459,6 +5130,8 @@ preserves the relative ordering of equivalent elements.</ins></p>
 <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>
  <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>Discussion:</b></p>
 <p>
@@ -4477,10 +5150,80 @@ Toronto: Howard to provide wording (really this time).
 ]</i></p>
 
 
+<p><i>[
+Bellevue:  Alisdair provided wording.
+]</i></p>
+
+
 
 
 <p><b>Proposed resolution:</b></p>
 
+<p>
+Add these signatures to 20.3 [tuple]
+</p>
+
+<blockquote><pre>template &lt;class... Types&gt;
+  void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
+template &lt;class... Types&gt;
+  void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
+template &lt;class... Types&gt;
+  void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y); 
+</pre></blockquote>
+
+<p>
+Add this signature to 20.3.1 [tuple.tuple]
+</p>
+
+<blockquote><pre>void swap(tuple&amp;&amp;);
+</pre></blockquote>
+
+<p>
+Add the following two sections to the end of the tuple clauses
+</p>
+
+<blockquote>
+<p>
+20.3.1.7 tuple swap [tuple.swap]
+</p>
+
+<pre>void swap(tuple&amp;&amp; rhs); 
+</pre>
+
+<blockquote>
+<p>
+<i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt>.
+</p>
+<p>
+<i>Effects:</i> Calls <tt>swap</tt> for each element in <tt>*this</tt> and its corresponding element
+in <tt>rhs</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throw an
+exception. 
+</p>
+</blockquote>
+
+<p>
+20.3.1.8 tuple specialized algorithms [tuple.special]
+</p>
+
+<pre>template &lt;class... Types&gt;
+  void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
+template &lt;class... Types&gt;
+  void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
+template &lt;class... Types&gt;
+  void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y); 
+</pre>
+
+<blockquote>
+<p>
+<i>Effects:</i> x.swap(y)
+</p>
+</blockquote>
+</blockquote>
+
+
 
 
 
@@ -4619,236 +5362,92 @@ Pete: Possible general problem with case insensitive ranges.
 
 
 <hr>
-<h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3>
-<p><b>Section:</b> 20.5.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2005-10-01</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="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>
+ <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>Discussion:</b></p>
 <p>
-The original bind proposal gives the guarantee that tr1::bind(f, t1,
-..., tN) does not throw when the copy constructors of f, t1, ..., tN
-don't.
+There are some problems in the definition of partial_sum and
+adjacent_difference in 26.4 [lib.numeric.ops]
 </p>
 
 <p>
-This guarantee is not present in the final version of TR1.
+Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
+parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
+specifies the effects clause as;
 </p>
 
-<p>
-I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
+<blockquote><p>
+Assigns to every element referred to by iterator <tt>i</tt> in the range
+<tt>[result,result + (last - first))</tt> a value correspondingly equal to
 </p>
+<blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
+</pre></blockquote>
+</blockquote>
 
-<p><i>[
-Berlin: not quite editorial, needs proposed wording.
-]</i></p>
-
-<p><i>[
-Batavia:  Doug to translate wording to variadic templates.
-]</i></p>
-
-
-<p><i>[
-Toronto:  We agree but aren't quite happy with the wording.  The "t"'s no
-longer refer to anything.  Alan to provide improved wording.
-]</i></p>
+<p>
+And similarly for BinaryOperation. Using just this definition, it seems
+logical to expect that:
+</p>
 
 
+<blockquote><pre>char i_array[4] = { 100, 100, 100, 100 };
+int  o_array[4];
 
+std::partial_sum(i_array, i_array+4, o_array);
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-In 20.5.10.1.3 [lib.func.bind.bind] ([tr.func.bind.bind]), add a new paragraph after p2:
+Is equivalent to
 </p>
-<blockquote><p>
-<i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
-throws an exception.
-</p></blockquote>
+
+<blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
+</pre></blockquote>
 
 <p>
-Add a new paragraph after p4:
+i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>,
+<tt>int</tt>.
 </p>
-<blockquote><p>
-<i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
-throws an exception.
-</p></blockquote>
 
-
-
-
-
-<hr>
-<h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3>
-<p><b>Section:</b> 17.4.3.8 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-10-25</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-17.4.3.8/1 says:
+Yet all implementations I have tested produce 100, -56, 44, -112,
+because they are using an accumulator of the <tt>InputIterator</tt>'s
+<tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>.
 </p>
 
-<blockquote><p>
-Violation of the preconditions specified in a function's 
-Required behavior: paragraph results in undefined behavior unless the 
-function's Throws: paragraph specifies throwing an exception when the 
-precondition is violated.
-</p></blockquote>
-
 <p>
-This implies that a precondition violation can lead to defined
-behavior.  That conflicts with the only reasonable definition of
-precondition: that a violation leads to undefined behavior.  Any other
-definition muddies the waters when it comes to analyzing program
-correctness, because precondition violations may be routinely done in
-correct code (e.g. you can use std::vector::at with the full
-expectation that you'll get an exception when your index is out of
-range, catch the exception, and continue).  Not only is it a bad
-example to set, but it encourages needless complication and redundancy
-in the standard.  For example:
+The issue becomes more noticeable when the result of the expression <tt>*i +
+*(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the
+<tt>value_type</tt>. In a contrived example:
 </p>
 
-<blockquote><pre>  21 Strings library 
-  21.3.3 basic_string capacity
-
-  void resize(size_type n, charT c);
-
-  5 Requires: n &lt;= max_size()
-  6 Throws: length_error if n &gt; max_size().
-  7 Effects: Alters the length of the string designated by *this as follows:
+<blockquote><pre>enum not_int { x = 1, y = 2 };
+...
+not_int e_array[4] = { x, x, y, y };
+std::partial_sum(e_array, e_array+4, o_array);
 </pre></blockquote>
 
 <p>
-The Requires clause is entirely redundant and can be dropped.  We
-could make that simplifying change (and many others like it) even
-without changing 17.4.3.8/1; the wording there just seems to encourage
-the redundant and error-prone Requires: clause.
+Is it the intent that the operations happen in the <tt>input type</tt>, or in
+the <tt>result type</tt>?
 </p>
 
-<p><i>[
-Batavia:  Alan and Pete to work.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-1. Change 17.4.3.8/1 to read:
+If the intent is that operations happen in the <tt>result type</tt>, something
+like this should be added to the "Requires" clause of 26.4.3/4
+[lib.partial.sum]:
 </p>
 
 <blockquote><p>
-Violation of the preconditions specified in a function's
-<i>Required behavior:</i> paragraph results in undefined behavior
-<del>unless the function's <i>Throws:</i> paragraph specifies throwing
-an exception when the precondition is violated</del>.
+The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the
+requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt>
+(23.1) types.
 </p></blockquote>
 
 <p>
-2. Go through and remove redundant Requires: clauses.  Specifics to be
-   provided by Dave A.
-</p>
-
-<p><i>[
-Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution.
-]</i></p>
-
-
-<p><i>[
-Alan provided the survey
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>.
-]</i></p>
-
-
-
-
-
-
-
-<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#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#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There are some problems in the definition of partial_sum and
-adjacent_difference in 26.4 [lib.numeric.ops]
-</p>
-
-<p>
-Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
-parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
-specifies the effects clause as;
-</p>
-
-<blockquote><p>
-Assigns to every element referred to by iterator <tt>i</tt> in the range
-<tt>[result,result + (last - first))</tt> a value correspondingly equal to
-</p>
-<blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
-</pre></blockquote>
-</blockquote>
-
-<p>
-And similarly for BinaryOperation. Using just this definition, it seems
-logical to expect that:
-</p>
-
-
-<blockquote><pre>char i_array[4] = { 100, 100, 100, 100 };
-int  o_array[4];
-
-std::partial_sum(i_array, i_array+4, o_array);
-</pre></blockquote>
-
-<p>
-Is equivalent to
-</p>
-
-<blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
-</pre></blockquote>
-
-<p>
-i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>,
-<tt>int</tt>.
-</p>
-
-<p>
-Yet all implementations I have tested produce 100, -56, 44, -112,
-because they are using an accumulator of the <tt>InputIterator</tt>'s
-<tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>.
-</p>
-
-<p>
-The issue becomes more noticeable when the result of the expression <tt>*i +
-*(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the
-<tt>value_type</tt>. In a contrived example:
-</p>
-
-<blockquote><pre>enum not_int { x = 1, y = 2 };
-...
-not_int e_array[4] = { x, x, y, y };
-std::partial_sum(e_array, e_array+4, o_array);
-</pre></blockquote>
-
-<p>
-Is it the intent that the operations happen in the <tt>input type</tt>, or in
-the <tt>result type</tt>?
-</p>
-
-<p>
-If the intent is that operations happen in the <tt>result type</tt>, something
-like this should be added to the "Requires" clause of 26.4.3/4
-[lib.partial.sum]:
-</p>
-
-<blockquote><p>
-The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the
-requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt>
-(23.1) types.
-</p></blockquote>
-
-<p>
-(As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2
-[lib.inner.product].)
+(As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2
+[lib.inner.product].)
 </p>
 
 <p>
@@ -4912,12 +5511,38 @@ adding signatures to allow user to specify "accumulator".
 ]</i></p>
 
 
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+The intent of the algorithms is to perform their calculations using the type of the input iterator.
+Proposed wording provided.
+</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
+Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences:
+</p>
+
+<blockquote>
+The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
+(20.1.3?) and <tt>Assignable</tt> (23.1?) types. The result of <tt>*i + *(i+1)</tt> or
+<tt>binary_op(*i, *(i+1))</tt> shall be convertible to this type.
+</blockquote>
+
+<p>
+Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence:
 </p>
 
+<blockquote>
+The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
+(20.1.3) and <tt>Assignable</tt> (23.1) types.
+</blockquote>
+
+
 
 
 
@@ -4951,11 +5576,11 @@ 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#Open">Open</a>
+<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#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>
 Assuming we adopt the
@@ -5015,52 +5640,73 @@ resolution")
 
 
 <p><i>[
-</i></p><p>
-<i>Howard, post Kona:
-</i></p>
+<p>
+Howard, post Kona:
+</p>
 <blockquote>
 <p>
-<i>Unfortunately I strongly disagree with a part of the resolution
+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.
-</i></p>
+</p>
 <p>
-<i>This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because
+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>.
-</i></p>
+</p>
 <p>
-<i>For similar reasons, I do not believe that the second <tt>long double</tt> parameter of
+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:
-</i></p>
+</p>
 <blockquote>
-<pre><i>float nexttoward(float, long double);
-</i></pre>
+<pre>float nexttoward(float, long double);
+</pre>
 </blockquote>
 <p>
-<i>which is what both the C++0X working paper and C99 state (as far as I currently understand).
-</i></p>
+which is what both the C++0X working paper and C99 state (as far as I currently understand).
+</p>
 <p>
-<i>This is really <b>only</b> about <tt>pow(float, int)</tt>.  And this is because C++98 took one
+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.
-</i></p>
+</p>
 </blockquote>
-<i>]</i>
+]</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]
+Change 26.7 [c.math] p10:
 </p>
 
-<blockquote><pre>float pow(float, float); 
-<del>float</del> <ins>double</ins> pow(float, int);
+<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>
 
 
 
@@ -5129,335 +5775,323 @@ destroyed.
 
 
 <hr>
-<h3><a name="557"></a>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3>
-<p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
+<h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
+<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
-long long we end up, essentially, with the same arguments and different
-return types (lldiv_t and imaxdiv_t, respectively). Similar issue with
-abs(_Longlong) and abs(intmax_t), of course.
-</p>
-<p>
-Comparing sections 8.25 and 8.11, I see an important difference,
-however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong
-types (rightfully, because not moved over directly from C99), whereas
-there is no equivalent in 8.11: the abs and div overloads for intmax_t
-types appear only in the synopsis and are not described anywhere, in
-particular no mention in 8.11.2 (at variance with 8.25.2).
-</p>
-<p>
-I'm wondering whether we really, really, want div and abs for intmax_t...
+The   effects  of  the   <code>seekpos()</code>  member   function  of
+<code>basic_stringbuf</code>  simply say  that the  function positions
+the  input and/or  output  sequences  but fail  to  spell out  exactly
+how. This is in contrast  to the detail in which <code>seekoff()</code>
+is described.
 </p>
 
 
-
 <p><b>Proposed resolution:</b></p>
+        <p>
+
+Change 27.7.1.3, p13 to read:
 
+        </p>
+<blockquote>
+<p>
+-13- <i>Effects:</i> <ins>Same as <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
+<i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
+if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
+(as described below).</del>
+</p>
+<ul>
+<li><del>If <tt>(<i>which</i> &amp; ios_base::in) != 0</tt>, positions the input sequence.</del></li>
+<li><del>If <tt>(<i>which</i> &amp; ios_base::out) != 0</tt>, positions the output sequence.</del></li>
+<li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
+positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
+has not been obtained by a previous successful call to one of the positioning
+functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
+the effect is undefined.</del></li>
+</ul>
+</blockquote>
 
 
 <p><i>[
-Portland: no consensus.
+Kona (2007): A <tt>pos_type</tt> is a position in a stream by
+definition, so there is no ambiguity as to what it means. Proposed
+Disposition: NAD
 ]</i></p>
 
 
-<p><b>Rationale:</b></p>
 <p><i>[
-Batavia, Bill: The <tt>&lt;cstdint&gt;</tt> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains:
+Post-Kona Martin adds:
+I'm afraid I disagree
+with the Kona '07 rationale for marking it NAD. The only text
+that describes precisely what it means to position the input
+or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
+clause is inadequate in comparison and the proposed resolution
+plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
 ]</i></p>
 
-<blockquote><pre>intmax_t imaxabs(intmax_t i);
-intmax_t abs(intmax_t i);
-
-imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
-imaxdiv_t div(intmax_t numer, intmax_t denom);
-</pre></blockquote>
 
-<p><i>[
-and in TR1 8.11.2 [tr.c99.cinttypes.def]:
-]</i></p>
 
 
-<blockquote><p>
-The header defines all functions, types, and macros the same as C99
-subclause 7.8.
-</p></blockquote>
 
-<p><i>[
-This is as much definition as we give for most other C99 functions,
-so nothing need change. We might, however, choose to add the footnote:
-]</i></p>
+<hr>
+<h3><a name="565"></a>565. xsputn inefficient</h3>
+<p><b>Section:</b> 27.5.2.4.5 [streambuf.virt.put] <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-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+        <p>
 
+<tt>streambuf::xsputn()</tt>  is  specified  to  have  the  effect  of
+"writing up to  <tt>n</tt> characters to the output  sequence as if by
+repeated calls to <tt>sputc(c)</tt>."
 
-<blockquote><p>
-[<i>Note:</i> These overloads for <tt>abs</tt> and <tt>div</tt> may well be equivalent to
-those that take <tt>long long</tt> arguments. If so, the implementation is
-responsible for avoiding conflicting declarations. -- <i>end note</i>]
-</p></blockquote>
+        </p>
+        <p>
 
+Since  <tt>sputc()</tt> is required  to call  <tt>overflow()</tt> when
+<tt>(pptr()    ==   epptr())</tt>    is   true,    strictly   speaking
+<tt>xsputn()</tt>  should do  the same.   However, doing  so  would be
+suboptimal in  some interesting cases,  such as in unbuffered  mode or
+when the buffer is <tt>basic_stringbuf</tt>.
 
+        </p>
+        <p>
 
+Assuming  calling <tt>overflow()</tt>  is  not really  intended to  be
+required  and the  wording is  simply  meant to  describe the  general
+effect of appending to the end  of the sequence it would be worthwhile
+to  mention in  <tt>xsputn()</tt> that  the function  is  not actually
+required to cause a call to <tt>overflow()</tt>.
 
+        </p>
 
 
-<hr>
-<h3><a name="561"></a>561. inserter overly generic</h3>
-<p><b>Section:</b> 24.4.2.6.5 [inserter] <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-02-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The declaration of <tt>std::inserter</tt> is:
-</p>
+<p><b>Proposed resolution:</b></p>
+        <p>
 
-<blockquote><pre>template &lt;class Container, class Iterator&gt;
-insert_iterator&lt;Container&gt;
-inserter(Container&amp; x, Iterator i);
-</pre></blockquote>
+Add the following sentence  to the <tt>xsputn()</tt> Effects clause in
+27.5.2.4.5, p1 (N1804):
 
-<p>
-The template parameter <tt>Iterator</tt> in this function is completely unrelated
-to the template parameter <tt>Container</tt> when it doesn't need to be.  This
-causes the code to be overly generic.  That is, any type at all can be deduced
-as <tt>Iterator</tt>, whether or not it makes sense.  Now the same is true of
-<tt>Container</tt>.  However, for every free (unconstrained) template parameter
-one has in a signature, the opportunity for a mistaken binding grows geometrically.
-</p>
+        </p>
+        <blockquote>    
+            <p>
+-1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
+sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters 
+written are obtained from successive elements of the array whose first element
+is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
+characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
+<tt>traits::eof()</tt>. <ins>It is  uspecified whether the function  calls
+<tt>overflow()</tt> when <tt>(pptr() ==  epptr())</tt> becomes true or whether
+it achieves the same effects by other means.</ins>
+            </p>
+        </blockquote>    
+        <p>
 
-<p>
-It would be much better if <tt>inserter</tt> had the following signature instead:
-</p>
+In addition,  I suggest to  add a footnote  to this function  with the
+same text as Footnote 292 to  make it extra clear that derived classes
+are permitted to override <tt>xsputn()</tt> for efficiency.
 
-<blockquote><pre>template &lt;class Container&gt;
-insert_iterator&lt;Container&gt;
-inserter(Container&amp; x, typename Container::iterator i);
-</pre></blockquote>
+        </p>
 
-<p>
-Now there is only one free template parameter.  And the second argument to
-<tt>inserter</tt> must be implicitly convertible to the container's iterator,
-else the call will not be a viable overload (allowing other functions in the
-overload set to take precedence).  Furthermore, the first parameter must have a
-nested type named <tt>iterator</tt>, or again the binding to <tt>std::inserter</tt>
-is not viable.  Contrast this with the current situation
-where any type can bind to <tt>Container</tt> or <tt>Iterator</tt> and those
-types need not be anything closely related to containers or iterators.
-</p>
 
-<p>
-This can adversely impact well written code.  Consider:
-</p>
-
-<blockquote><pre>#include &lt;iterator&gt;
-#include &lt;string&gt;
-
-namespace my
-{
-
-template &lt;class String&gt;
-struct my_type {};
+<p><i>[
+Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
+to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
+has always been the intention of the committee. We believe that the
+proposed wording doesn't accomplish that. Proposed Disposition: Open
+]</i></p>
 
-struct my_container
-{
-template &lt;class String&gt;
-void push_back(const my_type&lt;String&gt;&amp;);
-};
 
-template &lt;class String&gt;
-void inserter(const my_type&lt;String&gt;&amp; m, my_container&amp; c) {c.push_back(m);}
 
-}  // my
 
-int main()
-{
-    my::my_container c;
-    my::my_type&lt;std::string&gt; m;
-    inserter(m, c);
-}
-</pre></blockquote>
 
+<hr>
+<h3><a name="568"></a>568. log2 overloads missing</h3>
+<p><b>Section:</b> TR1 8.16.4 [tr.c99.cmath.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-03-07</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Today this code fails because the call to <tt>inserter</tt> binds to
-<tt>std::inserter</tt> instead of to <tt>my::inserter</tt>.  However with the
-proposed change <tt>std::inserter</tt> will no longer be a viable function which
-leaves only <tt>my::inserter</tt> in the overload resolution set.  Everything
-works as the client intends.
+<tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
 </p>
 
 <p>
-To make matters a little more insidious, the above example works today if you
-simply change the first argument to an rvalue:
+Hinnant:  This is a TR1 issue only.  It is fixed in the current (N2135) WD.
 </p>
 
-<blockquote><pre>    inserter(my::my_type(), c);
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-It will also work if instantiated with some string type other than
-<tt>std::string</tt> (or any other <tt>std</tt> type).  It will also work if
-<tt>&lt;iterator&gt;</tt> happens to not get included.
+Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
 </p>
 
-<p>
-And it will fail again for such inocuous reaons as <tt>my_type</tt> or
-<tt>my_container</tt> privately deriving from any <tt>std</tt> type.
-</p>
 
-<p>
-It seems unfortunate that such simple changes in the client's code can result
-in such radically differing behavior.
-</p>
 
 
 
-<p><b>Proposed resolution:</b></p>
+<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>
-Change 24.2:
-</p>
-
-<blockquote><p>
-<b>24.2 Header</b> <tt>&lt;iterator&gt;</tt> <b>synopsis</b>
+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>
-<blockquote><pre>...
-template &lt;class Container<del>, class Iterator</del>&gt;
-   insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
-...
-</pre></blockquote>
-</blockquote>
-
 <p>
-Change 24.4.2.5:
+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>
 
-<blockquote><p>
-<b>24.4.2.5 Class template</b> <tt>insert_iterator</tt></p>
-<blockquote><pre>...
-template &lt;class Container<del>, class Iterator</del>&gt;
-   insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
-...
-</pre></blockquote>
-</blockquote>
+<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>
 
-<p>
-Change 24.4.2.6.5:
-</p>
 
 <blockquote>
 <p>
-<b>24.4.2.6.5</b> <tt>inserter</tt>
+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>
-<pre>template &lt;class Container<del>, class Inserter</del>&gt;
-   insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Inserter</del> <ins>typename Container::iterator</ins> i);
-</pre>
-<blockquote><p>
--1- <i>Returns:</i> <tt>insert_iterator&lt;Container&gt;(x,<del>typename Container::iterator(</del>i<del>)</del>)</tt>.
-</p></blockquote>
 </blockquote>
 
 
 
-<p><i>[
-Kona (2007): This issue will probably be addressed as a part of the
-concepts overhaul of the library anyway, but the proposed resolution is
-correct in the absence of concepts. Proposed Disposition: Ready
-]</i></p>
+<p><b>Proposed resolution:</b></p>
 
 
 
 
 
 <hr>
-<h3><a name="562"></a>562. stringbuf ctor inefficient</h3>
-<p><b>Section:</b> 27.7 [string.streams] <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> 2006-02-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</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="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>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</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>
+<p>
+There are two deficiencies related to file sizes:
+</p>
+<ol>
+<li>It doesn't appear that the Standard Library is specified in
+      a way that handles modern file sizes, which are often too
+      large to be represented by an unsigned long.</li>
 
-For  better efficiency,  the requirement  on the  stringbuf  ctor that
-takes  a  string  argument  should  be  loosened  up  to  let  it  set
-<code>epptr()</code>  beyond  just   one  past  the  last  initialized
-character  just like  <code>overflow()</code> has  been changed  to be
-allowed  to  do   (see  issue  432).  That  way   the  first  call  to
-<code>sputc()</code> on  an object won't  necessarily cause a  call to
-<code>overflow</code>. The corresponding change  should be made to the
-string overload of the <code>str()</code> member function.
+<li>The std::fpos class does not currently have the ability to
+      set/get file positions.</li>
+</ol>
+<p>
+The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
+</p>
+<ol type="A">
+<li>Defining fpos_t be long long, which is large enough to
+      represent any file position likely in the foreseeable future.</li>
+
+<li>Adding member functions to class fpos. For example,
+<blockquote><pre>fpos_t seekpos() const;
+</pre></blockquote>
+</li>
+</ol>
+<p>
+Because there are so many types relating to file positions and offsets (fpos_t,
+fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
+perhaps more), it is difficult to know if the Dinkumware extensions are
+sufficient. But they seem a useful starting place for discussions, and they do
+represent existing practice.
+</p>
+
+<p><i>[
+Kona (2007): We need a paper. It would be nice if someone proposed
+clarifications to the definitions of <tt>pos_type</tt> and <tt>off_type</tt>. Currently
+these definitions are horrible. Proposed Disposition: Open
+]</i></p>
 
-        </p>
 
 
 <p><b>Proposed resolution:</b></p>
-        <p>
+<p>
+</p>
+
 
-Change 27.7.1.1, p3 of the Working Draft, N1804, as follows:
 
-        </p>
 
-<blockquote><pre>explicit basic_stringbuf(const basic_string&lt;charT,traits,Allocator&gt;&amp; <i>s<del>tr</del></i>,
-               ios_base::openmode <i>which</i> = ios_base::in | ios_base::out);
-</pre>
 
+<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>
--3- <i>Effects:</i>  Constructs an object of class <tt>basic_stringbuf</tt>,
-initializing the base class with <tt>basic_streambuf()</tt>
-(27.5.2.1), and initializing <tt><i>mode</i></tt> with <tt><i>which</i></tt>.
-Then <ins>calls <tt>str(<i>s</i>)</tt>.</ins> <del>copies the content of
-<i>str</i> into the <tt>basic_stringbuf</tt> underlying character
-sequence. If <tt><i>which</i> &amp; ios_base::out</tt> is true, initializes the
-output sequence such that <tt>pbase()</tt> points to the first underlying
-character, <tt>epptr()</tt> points one past the last underlying character, and
-<tt>pptr()</tt> is equal to <tt>epptr()</tt> if <tt><i>which</i> &amp; ios_base::ate</tt>
-is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
-<tt>which &amp; ios_base::in</tt> is true, initializes the input sequence such
-that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying 
-character and <tt>egptr()</tt> points one past the last underlying character.</del>
+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>
-</blockquote>
 
-        <p>
 
-Change the Effects clause of the <code>str()</code> in 27.7.1.2, p2 to
-read:
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 27.3 [iostream.objects]/1:
+</p>
 
-        </p>
 <blockquote>
 <p>
--2- <i>Effects:</i> Copies the content<ins>s</ins> of <tt><i>s</i></tt> into the
-<tt>basic_stringbuf</tt> underlying character sequence <ins>and
-initializes the input and output sequences according to <tt><i>mode</i></tt></ins>.
-<del>If
-<tt><i>mode</i> &amp; ios_base::out</tt> is true, initializes the output
-sequence such that <tt>pbase()</tt> points to the first underlying character, 
-<tt>epptr()</tt> points one past the last underlying character, and <tt>pptr()</tt>
-is equal to <tt>epptr()</tt> if <tt><i>mode</i> &amp; ios_base::in</tt>
-is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
-<tt>mode &amp; ios_base::in</tt> is true, initializes the input sequence 
-such that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying
-character and <tt>egptr()</tt> points one past the last underlying character.</del>
+-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>
-
-        <p>
-
-<ins>-3- <i>Postconditions:</i>  If  <code>mode  &amp; ios_base::out</code>  is  true,
-<code>pbase()</code>  points  to the  first  underlying character  and
-<code>(epptr() &gt;= pbase() + s.size())</code> holds; in addition, if
-<code>mode &amp; ios_base::in</code> is true, <code>(pptr() == pbase()
-+ s.data())</code>  holds, otherwise <code>(pptr()  == pbase())</code>
-is   true.    If  <code>mode   &amp;   ios_base::in</code>  is   true,
-<code>eback()</code>  points to  the first  underlying  character, and
-<code>(gptr()  ==  eback())</code>  and  <code>(egptr() ==  eback()  +
-s.size())</code> hold.</ins>
-
-        </p>
 </blockquote>
 
 
 <p><i>[
-Kona (2007) Moved to Ready.
+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>
 
 
@@ -5465,121 +6099,138 @@ Kona (2007) Moved to Ready.
 
 
 <hr>
-<h3><a name="563"></a>563. stringbuf seeking from end</h3>
-<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="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>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
 <p><b>Discussion:</b></p>
-<p>
-According to  Table 92  (unchanged by issue  432), when  <code>(way ==
-end)</code> the  <code>newoff</code> value in out mode  is computed as
-the difference between <code>epptr()</code> and <code>pbase()</code>.
-</p>
         <p>
 
-This value  isn't meaningful unless the  value of <code>epptr()</code>
-can be  precisely controlled by a  program.  That used  to be possible
-until  we accepted the  resolution of  issue 432,  but since  then the
-requirements on <code>overflow()</code> have  been relaxed to allow it
-to  make  more than  1  write  position  available (i.e.,  by  setting
-<code>epptr()</code>     to     some     unspecified    value     past
-<code>pptr()</code>).      So    after     the    first     call    to
-<code>overflow()</code>  positioning the  output sequence  relative to
-end will have unspecified results.
+C++ Standard Library  templates that take an allocator  as an argument
+are    required    to    call    the    <code>allocate()</code>    and
+<code>deallocate()</code>  members of the  allocator object  to obtain
+storage.  However, they do not appear to be required to call any other
+allocator      members      such     as      <code>construct()</code>,
+<code>destroy()</code>,           <code>address()</code>,          and
+<code>max_size()</code>.  This makes these allocator members less than
+useful in portable programs.
 
         </p>
         <p>
 
-In  addition,  in <code>in|out</code>  mode,  since <code>(egptr()  ==
-epptr())</code> need not hold, there are two different possible values
-for   <code>newoff</code>:    <code>epptr()   -   pbase()</code>   and
-<code>egptr() - eback()</code>.
+It's unclear to me whether the absence of the requirement to use these
+allocator  members  is  an  unintentional  omission  or  a  deliberate
+choice. However,  since the functions exist in  the standard allocator
+and  since  they are  required  to  be  provided by  any  user-defined
+allocator I  believe the standard  ought to be clarified  to explictly
+specify  whether programs  should or  should not  be able  to  rely on
+standard containers calling the functions.
 
         </p>
-
-
-<p><b>Proposed resolution:</b></p>
         <p>
 
-Change the <code>newoff</code>  column in the last row  of Table 94 to
-read:
+I  propose  that all  containers  be required  to  make  use of  these
+functions.
 
         </p>
-<blockquote><p>
+<p><i>[
+Batavia:  We support this resolution.  Martin to provide wording.
+]</i></p>
 
-the <del>end</del> <ins>high mark</ins> pointer minus the beginning 
-pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>).
+<p><i>[
+pre-Oxford:  Martin provided wording.
+]</i></p>
 
-</p></blockquote>
+    
 
+    <p><b>Proposed resolution:</b></p>
+       <p>
 
-<p><i>[
-Kona (2007) Moved to Ready.
-]</i></p>
+Specifically, I propose to change 23.1 [container.requirements],
+p9 as follows:
+
+       </p>
+           <blockquote>
+<p>
+-9- Copy constructors  for all container types defined  in this clause
+<ins>that   are  parametrized  on   <code>Allocator</code></ins>  copy
+<del>an</del><ins>the</ins>  allocator argument from  their respective
+first parameters.
 
+All other  constructors for  these container types  take a<del>n</del>
+<ins>const</ins>  <code>Allocator&amp;</code>  argument  (20.1.6),  an
+allocator whose <code>value_type</code> is the same as the container's
+<code>value_type</code>.
 
+A copy of this  argument <del>is</del><ins>shall be</ins> used for any
+memory  allocation <ins> and  deallocation</ins> performed<del>,</del>
+by these  constructors and by all  member functions<del>,</del> during
+the  lifetime  of each  container  object.   <ins>Allocation shall  be
+performed  "as  if"  by  calling  the  <code>allocate()</code>  member
+function on  a copy  of the allocator  object of the  appropriate type
+<sup>New  Footnote)</sup>,   and  deallocation  "as   if"  by  calling
+<code>deallocate()</code> on  a copy of  the same allocator  object of
+the corresponding type.</ins>
 
+<ins>A  copy of  this argument  shall also  be used  to  construct and
+destroy objects whose lifetime  is managed by the container, including
+but not  limited to those of  the container's <code>value_type</code>,
+and  to  obtain  their  address.   All  objects  residing  in  storage
+allocated by a  container's allocator shall be constructed  "as if" by
+calling the <code>construct()</code> member  function on a copy of the
+allocator object of  the appropriate type.  The same  objects shall be
+destroyed "as if"  by calling <code>destroy()</code> on a  copy of the
+same allocator object  of the same type.  The  address of such objects
+shall be obtained "as if" by calling the <code>address()</code> member
+function  on  a  copy  of  the allocator  object  of  the  appropriate
+type.</ins>
 
+<ins>Finally, a copy  of this argument shall be  used by its container
+object to determine  the maximum number of objects  of the container's
+<code>value_type</code> the container may  store at the same time. The
+container  member function <code>max_size()</code> obtains  this number
+from      the      value      returned      by     a      call      to
+<code>get_allocator().max_size()</code>.</ins>
 
-<hr>
-<h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
-<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+In   all  container   types  defined   in  this   clause <ins>that  are
+parametrized     on    <code>Allocator</code></ins>,     the    member
+<code>get_allocator()</code>     returns     a     copy     of     the
+<code>Allocator</code>     object     used     to    construct     the
+container.<sup>258)</sup>
+</p>
 <p>
-The   effects  of  the   <code>seekpos()</code>  member   function  of
-<code>basic_stringbuf</code>  simply say  that the  function positions
-the  input and/or  output  sequences  but fail  to  spell out  exactly
-how. This is in contrast  to the detail in which <code>seekoff()</code>
-is described.
+New Footnote: This type  may be different from <code>Allocator</code>:
+it     may    be     derived    from     <code>Allocator</code>    via
+<code>Allocator::rebind&lt;U&gt;::other</code>   for  the  appropriate
+type <code>U</code>.
 </p>
+           </blockquote>
+       <p>
 
+The proposed wording seems cumbersome but I couldn't think of a better
+way   to  describe   the   requirement  that   containers  use   their
+<code>Allocator</code>  to manage  only objects  (regardless  of their
+type)  that  persist  over  their  lifetimes  and  not,  for  example,
+temporaries  created on the  stack. That  is, containers  shouldn't be
+required  to  call  <code>Allocator::construct(Allocator::allocate(1),
+elem)</code>  just to  construct a  temporary copy  of an  element, or
+<code>Allocator::destroy(Allocator::address(temp),     1)</code>    to
+destroy temporaries.
 
-<p><b>Proposed resolution:</b></p>
-        <p>
-
-Change 27.7.1.3, p13 to read:
-
-        </p>
-<blockquote>
-<p>
--13- <i>Effects:</i> <ins>Same as <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
-<i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
-if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
-(as described below).</del>
-</p>
-<ul>
-<li><del>If <tt>(<i>which</i> &amp; ios_base::in) != 0</tt>, positions the input sequence.</del></li>
-<li><del>If <tt>(<i>which</i> &amp; ios_base::out) != 0</tt>, positions the output sequence.</del></li>
-<li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
-positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
-has not been obtained by a previous successful call to one of the positioning
-functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
-the effect is undefined.</del></li>
-</ul>
-</blockquote>
+       </p>
 
 
 <p><i>[
-Kona (2007): A <tt>pos_type</tt> is a position in a stream by
-definition, so there is no ambiguity as to what it means. Proposed
-Disposition: NAD
+Howard: This same paragraph will need some work to accommodate <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
 ]</i></p>
 
 
 <p><i>[
-Post-Kona Martin adds:
-I'm afraid I disagree
-with the Kona '07 rationale for marking it NAD. The only text
-that describes precisely what it means to position the input
-or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
-clause is inadequate in comparison and the proposed resolution
-plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
+post Oxford:  This would be rendered NAD Editorial by acceptance of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
 ]</i></p>
 
 
@@ -5587,596 +6238,552 @@ plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
 
 
 <hr>
-<h3><a name="565"></a>565. xsputn inefficient</h3>
-<p><b>Section:</b> 27.5.2.4.5 [streambuf.virt.put] <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-23</p>
+<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>
+ <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>
 <p><b>Discussion:</b></p>
         <p>
 
-<tt>streambuf::xsputn()</tt>  is  specified  to  have  the  effect  of
-"writing up to  <tt>n</tt> characters to the output  sequence as if by
-repeated calls to <tt>sputc(c)</tt>."
+The specialized  algorithms [lib.specialized.algorithms] are specified
+as having the general effect of invoking the following expression:
 
         </p>
+            <pre>
+new (static_cast&lt;void*&gt;(&amp;*i))
+    typename iterator_traits&lt;ForwardIterator&gt;::value_type (x)
+
+            </pre>
         <p>
 
-Since  <tt>sputc()</tt> is required  to call  <tt>overflow()</tt> when
-<tt>(pptr()    ==   epptr())</tt>    is   true,    strictly   speaking
-<tt>xsputn()</tt>  should do  the same.   However, doing  so  would be
-suboptimal in  some interesting cases,  such as in unbuffered  mode or
-when the buffer is <tt>basic_stringbuf</tt>.
+This  expression is  ill-formed  when the  type  of the  subexpression
+<code>&amp;*i</code> is some volatile-qualified <code>T</code>.
 
         </p>
+
+<p><i>[
+Batavia:  Lack of support for proposed resolution but agree there is a
+defect.  Howard to look at wording.  Concern that move semantics
+properly expressed if iterator returns rvalue.
+]</i></p>
+
+
+    
+
+    <p><b>Proposed resolution:</b></p>
         <p>
 
-Assuming  calling <tt>overflow()</tt>  is  not really  intended to  be
-required  and the  wording is  simply  meant to  describe the  general
-effect of appending to the end  of the sequence it would be worthwhile
-to  mention in  <tt>xsputn()</tt> that  the function  is  not actually
-required to cause a call to <tt>overflow()</tt>.
+In order  to allow these algorithms  to operate on  volatile storage I
+propose to change the expression so as to make it well-formed even for
+pointers  to volatile  types.  Specifically,  I propose  the following
+changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
 
         </p>
+            <pre>
+<i>Effects</i>:
 
+typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
+typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
 
-<p><b>Proposed resolution:</b></p>
+for (; first != last; ++result, ++first)
+    new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*result))
+        value_type (*first);
+
+            </pre>
         <p>
 
-Add the following sentence  to the <tt>xsputn()</tt> Effects clause in
-27.5.2.4.5, p1 (N1804):
+change 20.6.4.2, p1 to read
 
         </p>
-        <blockquote>    
-            <p>
--1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
-sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters 
-written are obtained from successive elements of the array whose first element
-is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
-characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
-<tt>traits::eof()</tt>. <ins>It is  uspecified whether the function  calls
-<tt>overflow()</tt> when <tt>(pptr() ==  epptr())</tt> becomes true or whether
-it achieves the same effects by other means.</ins>
-            </p>
-        </blockquote>    
+            <pre>
+<i>Effects</i>:
+
+typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
+typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
+
+for (; first != last; ++result, ++first)
+    new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
+        value_type (*x);
+
+            </pre>
         <p>
 
-In addition,  I suggest to  add a footnote  to this function  with the
-same text as Footnote 292 to  make it extra clear that derived classes
-are permitted to override <tt>xsputn()</tt> for efficiency.
+and change 20.6.4.3, p1 to read
 
         </p>
+            <pre>
+<i>Effects</i>:
 
+typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
+typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
 
-<p><i>[
-Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
-to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
-has always been the intention of the committee. We believe that the
-proposed wording doesn't accomplish that. Proposed Disposition: Open
-]</i></p>
+for (; n--; ++first)
+    new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
+        value_type (*x);
+
+            </pre>
+        <p>
 
+In   addition,  since   there   is  no   partial  specialization   for
+<code>iterator_traits&lt;volatile T*&gt;</code>  I propose to  add one
+to parallel such specialization  for &lt;const T*&gt;. Specifically, I
+propose to add the following text to the end of 24.3.1, p3:
 
+        </p>
+        <p>
 
+and for pointers to volatile as 
 
+        </p>
+            <pre>
+namespace std {
+template&lt;class T&gt; struct iterator_traits&lt;volatile T*&gt; {
+typedef ptrdiff_t difference_type;
+typedef T value_type;
+typedef volatile T* pointer;
+typedef volatile T&amp; reference;
+typedef random_access_iterator_tag iterator_category;
+};
+}
 
-<hr>
-<h3><a name="567"></a>567. streambuf inserter and extractor should be unformatted</h3>
-<p><b>Section:</b> 27.6 [iostream.format] <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> 2006-02-25</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iostream.format">active issues</a> in [iostream.format].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
+            </pre>
         <p>
 
-Issue  60 explicitly made  the extractor  and inserter  operators that
-take a  <tt>basic_streambuf*</tt> argument formatted  input and output
-functions,  respectively.  I  believe that's  wrong, certainly  in the
-case of  the extractor, since formatted functions  begin by extracting
-and  discarding  whitespace.  The  extractor  should  not discard  any
-characters.
+Note that  the change to  <code>iterator_traits</code> isn't necessary
+in order to implement the  specialized algorithms in a way that allows
+them to operate on volatile  strorage. It is only necesassary in order
+to specify  their effects in terms  of <code>iterator_traits</code> as
+is  done here.   Implementations can  (and some  do) achieve  the same
+effect by means of function template overloading.
 
         </p>
+    
 
 
-<p><b>Proposed resolution:</b></p>
+
+<hr>
+<h3><a name="585"></a>585. facet error reporting</h3>
+<p><b>Section:</b> 22.2 [locale.categories] <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, Paolo Carlini <b>Date:</b> 2006-06-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
         <p>
 
-I propose to  change each operator to behave  as unformatted input and
-output function,  respectively. The changes below are  relative to the
-working draft document number N1804.
+Section  22.2, paragraph 2  requires facet  <code>get()</code> members
+that    take    an    <code>ios_base::iostate&amp;</code>    argument,
+<code><i>err</i></code>,  to   ignore  the  (initial)   value  of  the
+argument, but to set it to <code>ios_base::failbit</code> in case of a
+parse error.
 
         </p>
         <p>
 
-Specifically, change 27.6.1.2.3, p14 as follows:
+We  believe  there  are  a   few  minor  problems  with  this  blanket
+requirement  in   conjunction  with   the  wording  specific   to  each
+<code>get()</code> member function.
 
         </p>
-
-            <blockquote>
         <p>
 
-<i>Effects</i>:  Behaves as  a<ins>n un</ins>formatted  input function
-(as   described   in   <del>27.6.1.2.1</del><ins>27.6.1.3,   paragraph
-1</ins>).
+First,  besides <code>get()</code>  there are  other  member functions
+with     a      slightly     different     name      (for     example,
+<code>get_date()</code>). It's not completely clear that the intent of
+the  paragraph  is  to  include  those  as  well,  and  at  least  one
+implementation has interpreted the requirement literally.
 
         </p>
-            </blockquote>
         <p>
 
-And change 27.6.2.5.3, p7 as follows:
+Second,    the     requirement    to    "set     the    argument    to
+<code>ios_base::failbit</code>  suggests that  the  functions are  not
+permitted    to   set    it   to    any   other    value    (such   as
+<code>ios_base::eofbit</code>,   or   even  <code>ios_base::eofbit   |
+ios_base::failbit</code>).
 
         </p>
-
-            <blockquote>
         <p>
 
-<i>Effects</i>: Behaves  as a<ins>n un</ins>formatted  output function
-(as   described   in   <del>27.6.2.5.1</del><ins>27.6.2.6,   paragraph
-1</ins>).
+However, 22.2.2.1.2, p5 (Stage  3 of <code>num_get</code> parsing) and
+p6 (<code>bool</code> parsing)  specifies that the <code>do_get</code>
+functions  perform <code><i>err</i> |=  ios_base::eofbit</code>, which
+contradicts  the earlier  requirement to  ignore  <i>err</i>'s initial
+value.
 
         </p>
-            </blockquote>
+        <p>
 
+22.2.6.1.2,  p1  (the  Effects  clause of  the  <code>money_get</code>
+facet's  <code>do_get</code>  member  functions) also  specifies  that
+<code><i>err</i></code>'s initial  value be used to  compute the final
+value  by  ORing  it  with  either  <code>ios_base::failbit</code>  or
+with<code>ios_base::eofbit | ios_base::failbit</code>.
 
-<p><i>[
-Kona (2007): Proposed Disposition: Ready
-]</i></p>
+        </p>
+    
 
+    <p><b>Proposed resolution:</b></p>
+        <p>
 
+We believe the  intent is for all facet member  functions that take an
+<code>ios_base::iostate&amp;</code> argument to:
 
+        </p>
+            <ul>
+                <li>
 
+ignore the initial value of the <code><i>err</i></code> argument,
 
-<hr>
-<h3><a name="568"></a>568. log2 overloads missing</h3>
-<p><b>Section:</b> TR1 8.16.4 [tr.c99.cmath.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-03-07</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
-</p>
+                </li>
+                <li>
 
-<p>
-Hinnant:  This is a TR1 issue only.  It is fixed in the current (N2135) WD.
-</p>
+reset <code><i>err</i></code>  to <code>ios_base::goodbit</code> prior
+to any further processing,
 
+                </li>
+                <li>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
-</p>
+and       set      either       <code>ios_base::eofbit</code>,      or
+<code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as
+appropriate,  in response  to  reaching the  end-of-file  or on  parse
+error, or both.
 
+                </li>
+            </ul>
+        <p>
 
+To that effect we propose to change 22.2, p2 as follows:
 
+        </p>
+        <p>
 
+The  <i>put</i><del>()</del>  members  make  no  provision  for  error
+reporting.   (Any  failures of  the  OutputIterator  argument must  be
+extracted   from  the   returned  iterator.)    <ins>Unless  otherwise
+specified, </ins>the <i>get</i><del>()</del>  members  <ins>that</ins>
+take an  <code>ios_base::iostate&amp;</code> argument <del>whose value
+they  ignore,  but  set  to  ios_base::failbit  in  case  of  a  parse
+error.</del><ins>,   <code><i>err</i></code>,   start  by   evaluating
+<code>err  =   ios_base::goodbit</code>,  and  may   subsequently  set
+<i>err</i>     to     either     <code>ios_base::eofbit</code>,     or
+<code>ios_base::failbit</code>,     or     <code>ios_base::eofbit    |
+ios_base::failbit</code> in response to reaching the end-of-file or in
+case of a parse error, or both, respectively.</ins>
 
-<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 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>
+    
+    
 <p><i>[
-Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>.
+Kona (2007): We need to change the proposed wording to clarify that the
+phrase "the get members" actually denotes <tt>get()</tt>, <tt>get_date()</tt>, etc.
+Proposed Disposition: Open
 ]</i></p>
 
 
 
-<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>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
+<h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</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#Open">Open</a>
+ <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2006-07-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-There are two deficiencies related to file sizes:
+The wording used for section 23.2.1 [lib.array] seems to be subtly
+ambiguous about zero sized arrays (N==0). Specifically:
 </p>
-<ol>
-<li>It doesn't appear that the Standard Library is specified in
-      a way that handles modern file sizes, which are often too
-      large to be represented by an unsigned long.</li>
-
-<li>The std::fpos class does not currently have the ability to
-      set/get file positions.</li>
-</ol>
 <p>
-The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
+* "An instance of array&lt;T, N&gt; stores N elements of type T, so that
+[...]"
 </p>
-<ol type="A">
-<li>Defining fpos_t be long long, which is large enough to
-      represent any file position likely in the foreseeable future.</li>
-
-<li>Adding member functions to class fpos. For example,
-<blockquote><pre>fpos_t seekpos() const;
-</pre></blockquote>
-</li>
-</ol>
 <p>
-Because there are so many types relating to file positions and offsets (fpos_t,
-fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
-perhaps more), it is difficult to know if the Dinkumware extensions are
-sufficient. But they seem a useful starting place for discussions, and they do
-represent existing practice.
+Does this imply that a zero sized array object stores 0 elements, i.e.
+that it cannot store any element of type T? The next point clarifies
+the rationale behind this question, basically how to implement begin()
+and end():
 </p>
-
-<p><i>[
-Kona (2007): We need a paper. It would be nice if someone proposed
-clarifications to the definitions of <tt>pos_type</tt> and <tt>off_type</tt>. Currently
-these definitions are horrible. Proposed Disposition: Open
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
+* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
+end() == unique value."
 </p>
+<p>
+What does "unique" mean in this context? Let's consider the following
+possible implementations, all relying on a partial specialization:
+</p>
+<blockquote><pre>a)
+    template&lt; typename T &gt;
+    class array&lt; T, 0 &gt; {
+    
+        ....
 
+        iterator begin()
+        { return iterator( reinterpret_cast&lt; T * &gt;( this ) ); }
+        ....
 
+    };
+</pre></blockquote>
+<p>
+This has been used in boost, probably intending that the return value
+had to be unique to the specific array object and that array couldn't
+store any T. Note that, besides relying on a reinterpret_cast, has
+(more than potential) alignment problems.
+</p>
+<blockquote><pre>b)
+    template&lt; typename T &gt;
+    class array&lt; T, 0 &gt; {
+    
+        T t;
 
+        iterator begin()
+        { return iterator( &amp;t ); }
+        ....
 
-
-<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#Review">Review</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#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
+    };
+</pre></blockquote>
 <p>
-lib.iostream.objects requires that the standard stream objects are never
-destroyed, and it requires that they be destroyed.
+This provides a value which is unique to the object and to the type of
+the array, but requires storing a T. Also, it would allow the user to
+mistakenly provide an initializer list with one element.
 </p>
 <p>
-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."
+A slight variant could be returning *the* null pointer of type T
 </p>
-
-
-<p><b>Proposed resolution:</b></p>
+<blockquote><pre>    return static_cast&lt;T*&gt;(0);
+</pre></blockquote>
 <p>
-Change 27.3 [iostream.objects]/1:
+In this case the value would be unique to the type array&lt;T, 0&gt; but not
+to the objects (all objects of type array&lt;T, 0&gt; with the same value
+for T would yield the same pointer value).
 </p>
-
-<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>.
+Furthermore this is inconsistent with what the standard requires from
+allocation functions (see library issue 9).
 </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="579"></a>579. erase(iterator) for unordered containers should not return an iterator</h3>
-<p><b>Section:</b> 23.1.3 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2006-06-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-See
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
-for full discussion.
+c) same as above but with t being a static data member; again, the
+value would be unique to the type, not to the object.
 </p>
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Option 1:
+d) to avoid storing a T *directly* while disallowing the possibility
+to use a one-element initializer list a non-aggregate nested class
+could be defined
 </p>
-
+<blockquote><pre>    struct holder { holder() {} T t; } h;
+</pre></blockquote>
 <p>
-The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an 
-iterator. This is, however, in contrast with the equivalent requirements for other 
-standard containers.
+and then begin be defined as
+</p>
+<blockquote><pre> iterator begin() { return &amp;h.t; }
+</pre></blockquote>
+<p>
+But then, it's arguable whether the array stores a T or not.
+Indirectly it does.
 </p>
-
 <p>
-Option 2:
+-----------------------------------------------------
 </p>
-
 <p>
-<tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested: 
-the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so 
-that
+Now, on different issues:
 </p>
-
-<blockquote><pre>iterator q1=a.erase(q);
-</pre></blockquote>
-
 <p>
-works as expected, while
+* what's the effect of calling assign(T&amp;) on a zero-sized array? There
+seems to be only mention of front() and back(), in 23.2.1 [lib.array]
+p4 (I would also suggest to move that bullet to section 23.2.1.5
+[lib.array.zero], for locality of reference)
 </p>
-
-<blockquote><pre>a.erase(q);
-</pre></blockquote>
-
 <p>
-does not ever invoke the conversion-to-iterator operator, thus avoiding the associated 
-computation. To allow this technique, some sections of TR1 along the line "return value 
-is an iterator..." should be changed to "return value is an unspecified object implicitly 
-convertible to an iterator..." Although this trick is expected to work transparently, it can 
-have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic 
-code.
+* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
+inconsistent with that of other sequences: that's not a problem in
+itself, but compare it for instance with "A vector is a kind of
+sequence that supports random access iterators"; though the intent is
+obvious one might argue that the wording used for arrays doesn't tell
+what an array is, and relies on the reader to infer that it is what
+the &lt;array&gt; header defines.
+</p>
+<p>
+* it would be desiderable to have a static const data member of type
+std::size_t, with value N, for usage as integral constant expression
 </p>
-
-
-
-<p><b>Rationale:</b></p>
 <p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
-was discussed in Portland and the consensus was that there appears to be
-no need for either change proposed in the paper.  The consensus opinion
-was that since the iterator could serve as its own proxy, there appears
-to be no need for the change. In general, "converts to" is undesirable
-because it interferes with template matching.
+* section 23.1 [lib.container.requirements] seem not to consider
+fixed-size containers at all, as it says: "[containers] control
+allocation and deallocation of these objects [the contained objects]
+through constructors, destructors, *insert and erase* operations"
+</p>
+<p>
+* max_size() isn't specified: the result is obvious but, technically,
+it relies on table 80: "size() of the largest possible container"
+which, again, doesn't seem to consider fixed size containers
 </p>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Post Toronto:  There does not at this time appear to be consensus with the Portland consensus. 
 </p>
 
 
+<p><i>[
+Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
+Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
+requirements? Alisdair will prepare a paper. Proposed Disposition: Open
+]</i></p>
+
+
 
 
 
 <hr>
-<h3><a name="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>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
+<h3><a name="595"></a>595. TR1/C++0x: fabs(complex&lt;T&gt;) redundant / wrongly specified</h3>
+<p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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>
 <p><b>Discussion:</b></p>
-        <p>
-
-C++ Standard Library  templates that take an allocator  as an argument
-are    required    to    call    the    <code>allocate()</code>    and
-<code>deallocate()</code>  members of the  allocator object  to obtain
-storage.  However, they do not appear to be required to call any other
-allocator      members      such     as      <code>construct()</code>,
-<code>destroy()</code>,           <code>address()</code>,          and
-<code>max_size()</code>.  This makes these allocator members less than
-useful in portable programs.
-
-        </p>
-        <p>
-
-It's unclear to me whether the absence of the requirement to use these
-allocator  members  is  an  unintentional  omission  or  a  deliberate
-choice. However,  since the functions exist in  the standard allocator
-and  since  they are  required  to  be  provided by  any  user-defined
-allocator I  believe the standard  ought to be clarified  to explictly
-specify  whether programs  should or  should not  be able  to  rely on
-standard containers calling the functions.
+<p>
+TR1 introduced, in the C compatibility chapter, the function
+fabs(complex&lt;T&gt;):
+</p>
+<blockquote><pre>----- SNIP -----
+8.1.1 Synopsis                                [tr.c99.cmplx.syn]
 
-        </p>
-        <p>
+  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
 
-I  propose  that all  containers  be required  to  make  use of  these
-functions.
+[...]
 
-        </p>
-<p><i>[
-Batavia:  We support this resolution.  Martin to provide wording.
-]</i></p>
+8.1.8 Function fabs                          [tr.c99.cmplx.fabs]
 
-<p><i>[
-pre-Oxford:  Martin provided wording.
-]</i></p>
+1 Effects: Behaves the same as C99 function cabs, defined in
+  subclause 7.3.8.1.
+----- SNIP -----
+</pre></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.
+</p>
+<p>
+But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
+n1124), the referenced subclause reads
+</p>
 
-    <p><b>Proposed resolution:</b></p>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<p>
+<blockquote><pre>----- SNIP -----
+7.3.8.1 The cabs functions
 
-Specifically, I propose to change 23.1 [container.requirements],
-p9 as follows:
+  Synopsis
 
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</p>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<blockquote>
-<p>
--9- Copy constructors &nbsp;for all container types defined &nbsp;in this clause
-<ins>that &nbsp;&nbsp;are &nbsp;parametrized &nbsp;on &nbsp;&nbsp;<code>Allocator</code></ins> &nbsp;copy
-<del>an</del><ins>the</ins> &nbsp;allocator argument from &nbsp;their respective
-first parameters.
+1 #include &lt;complex.h&gt;
+  double cabs(double complex z);
+  float cabsf(float complex z);
+  long double cabsl(long double z);
 
-All other &nbsp;constructors for &nbsp;these container types &nbsp;take a<del>n</del>
-<ins>const</ins> &nbsp;<code>Allocator&amp;</code> &nbsp;argument &nbsp;(20.1.6), &nbsp;an
-allocator whose <code>value_type</code> is the same as the container's
-<code>value_type</code>.
+  Description
 
-A copy of this &nbsp;argument <del>is</del><ins>shall be</ins> used for any
-memory &nbsp;allocation <ins> and &nbsp;deallocation</ins> performed<del>,</del>
-by these &nbsp;constructors and by all &nbsp;member functions<del>,</del> during
-the &nbsp;lifetime &nbsp;of each &nbsp;container &nbsp;object. &nbsp;&nbsp;<ins>Allocation shall &nbsp;be
-performed &nbsp;"as &nbsp;if" &nbsp;by &nbsp;calling &nbsp;the &nbsp;<code>allocate()</code> &nbsp;member
-function on &nbsp;a copy &nbsp;of the allocator &nbsp;object of the &nbsp;appropriate type
-<sup>New &nbsp;Footnote)</sup>, &nbsp;&nbsp;and &nbsp;deallocation &nbsp;"as &nbsp;&nbsp;if" &nbsp;by &nbsp;calling
-<code>deallocate()</code> on &nbsp;a copy of &nbsp;the same allocator &nbsp;object of
-the corresponding type.</ins>
+2 The cabs functions compute the complex absolute value (also called
+  norm, modulus, or magnitude) of z.
 
-<ins>A &nbsp;copy of &nbsp;this argument &nbsp;shall also &nbsp;be used &nbsp;to &nbsp;construct and
-destroy objects whose lifetime &nbsp;is managed by the container, including
-but not &nbsp;limited to those of &nbsp;the container's <code>value_type</code>,
-and &nbsp;to &nbsp;obtain &nbsp;their &nbsp;address. &nbsp;&nbsp;All &nbsp;objects &nbsp;residing &nbsp;in &nbsp;storage
-allocated by a &nbsp;container's allocator shall be constructed &nbsp;"as if" by
-calling the <code>construct()</code> member &nbsp;function on a copy of the
-allocator object of &nbsp;the appropriate type. &nbsp;The same &nbsp;objects shall be
-destroyed "as if" &nbsp;by calling <code>destroy()</code> on a &nbsp;copy of the
-same allocator object &nbsp;of the same type. &nbsp;The &nbsp;address of such objects
-shall be obtained "as if" by calling the <code>address()</code> member
-function &nbsp;on &nbsp;a &nbsp;copy &nbsp;of &nbsp;the allocator &nbsp;object &nbsp;of &nbsp;the &nbsp;appropriate
-type.</ins>
+  Returns
 
-<ins>Finally, a copy &nbsp;of this argument shall be &nbsp;used by its container
-object to determine &nbsp;the maximum number of objects &nbsp;of the container's
-<code>value_type</code> the container may &nbsp;store at the same time. The
-container &nbsp;member function <code>max_size()</code>
-obtains &nbsp;this number
-from &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;returned &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;by
-&nbsp;&nbsp;&nbsp;&nbsp;a &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;call
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to
-<code>get_allocator().max_size()</code>.</ins>
+3 The cabs functions return the complex absolute value.
+----- SNIP -----
+</pre></blockquote>
 
-In &nbsp;&nbsp;all &nbsp;container &nbsp;&nbsp;types &nbsp;defined &nbsp;&nbsp;in &nbsp;this &nbsp;&nbsp;clause <ins>that &nbsp;are
-parametrized &nbsp;&nbsp;&nbsp;&nbsp;on &nbsp;&nbsp;&nbsp;<code>Allocator</code></ins>, &nbsp;&nbsp;&nbsp;&nbsp;the &nbsp;&nbsp;&nbsp;member
-<code>get_allocator()</code> &nbsp;&nbsp;&nbsp;&nbsp;returns
-&nbsp;&nbsp;&nbsp;&nbsp;a &nbsp;&nbsp;&nbsp;&nbsp;copy
-&nbsp;&nbsp;&nbsp;&nbsp;of &nbsp;&nbsp;&nbsp;&nbsp;the
-<code>Allocator</code> &nbsp;&nbsp;&nbsp;&nbsp;object
-&nbsp;&nbsp;&nbsp;&nbsp;used &nbsp;&nbsp;&nbsp;&nbsp;to
-&nbsp;&nbsp;&nbsp;construct &nbsp;&nbsp;&nbsp;&nbsp;the
-container.<sup>258)</sup>
+<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).
 </p>
 <p>
-New Footnote: This type &nbsp;may be different from <code>Allocator</code>:
-it &nbsp;&nbsp;&nbsp;&nbsp;may &nbsp;&nbsp;&nbsp;be
-&nbsp;&nbsp;&nbsp;&nbsp;derived &nbsp;&nbsp;&nbsp;from
-&nbsp;&nbsp;&nbsp;&nbsp;<code>Allocator</code> &nbsp;&nbsp;&nbsp;via
-<code>Allocator::rebind&lt;U&gt;::other</code> &nbsp;&nbsp;for &nbsp;the &nbsp;appropriate
-type <code>U</code>.
+So either the return value of fabs() is specified wrongly, or fabs()
+does not behave the same as C99's cabs*().
 </p>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</blockquote>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<p>
-The proposed wording seems cumbersome but I couldn't think of a better
-way &nbsp;&nbsp;to &nbsp;describe &nbsp;&nbsp;the
-&nbsp;&nbsp;requirement &nbsp;that &nbsp;&nbsp;containers &nbsp;use
-&nbsp;&nbsp;their
-<code>Allocator</code> &nbsp;to manage &nbsp;only objects &nbsp;(regardless &nbsp;of their
-type) &nbsp;that &nbsp;persist &nbsp;over &nbsp;their &nbsp;lifetimes &nbsp;and &nbsp;not, &nbsp;for &nbsp;example,
-temporaries &nbsp;created on the &nbsp;stack. That &nbsp;is, containers &nbsp;shouldn't be
-required &nbsp;to &nbsp;call &nbsp;<code>Allocator::construct(Allocator::allocate(1),
-elem)</code> &nbsp;just to &nbsp;construct a &nbsp;temporary copy &nbsp;of an &nbsp;element, or
-<code>Allocator::destroy(Allocator::address(temp), &nbsp;&nbsp;&nbsp;&nbsp;1)</code> &nbsp;&nbsp;&nbsp;to
-destroy temporaries.
-
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</p>
-
 
-<p><i>[
-Howard: This same paragraph will need some work to accommodate <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
-]</i></p>
+<b>Possible Resolutions</b>
 
+<p>
+This depends on the intention behind the introduction of fabs().
+</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.
+</p>
+<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
+</p>
+<blockquote><pre>  complex&lt;double&gt; x, y;
+  y = fabs(x);
+  complex&lt;double&gt; z(fabs(x));
+</pre></blockquote>
+<p>
+and
+</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>
 
 <p><i>[
-post Oxford:  This would be rendered NAD Editorial by acceptance of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
+Bellevue:
 ]</i></p>
 
 
+<blockquote>
+Bill believes that abs() is a suitable overload. We should remove fabs().
+</blockquote>
 
 
+<p><b>Proposed resolution:</b></p>
 
-<hr>
-<h3><a name="581"></a>581. <code>flush()</code> not unformatted function</h3>
-<p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <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> 2006-06-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</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 resolution of issue 60 changed <code>basic_ostream::flush()</code>
-so as not  to require it to behave as  an unformatted output function.
-That has at least two in my opinion problematic consequences:
-
-        </p>
-        <p>
-
-First, <code>flush()</code>  now calls <code>rdbuf()-&gt;pubsync()</code>
-unconditionally, without  regard to the  state of the stream.  I can't
-think of any reason why <code>flush()</code> should behave differently
-from the vast majority of stream functions in this respect.
-
-        </p>
-        <p>
-
-Second, <code>flush()</code> is not  required to catch exceptions from
-<code>pubsync()</code> or set  <code>badbit</code> in response to such
-events. That doesn't seem right either, as most other stream functions
-do so.
-
-        </p>
-    
-
-    <p><b>Proposed resolution:</b></p>
-        <p>
+<p>
+Change the synopsis in 26.3.1 [complex.synopsis]:
+</p>
 
-I  propose  to revert  the  resolution of  issue  60  with respect  to
-<code>flush()</code>. Specifically,  I propose to  change 27.6.2.6, p7
-as follows:
+<blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);</del>
+</pre></blockquote>
 
-        </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>
-Effects: <ins>Behaves as an  unformatted output function (as described
-in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null
-pointer,  <ins>constructs a  sentry  object.  If  this object  returns
-<code>true</code> when converted to a  value of type bool the function
-</ins>calls <code>rdbuf()-&gt;pubsync()</code>.  If that function returns
--1    calls    <code>setstate(badbit)</code>    (which    may    throw
-<code>ios_base::failure</code>  (27.4.4.3)).   <ins>Otherwise, if  the
-sentry object returns <code>false</code>, does nothing.</ins><del>Does
-not  behave  as  an  unformatted  output  function  (as  described  in
-27.6.2.6, paragraph 1).</del>
+<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): Proposed Disposition: Ready
+Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>. 
+Proposed Disposition: Ready
 ]</i></p>
 
 
@@ -6184,387 +6791,3164 @@ Kona (2007): Proposed Disposition: Ready
 
 
 <hr>
-<h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
-<p><b>Section:</b> 20.6.4.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 other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#uninitialized.copy">active issues</a> in [uninitialized.copy].</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>
+<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>
-
-The specialized  algorithms [lib.specialized.algorithms] are specified
-as having the general effect of invoking the following expression:
-
-        </p>
-            <pre>
-new (static_cast&lt;void*&gt;(&amp;*i))
-    typename iterator_traits&lt;ForwardIterator&gt;::value_type (x)
-
-            </pre>
-        <p>
-
-This  expression is  ill-formed  when the  type  of the  subexpression
-<code>&amp;*i</code> is some volatile-qualified <code>T</code>.
-
-        </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>[
-Batavia:  Lack of support for proposed resolution but agree there is a
-defect.  Howard to look at wording.  Concern that move semantics
-properly expressed if iterator returns rvalue.
+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>
 
-In order  to allow these algorithms  to operate on  volatile storage I
-propose to change the expression so as to make it well-formed even for
-pointers  to volatile  types.  Specifically,  I propose  the following
-changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
+</p>
 
-        </p>
-            <pre>
-<i>Effects</i>:
+<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:
+</p>
+<blockquote><p>...was it a deliberate design choice to make narrowing
+assignments ill-formed while permitting narrowing compound assignments?
+For instance:
+</p></blockquote>
+<pre>      decimal32 d32;
+      decimal64 d64;
+
+      d32 = 64;     // error
+      d32 += 64;    // okay
+</pre>
+<p>
+In c++std-lib-17229, Robert responds:
+</p>
+<blockquote><p>It is a vestige of an old idea that I forgot to remove
+from the paper. Narrowing assignments should be permitted. The bug is
+that the converting constructors that cause narrowing should not be
+explicit. Thanks for pointing this out.
+</p></blockquote>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+1.  In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
+</p>
+<pre>                // <i>3.2.2.2 conversion from floating-point type:</i>
+                <del>explicit</del> decimal32(decimal64 <i>d64</i>);
+                <del>explicit</del> decimal32(decimal128 <i>d128</i>);
+</pre>
+<p>
+2.  Do the same thing in "3.2.2.2. Conversion from floating-point type."
+</p>
+<p>
+3.  In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
+</p>
+<pre>                // <i>3.2.3.2 conversion from floating-point type:</i>
+                <del>explicit</del> decimal64(decimal128 <i>d128</i>);
+</pre>
+<p>
+4.  Do the same thing in "3.2.3.2. Conversion from floating-point type."
+</p>
+
+<p><i>[
+Redmond: We prefer explicit conversions for narrowing and implicit for widening.
+]</i></p>
+
+
+
+
+
+
+<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>
+<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#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+This is based on N2134, where 21.3.1/2 states:
+"... The Allocator object used shall be a copy of the Allocator object 
+passed to the basic_string object's constructor or, if the constructor does 
+not take an Allocator argument, a copy of a default-constructed Allocator 
+object."
+</p>
+<p>
+Section 21.3.2/1 lists two constructors:
+</p>
+<blockquote><pre>basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str );
+
+basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str ,
+             size_type pos , size_type n = npos,
+             const Allocator&amp; a = Allocator());
+</pre></blockquote>
+<p>
+and then says "In the first form, the Allocator value used is copied from 
+str.get_allocator().", which isn't an option according to 21.3.1.
+</p>
+<p><i>[
+Batavia:  We need blanket statement to the effect of:
+]</i></p>
+
+
+<ol>
+<li>If an allocator is passed in, use it, or,</li>
+<li>If a string is passed in, use its allocator.</li>
+</ol>
+<p><i>[
+Review constructors and functions that return a string; make sure we follow these
+rules (substr, operator+, etc.).  Howard to supply wording.
+]</i></p>
+
+
+<p><i>[
+Bo adds:  The new container constructor which takes only a <tt>size_type</tt> is not
+consistent with 23.1 [container.requirements], p9 which says in part:
+
+<blockquote>
+All other constructors for these container types take an
+<tt>Allocator&amp;</tt> argument (20.1.2), an allocator whose value type
+is the same as the container's value type. A copy of this argument is
+used for any memory allocation performed, by these constructors and by
+all member functions, during the lifetime of each container object.
+</blockquote>
+]</i></p>
+
+
+<p><i>[
+post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
+<p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The <tt>&lt;array&gt;</tt> header is given under 23.2 [sequences].
+23.2.1 [array]/paragraph 3 says:
+</p>
+<blockquote><p>
+"Unless otherwise specified, all array operations are as described in
+23.1 [container.requirements]".
+</p></blockquote>
+<p>
+However, array isn't mentioned at all in section 23.1 [container.requirements].
+In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear) 
+that std::array does not have in 23.2.1 [array].
+</p>
+<p>
+Also, Table 83 "Optional sequence operations" lists several operations that 
+std::array does have, but array isn't mentioned.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<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>
+<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>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.5.2.7 [valarray.members], paragraph 10:
+</p>
+
+<blockquote>
+
+<pre>valarray&lt;T&gt; cshift(int <i>n</i>) const;
+</pre>
+
+<blockquote>
+<p>
+This function returns an object of class <tt>valarray&lt;T&gt;</tt>, of
+length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is
+<tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as
+the leftmost element, a positive value of <i>n</i> shifts the elements
+circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If
+element zero is taken as the leftmost element, a non-negative value of
+<i>n</i> shifts the elements circularly left <i>n</i> places and a
+negative value of <i>n</i> shifts the elements circularly right
+-<i>n</i> places.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+We do not believe that there is any real ambiguity about what happens
+when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++
+expression causes more trouble that it solves. The expression is
+certainly wrong when <tt>n &lt; 0</tt>, since the sign of % with negative arguments
+is implementation defined.
+</p>
+
+
+<p><i>[
+Kona (2007) Changed proposed wording, added rationale and set to Review.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="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.
+</p>
+<p>
+Solve the problem for ordered sequences in general, perhaps with a
+dedicated facet.  Then complex should use that solution.
+</p>
+</blockquote>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+After much discussion, we agreed on the following: Add a footnote:
+</p>
+<p>
+[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
+an explicit decimal point character; then all inserted complex sequences
+will extract unambiguously.]
+</p>
+<p>
+And move this to READY status.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a footnote to 26.3.6 [complex.ops] p16:
+</p>
+
+<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
+an explicit decimal point character; then all inserted complex sequences
+will extract unambiguously.]
+</blockquote>
+
+
+
+
+
+<hr>
+<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 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>
+        <p>
+
+Section 26.1 [numeric.requirements], p1     suggests     that     a
+<code>valarray</code>  specialization on  a  type <code>T</code>  that
+satisfies  the requirements enumerated  in the  paragraph is  itself a
+valid  type   on  which  <code>valarray</code>   may  be  instantiated
+(Footnote       269        makes       this       clear).        I.e.,
+<code>valarray&lt;valarray&lt;T&gt;  &gt;</code> is  valid as  long as
+<code>T</code>   is   valid.    However,  since   implementations   of
+<code>valarray</code> are permitted to initialize storage allocated by
+the class by  invoking the default ctor of  <code>T</code> followed by
+the    copy    assignment    operator,   such    implementations    of
+<code>valarray</code>   wouldn't  work  with   (perhaps  user-defined)
+specializations of <code>valarray</code> whose assignment operator had
+undefined behavior when the size of its argument didn't match the size
+of <code>*this</code>.  By <i>"wouldn't work"</i> I mean that it would
+be  impossible  to resize  such  an array  of  arrays  by calling  the
+<code>resize()</code> member  function on it if the  function used the
+copy  assignment operator  after constructing  all elements  using the
+default  ctor (e.g.,  by invoking  <code>new  value_type[N]</code>) to
+obtain default-initialized storage) as it's permitted to do.
+
+        </p>
+        <p>
+
+Stated      more     generally,      the      problem     is      that
+<code>valarray&lt;valarray&lt;T&gt;  &gt;::resize(size_t)</code> isn't
+required or  guaranteed to have well-defined semantics  for every type
+<code>T</code>     that      satisfies     all     requirements     in
+26.1 [numeric.requirements].
+
+        </p>
+        <p>
+
+I  believe  this  problem  was  introduced  by  the  adoption  of  the
+resolution                outlined                in                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
+<i>Assignment  of  valarrays</i>,  from  1996.   The  copy  assignment
+operator  of  the original  numerical  array  classes  proposed in  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0280.pdf">N0280</a>,
+as      well       as      the      one       proposed      in      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
+(both  from 1993), had  well-defined semantics  for arrays  of unequal
+size (the  latter explicitly  only when <code>*this</code>  was empty;
+assignment of non empty arrays of unequal size was a runtime error).
+
+        </p>
+        <p>
+
+The  justification for  the  change given  in  N0857 was the "loss  of
+performance [deemed]  only significant  for very simple  operations on
+small arrays or for architectures with very few registers."
+
+        </p>
+        <p>
+
+Since tiny  arrays on a  limited subset of hardware  architectures are
+likely  to  be  an   exceedingly  rare  case  (despite  the  continued
+popularity of  x86) I  propose to revert  the resolution and  make the
+behavior    of   all   <code>valarray</code>    assignment   operators
+well-defined even  for non-conformal  arrays (i.e., arrays  of unequal
+size).   I have implemented  this change  and measured  no significant
+degradation  in performance in  the common  case (non-empty  arrays of
+equal size).  I  have measured a 50% (and in  some cases even greater)
+speedup  in the  case of  assignments to  empty arrays  versus calling
+<code>resize()</code>  first followed  by  an invocation  of the  copy
+assignment operator.
+
+        </p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+If no proposed wording by June meeting, this issue should be closed NAD.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+        <p>
+
+Change 26.5.2.2 [valarray.assign], p1 as follows:
+
+        </p>
+        <blockquote>
+            <p>
+                <code>
+
+valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;<ins> x</ins>);
+
+                </code>
+            </p>
+            <p>
+
+-1- Each element of the <code>*this</code> array is assigned the value
+of  the  corresponding  element   of  the  argument  array.   <del>The
+resulting behavior is undefined if </del><ins>When </ins>the length of
+the  argument  array  is  not   equal  to  the  length  of  the  *this
+array<del>.</del><ins>  resizes  <code>*this</code>  to make  the  two
+arrays     the      same     length,     as      if     by     calling
+<code>resize(x.size())</code>, before performing the assignment.</ins>
+
+            </p>
+        </blockquote>
+        <p>
+
+And  add a new  paragraph just  below paragraph  1 with  the following
+text:
+
+        </p>
+        <blockquote>
+            <p>
+
+<ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
+
+            </p>
+        </blockquote>
+        <p>
+
+Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4:
+
+        </p>
+        <blockquote>
+            <p>
+
+<ins>-?- When the length,  <i><code>N</code></i> of the array referred
+to by the  argument is not equal to  the length of <code>*this</code>,
+the  operator resizes <code>*this</code>  to make  the two  arrays the
+same  length, as if  by calling  <code>resize(<i>N</i>)</code>, before
+performing the assignment.</ins>
+
+            </p>
+        </blockquote>
+
+
+<p><i>[
+Kona (2007): Gaby to propose wording for an alternative resolution in
+which you can assign to a <tt>valarray</tt> of size 0, but not to any other
+<tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3>
+<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> James Kanze <b>Date:</b> 2007-01-31</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for
+some functions. In particular, it says that:
+</p>
+
+<blockquote><p>
+[...] if an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt>
+as its argument and <tt><i>first1</i></tt> and <i>first2</i> as its
+iterator arguments, it should work correctly in the construct <tt>if
+(binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt>.
+<tt>BinaryPredicate</tt> always takes the first iterator type as its
+first argument, that is, in those cases when <tt>T <i>value</i></tt> is
+part of the signature, it should work correctly in the context of <tt>if
+(binary_pred (*<i>first1</i> , <i>value</i>)){...}</tt>.
+</p></blockquote>
+
+<p>
+In the description of <tt>upper_bound</tt> (25.3.3.2 [upper.bound]/2), however, the use is described as
+"<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an
+element of the sequence (a result of dereferencing
+<tt>*<i>first</i></tt>).
+</p>
+
+<p>
+In the description of <tt>lexicographical_compare</tt>, we have both
+"<tt>*<i>first1</i> &lt; *<i>first2</i></tt>" and "<tt>*<i>first2</i>
+&lt; *<i>first1</i></tt>" (which presumably implies "<tt>comp(
+*<i>first1</i>, *<i>first2</i> )</tt>" and "<tt>comp( *<i>first2</i>,
+*<i>first1</i> )</tt>".
+</p>
+
+<p><i>[
+Toronto:  Moved to Open.  ConceptGCC seems to get <tt>lower_bound</tt>
+and <tt>upper_bound</tt> to work withoutt these changes.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Logically, the <tt>BinaryPredicate</tt> is used as an ordering
+relationship, with the semantics of "less than".  Depending on the
+function, it may be used to determine equality, or any of the inequality
+relationships; doing this requires being able to use it with either
+parameter first.  I would thus suggest that the requirement be:
+</p>
+
+<blockquote><p>
+[...] <tt>BinaryPredicate</tt> always takes the first iterator
+<tt>value_type</tt> as one of its arguments, it is unspecified which. If
+an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt> as its
+argument and <tt><i><i>first1</i></i></tt> and <i>first2</i> as its
+iterator arguments, it should work correctly both in the construct
+<tt>if (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt> and
+<tt>if (binary_pred (*<i>first2</i>, *<i>first1</i>)){...}</tt>.  In
+those cases when <tt>T <i>value</i></tt> is part of the signature, it
+should work correctly in the context of <tt>if (binary_pred
+(*<i>first1</i> , <i>value</i>)){...}</tt> and of <tt>if (binary_pred
+(<i>value</i>, *<i>first1</i>)){...}</tt>. [<i>Note:</i> if the two
+types are not identical, and neither is convertable to the other, this
+may require that the <tt>BinaryPredicate</tt> be a functional object
+with two overloaded <tt>operator()()</tt> functions. <i>--end note</i>]
+</p></blockquote>
+
+<p>
+Alternatively, one could specify an order for each function. IMHO, this
+would be more work for the committee, more work for the implementors,
+and of no real advantage for the user: some functions, such as
+<tt>lexicographical_compare</tt> or <tt>equal_range</tt>, will still require both
+functions, and it seems like a much easier rule to teach that both
+functions are always required, rather than to have a complicated list of
+when you only need one, and which one.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="632"></a>632. Time complexity of size() for std::set</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> Lionel B <b>Date:</b> 2007-02-01</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>
+A recent news group discussion:
+</p>
+<blockquote>
+<p>
+Anyone know if the Standard has anything to say about the time complexity
+of size() for std::set?   I need to access a set's size (/not/ to know if it is empty!) heavily
+during an algorithm and was thus wondering whether I'd be better off
+tracking the size "manually" or whether that'd be pointless.
+</p>
+<p>
+That would be pointless. size() is O(1).
+</p>
+<p>
+Nit: the standard says "should" have constant time. Implementations may take
+license to do worse. I know that some do this for <tt>std::list&lt;&gt;</tt> as a part of
+some trade-off with other operation.
+</p>
+
+<p>
+I was aware of that, hence my reluctance to use size() for std::set.
+</p>
+<p>
+However, this reason would not apply to <tt>std::set&lt;&gt;</tt> as far as I can see.
+</p>
+<p>
+Ok, I guess the only option is to try it and see...
+</p>
+</blockquote>
+
+<p>
+If I have any recommendation to the C++ Standards Committee it is that
+implementations must (not "should"!) document clearly[1], where known, the
+time complexity of *all* container access operations.
+</p>
+<p>
+[1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()
+for std::set is not documented... but if it is it's certainly well hidden
+away.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+<p><i>[
+Kona (2007): This issue affects all the containers. We'd love to see a
+paper dealing with the broad issue. We think that the complexity of the
+<tt>size()</tt> member of every container -- except possibly <tt>list</tt> -- should be
+O(1). Alan has volunteered to provide wording.
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Mandating O(1) size will not fly, too many implementations would be
+invalidated. Alan to provide wording that toughens wording, but that
+does not absolutely mandate O(1).
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="635"></a>635. domain of <tt>allocator::address</tt></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> Howard Hinnant <b>Date:</b> 2007-02-08</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The table of allocator requirements in 20.1.2 [allocator.requirements] describes
+<tt>allocator::address</tt> as:
+</p>
+<blockquote><pre>a.address(r)
+a.address(s)
+</pre></blockquote>
+<p>
+where <tt>r</tt> and <tt>s</tt> are described as:
+</p>
+<blockquote><p>
+a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>. 
+</p></blockquote>
+
+<p>
+and <tt>p</tt> is 
+</p>
+
+<blockquote><p>
+a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>, 
+where <tt>a1 == a</tt>
+</p></blockquote>
+
+<p>
+This all implies that to get the address of some value of type <tt>T</tt> that
+value must have been allocated by this allocator or a copy of it.
+</p>
+
+<p>
+However sometimes container code needs to compare the address of an external value of
+type <tt>T</tt> with an internal value.  For example <tt>list::remove(const T&amp; t)</tt>
+may want to compare the address of the external value <tt>t</tt> with that of a value
+stored within the list.  Similarly <tt>vector</tt> or <tt>deque insert</tt> may
+want to make similar comparisons (to check for self-referencing calls).
+</p>
+
+<p>
+Mandating that <tt>allocator::address</tt> can only be called for values which the
+allocator allocated seems overly restrictive.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.1.2 [allocator.requirements]:
+</p>
+
+<blockquote>
+<p>
+<tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
+</p>
+<p>
+<tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the 
+expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
+</p>
+</blockquote>
+
+<p><i>[
+post Oxford:  This would be rendered NAD Editorial by acceptance of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
+]</i></p>
+
+
+<p><i>[
+Kona (2007):  This issue is section 8 of N2387.  There was some discussion of it but
+no resolution to this issue was recorded.  Moved to Open.
+]</i></p>
+
+
+
+
+
+
+
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The standard states at 23.2.2.3 [deque.modifiers]/4:
+</p>
+<blockquote><pre>deque erase(...)
+</pre>
+ <p>
+<i>Effects:</i> ... An erase at either end of the deque invalidates only
+the iterators and the references to the erased elements.
+</p>
+</blockquote>
+<p>
+This does not state that iterators to end will be invalidated.
+It needs to be amended in such a way as to account for end invalidation.
+</p>
+<p>
+Something like:
+</p>
+<blockquote><p>
+Any time the last element is erased, iterators to end are invalidated.
+</p></blockquote>
+
+<p>
+This would handle situations like:
+</p>
+<blockquote><pre>erase(begin(), end())
+erase(end() - 1)
+pop_back()
+resize(n, ...) where n &lt; size()
+pop_front() with size() == 1
+
+</pre></blockquote>
+
+<p><i>[
+Post Kona, Steve LoBasso notes:
+]</i></p>
+
+
+<blockquote>
+My only issue with the proposed resolution is that it might not be clear
+that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end
+iterators.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 23.2.2.3 [deque.modifiers], p4:
+</p>
+
+<blockquote>
+<pre>iterator erase(const_iterator position); 
+iterator erase(const_iterator first, const_iterator last);
+</pre>
+
+<blockquote>
+<p>
+-4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt>
+invalidates all the iterators and references to elements of the
+<tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at
+either end of the <tt>deque</tt> invalidates only the iterators and the
+references to the erased elements<ins>, except that erasing at the end
+also invalidates the past-the-end iterator</ins>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+<p><i>[
+Kona (2007): Proposed wording added and moved to Review.
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Note that there is existing code that relies on iterators not being
+invalidated, but there are also existing implementations that do
+invalidate iterators. Thus, such code is not portable in any case. There
+is a pop_front() note, which should possibly be a separate issue. Mike
+Spertus to evaluate and, if need be, file an issue.
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="659"></a>659. istreambuf_iterator should have an operator-&gt;()</h3>
+<p><b>Section:</b> 24.5.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-03-25</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Greg Herlihy has clearly demonstrated that a user defined input
+iterator should have an operator-&gt;(), even if its
+value type is a built-in type (comp.std.c++, "Re: Should any iterator
+have an operator-&gt;() in C++0x?", March 2007).  And as Howard
+Hinnant remarked in the same thread that the input iterator
+<tt>istreambuf_iterator</tt> doesn't have one, this must be a
+defect!
+</p>
+<p>
+Based on Greg's example, the following code demonstrates the issue:
+</p><pre> #include &lt;iostream&gt; 
+ #include &lt;fstream&gt;
+ #include &lt;streambuf&gt; 
+
+ typedef char C;
+ int main ()
+ {
+   std::ifstream s("filename", std::ios::in);
+   std::istreambuf_iterator&lt;char&gt; i(s);
+
+   (*i).~C();  // This is well-formed...
+   i-&gt;~C();  // ... so this should be supported!
+ }
+</pre>
+
+<p>
+Of course, operator-&gt; is also needed when the value_type of
+istreambuf_iterator is a class.
+</p>
+<p>
+The operator-&gt; could be implemented in various ways.  For instance,
+by storing the current value inside the iterator, and returning its
+address.  Or by returning a proxy, like operator_arrow_proxy, from
+<a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
+</p>
+<p>
+I hope that the resolution of this issue will contribute to getting a
+clear and consistent definition of iterator concepts.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to the synopsis in 24.5.3 [istreambuf.iterator]:
+</p>
+
+<blockquote><pre>charT operator*() const;
+<ins>pointer operator-&gt;() const;</ins>
+istreambuf_iterator&lt;charT,traits&gt;&amp; operator++();
+</pre></blockquote>
+
+<p>
+Change 24.5.3 [istreambuf.iterator], p1:
+</p>
+
+<blockquote><p>
+The class template <tt>istreambuf_iterator</tt> reads successive
+characters from the <tt>streambuf</tt> for which it was constructed.
+<tt>operator*</tt> provides access to the current input character, if
+any. <ins><tt>operator-&gt;</tt> may return a proxy.</ins> Each time
+<tt>operator++</tt> is evaluated, the iterator advances to the next
+input character. If the end of stream is reached
+(<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
+iterator becomes equal to the end of stream iterator value. The default
+constructor <tt>istreambuf_iterator()</tt> and the constructor
+<tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
+object suitable for use as an end-of-range.
+</p></blockquote>
+
+
+
+<p><i>[
+Kona (2007): The proposed resolution is inconsistent because the return
+type of <tt>istreambuf_iterator::operator-&gt;()</tt> is specified to be <tt>pointer</tt>,
+but the proposed text also states that "<tt>operator-&gt;</tt> may return a proxy."
+]</i></p>
+
+
+<p><i>[
+Niels Dekker (mailed to Howard Hinnant):
+]</i></p>
+
+<blockquote>
+<p>
+The proposed resolution does
+not seem inconsistent to me. <tt>istreambuf_iterator::operator-&gt;()</tt> should
+have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
+may in fact be a proxy.
+</p>
+<p>
+AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt>
+unspecified for some iterator categories") implies that for any iterator
+class <tt>Iter</tt>, the return type of <tt>operator-&gt;()</tt> is <tt>Iter::pointer</tt>, by
+definition.  I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
+</p>
+<p>
+Still I wouldn't mind if the text "<tt>operator-&gt;</tt> may return a proxy" would
+be removed from the resolution. I think it's up to the library
+implementation, how to implement <tt>istreambuf_iterator::operator-&gt;()</tt>.  As
+longs as it behaves as expected: <tt>i-&gt;m</tt> should have the same effect as
+<tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i-&gt;~C()</tt>.  The main issue
+is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</tt>!
+</p>
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3>
+<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
+</p>
+
+<blockquote><p>
+The result is returned as an integral value 
+stored in <tt>units</tt> or as a sequence of digits possibly preceded by a 
+minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range 
+from '0' through '9', inclusive) stored in <tt>digits</tt>.
+</p></blockquote>
+
+<p>
+The following
+objection has been raised:
+</p>
+
+<blockquote><p>
+Some implementations interpret this to mean that a facet derived from
+<tt>ctype&lt;wchar_t&gt;</tt> can provide its own member <tt>do_widen(char)</tt>
+which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
+<tt>'@'</tt> symbol will appear in the resulting sequence of digits.  Other
+implementations have assumed that one or more places in the standard permit the
+implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign.  Are
+both interpretations permissible, or only  one?
+</p></blockquote>
+
+<p>
+[Plum ref _222612Y14]
+</p>
+
+<p>
+Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
+parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
+</p>
+
+<p><i>[
+Kona (2007): Bill and Dietmar to provide proposed wording.
+]</i></p>
+
+
+<p><i>[
+post Bellevue: Bill adds:
+]</i></p>
+
+
+<blockquote>
+The Standard is clear that the minus sign stored in <tt>digits</tt> is <tt>ct.widen('-')</tt>.
+The subject string must contain characters <tt>c</tt> in the set <tt>[-0123456789]</tt>
+which are translated by <tt>ct.widen(c)</tt> calls before being stored in <tt>digits</tt>;
+the widened characters are not relevant to the parsing of the subject string.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
+<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
+</p>
+
+<blockquote><p>
+If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
+optional, and if no sign is detected, the result is given the sign 
+that corresponds to the source of the empty string.
+</p></blockquote>
+
+<p>
+The following
+objection has been raised:
+</p>
+
+<blockquote><p>
+A <tt>negative_sign</tt> of "" means "there is no 
+way to write a negative sign" not "any null sequence is a negative 
+sign, so it's always there when you look for it".
+</p></blockquote>
+
+<p>
+[Plum ref _222612Y32]
+</p>
+
+<p><i>[
+Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
+<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
+</p>
+
+<blockquote><p>
+If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>, 
+or if both strings are empty, the result is given a positive sign.
+</p></blockquote>
+
+<p>
+One interpretation is that an input sequence must match either the
+positive pattern or the negative pattern, and then in either event it
+is interpreted as positive.  The following objections has been raised:
+</p>
+
+<blockquote><p>
+The input can successfully match only a positive sign, so the negative
+pattern is an unsuccessful match.
+</p></blockquote>
+
+<p>
+[Plum ref _222612Y34, 222612Y51b]
+</p>
+
+<p><i>[
+Bill to provide proposed wording and interpretation of existing wording.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
+<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>Discussion:</b></p>
+<p>
+22.2.6.3 [locale.moneypunct], para 2 says:
+</p>
+
+<blockquote><p>
+The value <tt>space</tt> indicates that at least one space is required at 
+that position.
+</p></blockquote>
+
+<p>
+The following objection has been raised:
+</p>
+
+<blockquote><p>
+Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
+</p></blockquote>
+
+<p>
+[Plum ref _22263Y22]
+</p>
+
+<p><i>[
+Kona (2007): Bill to provide proposed wording. We agree that C++03 is
+ambiguous, and that we want C++0X to say "space" means 0 or more
+whitespace characters on input.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="671"></a>671. precision of hexfloat</h3>
+<p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> John Salmon <b>Date:</b> 2007-04-20</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I am trying to understand how TR1 supports hex float (%a) output.
+</p>
+<p>
+As far as I can tell, it does so via the following:
+</p>
+<p>
+8.15 Additions to header &lt;locale&gt; [tr.c99.locale]
+</p>
+<p>
+In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
+the line:
+floatfield == ios_base::scientific %E
+</p>
+<p>
+add the two lines:
+</p>
+<blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase %a
+floatfield == ios_base::fixed | ios_base::scientific %A 2
+</pre></blockquote>
+<p>
+[Note: The additional requirements on print and scan functions, later
+in this clause, ensure that the print functions generate hexadecimal
+floating-point fields with a %a or %A conversion specifier, and that
+the scan functions match hexadecimal floating-point fields with a %g
+conversion specifier. &nbsp;end note]
+</p>
+<p>
+Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
+</p>
+<p>
+For conversion from a floating-point type, if (flags &amp; fixed) != 0 or
+if str.precision() &gt; 0, then str.precision() is specified in the
+conversion specification.
+</p>
+<p>
+This would seem to imply that when floatfield == fixed|scientific, the
+precision of the conversion specifier is to be taken from
+str.precision(). &nbsp;Is this really what's intended? &nbsp;I sincerely hope
+that I'm either missing something or this is an oversight. &nbsp;Please
+tell me that the committee did not intend to mandate that hex floats
+(and doubles) should by default be printed as if by %.6a.
+</p>
+
+<p><i>[
+Howard: I think the fundamental issue we overlooked was that with %f,
+%e, %g, the default precision was always 6. &nbsp;With %a the default
+precision is not 6, it is infinity. &nbsp;So for the first time, we need to
+distinguish between the default value of precision, and the precision
+value 6.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+<p><i>[
+Kona (2007): Robert volunteers to propose wording.
+]</i></p>
+
+
+
+
+
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The current <tt>Swappable</tt> is:
+</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>
+
+<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.
+</p>
+
+<p>
+Additionally we may want to support proxy references such that the following code is acceptable:
+</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>.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change 20.1.1 [utility.arg.requirements]:
+</p>
+
+<blockquote>
+
+<p>
+-1- The template definitions in the C++ Standard Library refer to various
+named requirements whose details are set out in tables 31-38. In these
+tables, <tt>T</tt> is a type to be supplied by a C++ program
+instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
+values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
+lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
+<tt>const</tt>) <tt>T</tt>; and <tt>rv</tt> is a non-<tt>const</tt>
+rvalue of type <tt>T</tt>.
+</p>
+
+<table border="1">
+<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
+<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
+<tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td>
+<td><tt>t</tt> has the value originally
+held by <tt>u</tt>, and
+<tt>u</tt> has the value originally held
+by <tt>t</tt></td></tr>
+<tr><td colspan="3">
+<p>
+The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
+</p>
+<ul>
+<li>
+<tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> satisfies the
+<del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins>
+requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</ins>
+requirements (Table <del>36</del> <ins>35</ins>);
+</li>
+<li>
+<tt>T</tt> is <tt>Swappable</tt> if a namespace scope function named
+<tt>swap</tt> exists in the same namespace as the definition of
+<tt>T</tt>, such that the expression
+<tt>swap(t,u)</tt> is valid and has the
+semantics described in this table.
+</li>
+</ul>
+</td></tr>
+</tbody></table>
+</blockquote>
+
+
+
+<p><i>[
+Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use
+move semantics. The issue relating to the support of proxies is
+separable from the one relating to move semantics, and it's bigger than
+just swap. We'd like to address only the move semantics changes under
+this issue, and open a separated issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>) to handle proxies. Also, there
+may be a third issue, in that the current definition of <tt>Swappable</tt> does
+not permit rvalues to be operands to a swap operation, and Howard's
+proposed resolution would allow the right-most operand to be an rvalue,
+but it would not allow the left-most operand to be an rvalue (some swap
+functions in the library have been overloaded to permit left operands to
+swap to be rvalues).
+]</i></p>
+
+
+
+
+
+<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>
+<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.
+</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.
+</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>
+
+<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.
+</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>
+
+
+<p><i>[
+Post Kona: Howard adds example user code related to the first bullet:
+]</i></p>
+
+
+<blockquote>
+<pre>void legacy_code(void*, std::size_t);
+
+void foo(std::size_t N)
+{
+    std::unique_ptr&lt;void, void(*)(void*)&gt; ptr(std::malloc(N), std::free);
+    legacy_code(ptr.get(), N);
+}   // unique_ptr used for exception safety purposes
+</pre>
+</blockquote>
+
+<p>
+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>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<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>
+
+
+<ul>
+<li>
+
+<p>
+Change 20.6.11.2 [unique.ptr.single]:
+</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;
+   ...
+};
+</pre></blockquote>
+
+<p>
+Change 20.6.11.2.4 [unique.ptr.single.observers]:
+</p>
+
+<blockquote><pre><del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
+</pre></blockquote>
+
+</li>
+
+<li>
+<p>
+Change 20.6.11.2 [unique.ptr.single]:
+</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>
+
+<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>.
+</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>
+-23- <i>Requires:</i> If <tt>D</tt> is not a reference type,
+construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
+<del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a
+reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt>
+(diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins>
+<del>must</del> <ins>shall</ins> be implicitly convertible to <del><tt>T*</tt></del>
+<ins>pointer</ins>.
+</p>
+
+<p>
+-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>
+
+<p>
+Change 20.6.11.2.3 [unique.ptr.single.asgn]:
+</p>
+
+<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>
+</blockquote>
+
+<p>
+Change 20.6.11.2.4 [unique.ptr.single.observers]:
+</p>
+
+<blockquote>
+<pre><del>T*</del> <ins>pointer</ins> operator-&gt;() const;</pre>
+...
+<pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
+</blockquote>
+
+<p>
+Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
+</p>
+
+<blockquote>
+<pre><del>T*</del> <ins>pointer</ins> release();</pre>
+...
+<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
+</blockquote>
+
+<p>
+Change 20.6.11.3 [unique.ptr.runtime]:
+</p>
+
+<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>
+
+<p>
+Change 20.6.11.3.1 [unique.ptr.runtime.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);
+</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>
+
+<p>
+Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
+</p>
+
+<blockquote>
+<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+</pre>
+
+<p>
+-1- <i>Requires:</i> Does not accept pointer types which are convertible
+to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
+required). [<i>Note:</i> One implementation technique is to create a private
+templated overload. <i>-- end note</i>]
+</p>
+</blockquote>
+
+</li>
+
+<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]:
+</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; 
+  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>
+
+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>
+Change 23.4.1 [unord.map]:
+</p>
+
+<blockquote><pre>class unordered_map
+{
+    ...
+    unordered_map(const unordered_map&amp;);
+    <ins>unordered_map(unordered_map&amp;&amp;);</ins>
+    ~unordered_map();
+    unordered_map&amp; operator=(const unordered_map&amp;);
+    <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
+    ...
+    // modifiers 
+    <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj); 
+    <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
+    iterator       insert(iterator hint, const value_type&amp; obj);
+    <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
+    const_iterator insert(const_iterator hint, const value_type&amp; obj);
+    <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
+    ...
+    void swap(unordered_map&amp;<ins>&amp;</ins>);
+    ...
+    mapped_type&amp; operator[](const key_type&amp; k);
+    <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
+    ...
+};
+
+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>
+Add to 23.4.1.1 [unord.map.cnstr]:
+</p>
+
+<blockquote>
+<pre>template &lt;class InputIterator&gt;
+  unordered_map(InputIterator f, InputIterator l, 
+                size_type n = <i>implementation-defined</i>, 
+                const hasher&amp; hf = hasher(), 
+                const key_equal&amp; eql = key_equal(), 
+                const allocator_type&amp; a = allocator_type());
+</pre>
+
+<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 to 23.4.1.2 [unord.map.elem]:
+</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>
+
+<blockquote>
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
+requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
+<tt>CopyConstructible</tt>.
+</ins></p>
+
+<p><ins>
+<tt>P</tt> shall be convertible to <tt>value_type</tt>.
+ If <tt>P</tt> is instantiated as a reference
+type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
+is considered to be an rvalue as it is converted to <tt>value_type</tt>
+and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
+cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
+<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
+requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
+mapped_type&gt;</tt>, then <tt>key_type</tt> must be
+<tt>CopyConstructible</tt>).
+</ins></p>
+
+<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.2.2 [unord.multimap.swap]:
+</p>
+
+<blockquote>
+<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
+            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
+<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
+            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
+<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
+            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
+</pre>
+</blockquote>
+
+<p><b><tt>unordered_set</tt></b></p>
+
+<p>
+Change 23.4.3 [unord.set]:
+</p>
+
+<blockquote><pre>class unordered_set
+{
+    ...
+    unordered_set(const unordered_set&amp;);
+    <ins>unordered_set(unordered_set&amp;&amp;);</ins>
+    ~unordered_set();
+    unordered_set&amp; operator=(const unordered_set&amp;);
+    <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
+    ...
+    // modifiers 
+    <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj); 
+    <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
+    iterator       insert(iterator hint, const value_type&amp; obj);
+    <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
+    const_iterator insert(const_iterator hint, const value_type&amp; obj);
+    <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
+    ...
+    void swap(unordered_set&amp;<ins>&amp;</ins>);
+    ...
+};
+
+template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
+            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
+
+<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
+            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
+
+<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
+            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
+</pre></blockquote>
+
+<p>
+Add to 23.4.3.1 [unord.set.cnstr]:
+</p>
+
+<blockquote>
+<pre>template &lt;class InputIterator&gt;
+  unordered_set(InputIterator f, InputIterator l, 
+                size_type n = <i>implementation-defined</i>, 
+                const hasher&amp; hf = hasher(), 
+                const key_equal&amp; eql = key_equal(), 
+                const allocator_type&amp; a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>value_type</tt>, then the
+<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
+
+<p>
+Add new section [unord.set.modifiers]:
+</p>
+
+<blockquote>
+<pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
+<ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; x);</ins>
+<ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
+<ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
+<ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
+<ins>template &lt;class InputIterator&gt;
+  void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+
+<blockquote>
+
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const
+value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
+be <tt>CopyConstructible</tt>.
+</ins></p>
+
+<p><ins>
+The signature taking <tt>InputIterator</tt> parameters requires
+<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
+
+</blockquote>
+
+</blockquote>
+
+<p>
+Add to 23.4.3.2 [unord.set.swap]:
+</p>
+
+<blockquote>
+<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
+            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
+<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
+            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
+<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
+            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
+</pre>
+</blockquote>
+
+<p><b><tt>unordered_multiset</tt></b></p>
+
+<p>
+Change 23.4.4 [unord.multiset]:
+</p>
+
+<blockquote><pre>class unordered_multiset
+{
+    ...
+    unordered_multiset(const unordered_multiset&amp;);
+    <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
+    ~unordered_multiset();
+    unordered_multiset&amp; operator=(const unordered_multiset&amp;);
+    <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
+    ...
+    // modifiers 
+    iterator insert(const value_type&amp; obj); 
+    <ins>iterator insert(value_type&amp;&amp; obj);</ins>
+    iterator       insert(iterator hint, const value_type&amp; obj);
+    <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
+    const_iterator insert(const_iterator hint, const value_type&amp; obj);
+    <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
+    ...
+    void swap(unordered_multiset&amp;<ins>&amp;</ins>);
+    ...
+};
+
+template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
+            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
+
+<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
+            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
+
+<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
+            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
+</pre></blockquote>
+
+<p>
+Add to 23.4.4.1 [unord.multiset.cnstr]:
+</p>
+
+<blockquote>
+<pre>template &lt;class InputIterator&gt;
+  unordered_multiset(InputIterator f, InputIterator l, 
+                size_type n = <i>implementation-defined</i>, 
+                const hasher&amp; hf = hasher(), 
+                const key_equal&amp; eql = key_equal(), 
+                const allocator_type&amp; a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>value_type</tt>, then the
+<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
+
+<p>
+Add new section [unord.multiset.modifiers]:
+</p>
+
+<blockquote>
+<pre><ins>iterator insert(const value_type&amp; x);</ins>
+<ins>iterator insert(value_type&amp;&amp; x);</ins>
+<ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
+<ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
+<ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
+<ins>template &lt;class InputIterator&gt;
+  void insert(InputIterator first, InputIterator last);</ins>
+</pre>
 
-typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
-typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
+<blockquote>
 
-for (; first != last; ++result, ++first)
-    new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*result))
-        value_type (*first);
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const
+value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
+be <tt>CopyConstructible</tt>.
+</ins></p>
 
-            </pre>
-        <p>
+<p><ins>
+The signature taking <tt>InputIterator</tt> parameters requires
+<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
 
-change 20.6.4.2, p1 to read
+</blockquote>
 
-        </p>
-            <pre>
-<i>Effects</i>:
+</blockquote>
 
-typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
-typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
+<p>
+Add to 23.4.4.2 [unord.multiset.swap]:
+</p>
 
-for (; first != last; ++result, ++first)
-    new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
-        value_type (*x);
+<blockquote>
+<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
+            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
+<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
+            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
+<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
+  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
+            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
+</pre>
+</blockquote>
 
-            </pre>
-        <p>
 
-and change 20.6.4.3, p1 to read
 
-        </p>
-            <pre>
-<i>Effects</i>:
+<p><i>[
+Voted to WP in Bellevue.
+]</i></p>
 
-typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
-typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
 
-for (; n--; ++first)
-    new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
-        value_type (*x);
+<p><i>[
+post Bellevue, Pete notes:
+]</i></p>
 
-            </pre>
-        <p>
 
-In   addition,  since   there   is  no   partial  specialization   for
-<code>iterator_traits&lt;volatile T*&gt;</code>  I propose to  add one
-to parallel such specialization  for &lt;const T*&gt;. Specifically, I
-propose to add the following text to the end of 24.3.1, p3:
+<blockquote>
+<p>
+Please remind people who are reviewing issues to check that the text
+modifications match the current draft. Issue 676, for example, adds two
+overloads for unordered_map::insert taking a hint. One takes a
+const_iterator and returns a const_iterator, and the other takes an
+iterator and returns an iterator. This was correct at the time the issue
+was written, but was changed in Toronto so there is only one hint
+overload, taking a const_iterator and returning an iterator.
+</p>
+<p>
+This issue is not ready. In addition to the relatively minor signature
+problem I mentioned earlier, it puts requirements in the wrong places.
+Instead of duplicating requirements throughout the template
+specifications, it should put them in the front matter that talks about
+requirements for unordered containers in general. This presentation
+problem is editorial, but I'm not willing to do the extensive rewrite
+that it requires. Please put it back into Open status.
+</p>
+</blockquote>
 
-        </p>
-        <p>
 
-and for pointers to volatile as 
 
-        </p>
-            <pre>
-namespace std {
-template&lt;class T&gt; struct iterator_traits&lt;volatile T*&gt; {
-typedef ptrdiff_t difference_type;
-typedef T value_type;
-typedef volatile T* pointer;
-typedef volatile T&amp; reference;
-typedef random_access_iterator_tag iterator_category;
-};
-}
 
-            </pre>
-        <p>
+<hr>
+<h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
+<p><b>Section:</b> 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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>
 
-Note that  the change to  <code>iterator_traits</code> isn't necessary
-in order to implement the  specialized algorithms in a way that allows
-them to operate on volatile  strorage. It is only necesassary in order
-to specify  their effects in terms  of <code>iterator_traits</code> as
-is  done here.   Implementations can  (and some  do) achieve  the same
-effect by means of function template overloading.
 
-        </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>
 
-<hr>
-<h3><a name="585"></a>585. facet error reporting</h3>
-<p><b>Section:</b> 22.2 [locale.categories] <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, Paolo Carlini <b>Date:</b> 2006-06-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</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>
+<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>
 
-Section  22.2, paragraph 2  requires facet  <code>get()</code> members
-that    take    an    <code>ios_base::iostate&amp;</code>    argument,
-<code><i>err</i></code>,  to   ignore  the  (initial)   value  of  the
-argument, but to set it to <code>ios_base::failbit</code> in case of a
-parse error.
 
-        </p>
-        <p>
+<p>
+Change the synopsis in 24.4.3.1 [move.iterator]:
+</p>
 
-We  believe  there  are  a   few  minor  problems  with  this  blanket
-requirement  in   conjunction  with   the  wording  specific   to  each
-<code>get()</code> member function.
+<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>
-        <p>
+<p>
+Change 24.4.3.3.14 [move.iter.nonmember]:
+</p>
 
-First,  besides <code>get()</code>  there are  other  member functions
-with     a      slightly     different     name      (for     example,
-<code>get_date()</code>). It's not completely clear that the intent of
-the  paragraph  is  to  include  those  as  well,  and  at  least  one
-implementation has interpreted the requirement literally.
+<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>
-        <p>
+<p><i>[
+Pre Bellevue:  This issue needs to wait until the <tt>auto -&gt; return</tt> language feature
+goes in.
+]</i></p>
 
-Second,    the     requirement    to    "set     the    argument    to
-<code>ios_base::failbit</code>  suggests that  the  functions are  not
-permitted    to   set    it   to    any   other    value    (such   as
-<code>ios_base::eofbit</code>,   or   even  <code>ios_base::eofbit   |
-ios_base::failbit</code>).
 
-        </p>
-        <p>
 
-However, 22.2.2.1.2, p5 (Stage  3 of <code>num_get</code> parsing) and
-p6 (<code>bool</code> parsing)  specifies that the <code>do_get</code>
-functions  perform <code><i>err</i> |=  ios_base::eofbit</code>, which
-contradicts  the earlier  requirement to  ignore  <i>err</i>'s initial
-value.
 
-        </p>
-        <p>
 
-22.2.6.1.2,  p1  (the  Effects  clause of  the  <code>money_get</code>
-facet's  <code>do_get</code>  member  functions) also  specifies  that
-<code><i>err</i></code>'s initial  value be used to  compute the final
-value  by  ORing  it  with  either  <code>ios_base::failbit</code>  or
-with<code>ios_base::eofbit | ios_base::failbit</code>.
 
-        </p>
-    
 
-    <p><b>Proposed resolution:</b></p>
-        <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>
+ <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>
+<p><b>Discussion:</b></p>
+<p>
+A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
+the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
+to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
+Now that we have a mechanism to detect an rvalue, we can fix them to
+disallow this source of undefined behavior.
+</p>
 
-We believe the  intent is for all facet member  functions that take an
-<code>ios_base::iostate&amp;</code> argument to:
+<p>
+Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+</p>
 
-        </p>
-            <ul>
-                <li>
 
-ignore the initial value of the <code><i>err</i></code> argument,
 
-                </li>
-                <li>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.5 [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;
+template &lt;class T&gt; void cref(const T&amp;&amp; t) = delete;
+</pre></blockquote>
+
 
-reset <code><i>err</i></code>  to <code>ios_base::goodbit</code> prior
-to any further processing,
 
-                </li>
-                <li>
+<p><i>[
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
+addresses the first part of the resolution but not the second.
+]</i></p>
 
-and       set      either       <code>ios_base::eofbit</code>,      or
-<code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as
-appropriate,  in response  to  reaching the  end-of-file  or on  parse
-error, or both.
 
-                </li>
-            </ul>
-        <p>
+<p><i>[
+Bellevue:  Doug noticed problems with the current wording.
+]</i></p>
 
-To that effect we propose to change 22.2, p2 as follows:
 
-        </p>
-        <p>
+<p><i>[
+post Bellevue:  Howard and Peter provided revised wording.
+]</i></p>
 
-The  <i>put</i><del>()</del>  members  make  no  provision  for  error
-reporting.   (Any  failures of  the  OutputIterator  argument must  be
-extracted   from  the   returned  iterator.)    <ins>Unless  otherwise
-specified, </ins>the <i>get</i><del>()</del>  members  <ins>that</ins>
-take an  <code>ios_base::iostate&amp;</code> argument <del>whose value
-they  ignore,  but  set  to  ios_base::failbit  in  case  of  a  parse
-error.</del><ins>,   <code><i>err</i></code>,   start  by   evaluating
-<code>err  =   ios_base::goodbit</code>,  and  may   subsequently  set
-<i>err</i>     to     either     <code>ios_base::eofbit</code>,     or
-<code>ios_base::failbit</code>,     or     <code>ios_base::eofbit    |
-ios_base::failbit</code> in response to reaching the end-of-file or in
-case of a parse error, or both, respectively.</ins>
 
-        </p>
-    
-    
 <p><i>[
-Kona (2007): We need to change the proposed wording to clarify that the
-phrase "the get members" actually denotes <tt>get()</tt>, <tt>get_date()</tt>, etc.
-Proposed Disposition: Open
+This resolution depends on a "favorable" resolution of CWG 606:  that is,
+the "special deduction rule" is disabled with the const T&amp;&amp; pattern.
 ]</i></p>
 
 
 
 
+
 <hr>
-<h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</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#Open">Open</a>
- <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2006-07-18</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>
+<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>
+ <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>Discussion:</b></p>
 <p>
-The wording used for section 23.2.1 [lib.array] seems to be subtly
-ambiguous about zero sized arrays (N==0). Specifically:
+The last version of TR1 does not include the following member
+functions
+for unordered containers:
 </p>
+
+<blockquote><pre>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
+</pre></blockquote>
+
 <p>
-* "An instance of array&lt;T, N&gt; stores N elements of type T, so that
-[...]"
+which looks like an oversight to me. I've checked th TR1 issues lists
+and the latest working draft of the C++0x std (N2284) and haven't
+found any mention to these menfuns or to their absence.
 </p>
 <p>
-Does this imply that a zero sized array object stores 0 elements, i.e.
-that it cannot store any element of type T? The next point clarifies
-the rationale behind this question, basically how to implement begin()
-and end():
+Is this really an oversight, or am I missing something?
 </p>
+
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
-end() == unique value."
+Add the following two rows to table 93 (unordered associative container
+requirements) in section 23.1.3 [unord.req]:
 </p>
+
+<blockquote>
+<table border="1">
+<caption>Unordered associative container requirements (in addition to container)</caption>
+<tbody><tr>
+<th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
+</tr>
+<tr>
+<td><ins><tt>b.cbegin(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>. Note: <tt>[b.cbegin(n), b.cend(n))</tt> is a valid range containing all of the elements in the <tt>n</tt><sup><i>th</i></sup> bucket.</ins></td> <td><ins>Constant</ins></td> 
+</tr>
+<tr>
+<td><ins><tt>b.cend(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>.</ins></td> <td><ins>Constant</ins></td> 
+</tr>
+</tbody></table>
+</blockquote>
+
 <p>
-What does "unique" mean in this context? Let's consider the following
-possible implementations, all relying on a partial specialization:
+Add to the synopsis in 23.4.1 [unord.map]:
 </p>
-<blockquote><pre>a)
-    template&lt; typename T &gt;
-    class array&lt; T, 0 &gt; {
-    
-        ....
-
-        iterator begin()
-        { return iterator( reinterpret_cast&lt; T * &gt;( this ) ); }
-        ....
 
-    };
+<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;</ins>
 </pre></blockquote>
+
 <p>
-This has been used in boost, probably intending that the return value
-had to be unique to the specific array object and that array couldn't
-store any T. Note that, besides relying on a reinterpret_cast, has
-(more than potential) alignment problems.
+Add to the synopsis in 23.4.2 [unord.multimap]:
 </p>
-<blockquote><pre>b)
-    template&lt; typename T &gt;
-    class array&lt; T, 0 &gt; {
-    
-        T t;
 
-        iterator begin()
-        { return iterator( &amp;t ); }
-        ....
-
-    };
+<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;</ins>
 </pre></blockquote>
+
 <p>
-This provides a value which is unique to the object and to the type of
-the array, but requires storing a T. Also, it would allow the user to
-mistakenly provide an initializer list with one element.
+Add to the synopsis in 23.4.3 [unord.set]:
 </p>
+
+<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;</ins>
+</pre></blockquote>
+
 <p>
-A slight variant could be returning *the* null pointer of type T
+Add to the synopsis in 23.4.4 [unord.multiset]:
 </p>
-<blockquote><pre>    return static_cast&lt;T*&gt;(0);
+
+<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;</ins>
 </pre></blockquote>
+
+
+
+
+
+
+<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>
+ <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>Discussion:</b></p>
 <p>
-In this case the value would be unique to the type array&lt;T, 0&gt; but not
-to the objects (all objects of type array&lt;T, 0&gt; with the same value
-for T would yield the same pointer value).
+In a private email Bill Plauger notes:
+</p>
+<blockquote><p>
+I  believe that  the function  that  implements <code>get_money</code>
+[from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
+should behave  as a  formatted input function,  and the  function that
+implements <code>put_money</code> should  behave as a formatted output
+function. This  has implications regarding the  skipping of whitespace
+and the handling of errors, among other things.
 </p>
 <p>
-Furthermore this is inconsistent with what the standard requires from
-allocation functions (see library issue 9).
+The words  don't say that  right now and  I'm far from  convinced that
+such a change is editorial.
+</p></blockquote>
+<p>
+Martin's response:
+</p>
+<blockquote><p>
+I agree that the manipulators should handle exceptions the same way as
+formatted I/O functions do. The text in N2072 assumes so but the
+<i>Returns</i> clause explicitly omits exception handling for the sake
+of brevity. The spec should be clarified to that effect.
 </p>
 <p>
-c) same as above but with t being a static data member; again, the
-value would be unique to the type, not to the object.
+As for dealing  with whitespace, I also agree it  would make sense for
+the extractors  and inserters involving the new  manipulators to treat
+it the same way as formatted I/O.
+</p></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add  a new  paragraph immediately  above  p4 of 27.6.4 [ext.manip] with  the
+following text:
 </p>
+<blockquote><p>
+<i>Effects</i>:  The   expression  <code><i>in</i> &gt;&gt; get_money(mon, intl)</code>
+described below behaves as a formatted input function (as
+described in 27.6.1.2.1 [istream.formatted.reqmts]).
+</p></blockquote>
 <p>
-d) to avoid storing a T *directly* while disallowing the possibility
-to use a one-element initializer list a non-aggregate nested class
-could be defined
+Also change p4 of 27.6.4 [ext.manip] as follows:
 </p>
-<blockquote><pre>    struct holder { holder() {} T t; } h;
-</pre></blockquote>
+<blockquote><p>
+<i>Returns</i>: An object <code>s</code> of unspecified type such that
+if <code>in</code> is  an object of type <code>basic_istream&lt;charT,
+traits&gt;</code>    then    the    expression   <code><i>in</i> &gt;&gt; get_money(mon, intl)</code> behaves as <ins>a formatted input function
+that    calls    </ins><code>f(in, mon, intl)</code><del>    were
+called</del>. The function <code>f</code> can be defined as...
+</p></blockquote>
+
+
+<p><i>[
+post Bellevue:
+]</i></p>
+
+
+<blockquote>
+We recommend moving immediately to Review. We've looked at the issue and
+have a consensus that the proposed resolution is correct, but want an
+iostream expert to sign off. Alisdair has taken the action item to putt
+this up on the reflector for possible movement by Howard to Tenatively
+Ready.
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="696"></a>696. <code>istream::operator&gt;&gt;(int&amp;)</code> broken</h3>
+<p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <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> 2007-06-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-and then begin be defined as
+From message c++std-lib-17897:
 </p>
-<blockquote><pre> iterator begin() { return &amp;h.t; }
-</pre></blockquote>
 <p>
-But then, it's arguable whether the array stores a T or not.
-Indirectly it does.
+The  code  shown  in  27.6.1.2.2 [istream.formatted.arithmetic] as  the  "as  if"
+implementation  of the  two arithmetic  extractors that  don't  have a
+corresponding     <code>num_get</code>     interface    (i.e.,     the
+<code>short</code> and <code>int</code>  overloads) is subtly buggy in
+how  it  deals  with  <code>EOF</code>, overflow,  and  other  similar
+conditions (in addition to containing a few typos).
 </p>
 <p>
------------------------------------------------------
+One  problem is  that if  <code>num_get::get()</code> reaches  the EOF
+after reading in  an otherwise valid value that  exceeds the limits of
+the    narrower    type     (but    not    <code>LONG_MIN</code>    or
+<code>LONG_MAX</code>),   it  will   set   <code><i>err</i></code>  to
+<code>eofbit</code>.   Because   of  the  if   condition  testing  for
+<code>(<i>err</i> == 0)</code>,    the   extractor    won't   set
+<code>failbit</code>  (and presumably,  return  a bogus  value to  the
+caller).
+</p>
+<p>
+Another  problem with  the code  is that  it never  actually  sets the
+argument to  the extracted  value. It can't  happen after the  call to
+<code>setstate()</code> since  the function may  throw, so we  need to
+show when  and how it's done (we  can't just punt as  say: "it happens
+afterwards"). However, it  turns out that showing how  it's done isn't
+quite so  easy since  the argument is  normally left unchanged  by the
+facet on error  except when the error is due  to a misplaced thousands
+separator,  which causes  <code>failbit</code> to  be set  but doesn't
+prevent the facet from storing the value.
 </p>
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Now, on different issues:
 </p>
+
+
+
+
+
+<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>
+ <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>Discussion:</b></p>
 <p>
-* what's the effect of calling assign(T&amp;) on a zero-sized array? There
-seems to be only mention of front() and back(), in 23.2.1 [lib.array]
-p4 (I would also suggest to move that bullet to section 23.2.1.5
-[lib.array.zero], for locality of reference)
+In 19.4.5.1 [syserr.syserr.overview] we have the class definition of
+<tt>std::system_error</tt>. In contrast to all exception classes, which
+are constructible with a <tt>what_arg string</tt> (see 19.1 [std.exceptions],
+or <tt>ios_base::failure</tt> in 27.4.2.1.1 [ios::failure]), only overloads with with
+<tt>const string&amp;</tt> are possible. For consistency with the re-designed
+remaining exception classes this class should also provide
+c'tors which accept a const <tt>char* what_arg</tt> string.
 </p>
 <p>
-* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
-inconsistent with that of other sequences: that's not a problem in
-itself, but compare it for instance with "A vector is a kind of
-sequence that supports random access iterators"; though the intent is
-obvious one might argue that the wording used for arrays doesn't tell
-what an array is, and relies on the reader to infer that it is what
-the &lt;array&gt; header defines.
+Please note that this proposed addition makes sense even
+considering the given implementation hint for <tt>what()</tt>, because
+<tt>what_arg</tt> is required to be set as <tt>what_arg</tt> of the base class
+<tt>runtime_error</tt>, which now has the additional c'tor overload
+accepting a <tt>const char*</tt>.
 </p>
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-* it would be desiderable to have a static const data member of type
-std::size_t, with value N, for usage as integral constant expression
 </p>
+
+
+
+
+
+<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>
+<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>
-* section 23.1 [lib.container.requirements] seem not to consider
-fixed-size containers at all, as it says: "[containers] control
-allocation and deallocation of these objects [the contained objects]
-through constructors, destructors, *insert and erase* operations"
+I see that the definition the associated Laguerre
+polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>.
+However, the draft standard only specifies ranks of integer value <tt>m</tt>,
+while the associated Laguerre polynomials are actually valid for real
+values of <tt>m &gt; -1</tt>.  In the case of non-integer values of <tt>m</tt>, the
+definition  <tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt>
+must be used, which also holds for integer values of <tt>m</tt>.  See
+Abramowitz &amp; Stegun, 22.11.6 for the general case, and 22.5.16-17 for
+the integer case.  In fact fractional values are most commonly used in
+physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic
+oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3
+dimensions.
 </p>
 <p>
-* max_size() isn't specified: the result is obvious but, technically,
-it relies on table 80: "size() of the largest possible container"
-which, again, doesn't seem to consider fixed size containers
+If I am correct, the calculation of the more general case is no
+more difficult, and is in fact the function implemented in the GNU
+Scientific Library.  I would urge you to consider upgrading the 
+standard, either adding extra functions for real <tt>m</tt> or switching the
+current ones to <tt>double</tt>.
 </p>
 
 
@@ -6573,440 +9957,619 @@ which, again, doesn't seem to consider fixed size containers
 </p>
 
 
-<p><i>[
-Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
-Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
-requirements? Alisdair will prepare a paper. Proposed Disposition: Open
-]</i></p>
+
+
+
+<hr>
+<h3><a name="702"></a>702. Restriction in associated Legendre functions</h3>
+<p><b>Section:</b> TR1 5.2.1.2 [tr.num.sf.Plm] <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>
+<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>
+One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should  be
+<tt>|x| &lt;= 1</tt>, not <tt>x &gt;= 0</tt>.</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
 
 
 
 
 
 <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 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="704"></a>704. MoveAssignable requirement for container value type overly strict</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-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-TR1 introduced, in the C compatibility chapter, the function
-fabs(complex&lt;T&gt;):
+The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from
+most of the member functions of node-based containers.  But the move-related changes
+unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
+require <tt>CopyAssignable</tt>.
 </p>
-<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
+<p>
+We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
+from some of the sequence requirements.  Additionally the <i>in-place</i> construction
+work may further reduce requirements.  For purposes of an easy reference, here are the
+minimum sequence requirements as I currently understand them.  Those items in requirements
+table in the working draft which do not appear below have been purposefully omitted for
+brevity as they do not have any requirements of this nature.  Some items which do not
+have any requirements of this nature are included below just to confirm that they were
+not omitted by mistake.
+</p>
 
-[...]
+<table border="1">
+<caption>Container Requirements</caption>
+<tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
+<tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> requires <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>
+</tbody></table>
 
-8.1.8 Function fabs                          [tr.c99.cmplx.fabs]
+<p>
+</p>
 
-1 Effects: Behaves the same as C99 function cabs, defined in
-  subclause 7.3.8.1.
------ SNIP -----
-</pre></blockquote>
+<table border="1">
+<caption>Sequence Requirements</caption>
+<tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
+<tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
+<tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
+<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
+                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
+<tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
+                                        If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
+                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
+<tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.clear()</tt></td><td></td></tr>
+<tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
+                                        If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
+<tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
+                                     The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+</tbody></table>
+
+<p>
+</p>
+
+<table border="1">
+<caption>Optional Sequence Requirements</caption>
+<tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
+<tr><td><tt>a.back()</tt></td><td></td></tr>
+<tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.pop_front()</tt></td><td></td></tr>
+<tr><td><tt>a.pop_back()</tt></td><td></td></tr>
+<tr><td><tt>a[n]</tt></td><td></td></tr>
+<tr><td><tt>a.at[n]</tt></td><td></td></tr>
+</tbody></table>
 
 <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.
 </p>
+
+<table border="1">
+<caption>Associative Container Requirements</caption>
+<tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                        If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
+</tbody></table>
+
 <p>
-But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
-n1124), the referenced subclause reads
 </p>
 
-<blockquote><pre>----- SNIP -----
-7.3.8.1 The cabs functions
+<table border="1">
+<caption>Unordered Associative Container Requirements</caption>
+<tbody><tr><td><tt>X(i, j, n, hf, eq)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+                                        If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
+</tbody></table>
 
-  Synopsis
+<p>
+</p>
 
-1 #include &lt;complex.h&gt;
-  double cabs(double complex z);
-  float cabsf(float complex z);
-  long double cabsl(long double z);
+<table border="1">
+<caption>Miscellaneous Requirements</caption>
+<tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
+                                         The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
+                                         The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
+</tbody></table>
 
-  Description
+<p><i>[
+Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
+]</i></p>
+
+
+<p><i>[
+Bellevue: This should be handled as part of the concepts work.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
 
-2 The cabs functions compute the complex absolute value (also called
-  norm, modulus, or magnitude) of z.
 
-  Returns
 
-3 The cabs functions return the complex absolute value.
------ SNIP -----
-</pre></blockquote>
 
-<p>
-Note that the return type of the cabs*() functions is not a complex
-type.  Thus, they are equivalent to the already well established
-  template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp; x);
-(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
-document n2009.pdf).
-</p>
-<p>
-So either the return value of fabs() is specified wrongly, or fabs()
-does not behave the same as C99's cabs*().
-</p>
 
-<b>Possible Resolutions</b>
 
+<hr>
+<h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3>
+<p><b>Section:</b> 22 [localization] <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-07-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</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 depends on the intention behind the introduction of fabs().
+The POSIX "Extended API Set Part 4,"
 </p>
+<blockquote><p>
+<a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
+</p></blockquote>
 <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.
+introduces extensions to the C locale mechanism that
+allow multiple concurrent locales to be used in the same application
+by introducing a type <tt>locale_t</tt> that is very similar to
+<tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it.
 </p>
 <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
+The global locale (set by setlocale) is now specified to be per-
+process. If a thread does not call <tt>uselocale</tt>, the global locale is
+in effect for that thread. It can install a per-thread locale by
+using <tt>uselocale</tt>.
 </p>
-<blockquote><pre>  complex&lt;double&gt; x, y;
-  y = fabs(x);
-  complex&lt;double&gt; z(fabs(x));
-</pre></blockquote>
 <p>
-and
+There is also a nice <tt>querylocale</tt> mechanism by which one can obtain
+the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined
+locales, with no <tt>std::locale</tt> equivalent.
 </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().
+<tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt>
+mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>.
 </p>
 
+<p><i>[
+Kona (2007): Bill and Nick to provide wording.
+]</i></p>
+
 
 
-<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>template&lt;class T&gt; <del>complex&lt;</del>T<del>&gt;</del> fabs(const complex&lt;T&gt;&amp;);
-</pre></blockquote>
 
-<p>
-Change 26.3.7 [complex.value.ops], p7:
-</p>
 
-<blockquote>
-<pre>template&lt;class T&gt; <del>complex&lt;</del>T<del>&gt;</del> fabs(const complex&lt;T&gt;&amp; <i>x</i>);
-</pre>
-<blockquote>
-<p>
--7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.
-</p>
-</blockquote>
-</blockquote>
 
 
+<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>
+<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>[
-Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>. 
-Proposed Disposition: Ready
+Bellevue:
 ]</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#Review">Review</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#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
 <p>
-In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke  
+Move to "ready", adopting the first (Peter's) proposed resolution.
 </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:
+Note to the project editor: there is an editorial issue here. The
+wording for the postconditions of the casts is slightly awkward, and the
+editor should consider rewording "If w is the return value...", e. g. as
+"For a return value w...".
 </p>
-<blockquote><p>
-  If mode is not some combination of flags shown in the table 
-  then the open fails.
-</p></blockquote>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
 <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.
+Add to 20.6.12.2.1 [util.smartptr.shared.const]:
 </p>
+
+<blockquote>
+<pre>shared_ptr(shared_ptr&amp;&amp; r);
+template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r);
+</pre>
+<blockquote>
 <p>
-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.)
+<i>Postconditions:</i>  <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt>
+shall be empty. <ins><tt>r.get() == 0</tt>.</ins>
 </p>
+</blockquote>
+</blockquote>
+
 <p>
-We further request that the missing modes be explicitly restored to
-the WP, for inclusion in C++0x.
+Add to 20.6.12.2.10 [util.smartptr.shared.cast]:
 </p>
 
-<p><i>[
-Martin adds:
-]</i></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>
-...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.
+<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>
 
-
-<p><b>Proposed resolution:</b></p>
+<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>
-Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
+<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast&lt;T*&gt;(r.get())</tt>.</ins>
 </p>
+</blockquote>
+</blockquote>
 
 <blockquote>
-<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>
+<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>
 
-<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>
+<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>
 
-<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>
+<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>
 
-</tbody></table>
+<blockquote>
+<p>
+-6- <i>Returns:</i>
+</p>
+<ul>
+<li><del>When <tt>dynamic_cast&lt;T*&gt;(r.get())</tt> returns a nonzero value,
+a <tt>shared_ptr&lt;T&gt;</tt> object that stores a copy 
+of it and <i>shares ownership</i> with <tt>r</tt>;</del></li>
+<li><del>Otherwise, an <i>empty</i> <tt>shared_ptr&lt;T&gt;</tt> object.</del></li>
+<li><ins>If <tt>p = dynamic_cast&lt;T*&gt;(r.get())</tt> is a non-null pointer, <tt>shared_ptr&lt;T&gt;(r, p);</tt></ins></li>
+<li><ins>Otherwise, <tt>shared_ptr&lt;T&gt;()</tt>.</ins></li>
+</ul>
 </blockquote>
 
+<blockquote>
+<p>
+-10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
+shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
+object that stores <tt>const_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
+<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, const_cast&lt;T*&gt;(r.get())</tt>.</ins>
+</p>
+</blockquote>
 
+<p>
+This takes care of the missing postconditions for the casts by bringing
+in the aliasing constructor postcondition "by reference".
+</p>
 
-<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>
+<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>
+ <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>Discussion:</b></p>
 <p>
-In a private email, Daveed writes:
+A discussion on
+<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
+has identified a contradiction in the <tt>shared_ptr</tt> specification.
+The note:
 </p>
-<blockquote>
+
+<blockquote><p>
+[ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
+-end note ]
+</p></blockquote>
+
 <p>
-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.
+after the aliasing constructor
 </p>
+
+<blockquote><pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
+</pre></blockquote>
+
 <p>
-Here is an example:
+reflects the intent of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
+to, well, allow the creation of an empty <tt>shared_ptr</tt>
+with a non-NULL stored pointer.
 </p>
-</blockquote>
-<pre>
-		 struct S {
-		   S(_Decimal32 const&amp;);  // Converting constructor
-		 };
-		 void f(S);
 
-		 void f(_Decimal64);
+<p>
+This is contradicted by the second sentence in the Returns clause of 20.6.12.2.5 [util.smartptr.shared.obs]:
+</p>
 
-		 void g(_Decimal32 d) {
-		   f(d);
-		 }
+<blockquote>
+<pre>T* get() const;
 </pre>
+<blockquote><p>
+<i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
+</p></blockquote>
+</blockquote>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
 
 <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.
+Adopt option 1 and move to review, not ready.
 </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.
+There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
+isn't defined anywhere), and whether we have a good mental model for how
+one behaves. We think it might be possible to deduce what the definition
+should be, but the words just aren't there. We need to open an issue on
+the use of this undefined term. (The resolution of that issue might
+affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.)
+</p>
+<p>
+The LWG is getting more uncomfortable with the aliasing proposal (N2351)
+now that we realize some of its implications, and we need to keep an eye
+on it, but there isn't support for removing this feature at this time.
 </p>
 </blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Robert comments:
+In keeping the N2351 spirit and obviously my preference, change 20.6.12.2.5 [util.smartptr.shared.obs]:
 </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:
+
+<blockquote>
+<pre>T* get() const;
+</pre>
+<blockquote><p>
+<i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
+</p></blockquote>
+</blockquote>
+
+<p>
+Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
 </p>
-<pre>                 _Decimal32 d1;
-                 d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
+
+<p>
+Change 20.6.12.2.1 [util.smartptr.shared.const]:
+</p>
+
+<blockquote>
+<pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
 </pre>
+<blockquote>
 <p>
-In preparing the decimal TR, we have three options:
+<ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins>
 </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.
+<del>[ <i>Note:</i> this constructor allows creation of an empty <tt>shared_ptr</tt>
+instance with a non-NULL stored pointer. 
+-- <i>end note</i> ]</del>
 </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.
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<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>
+ <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>Discussion:</b></p>
+<p>
+The complexity of <tt>sort()</tt> is specified as "Approximately <tt>N
+log(N)</tt> (where <tt>N == last - first</tt> ) comparisons on the
+average", with no worst case complicity specified. The intention was to
+allow a median-of-three quicksort implementation, which is usually <tt>O(N
+log N)</tt> but can be quadratic for pathological inputs. However, there is
+no longer any reason to allow implementers the freedom to have a
+worst-cast-quadratic sort algorithm. Implementers who want to use
+quicksort can use a variant like David Musser's "Introsort" (Software
+Practice and Experience 27:983-993, 1997), which is guaranteed to be <tt>O(N
+log N)</tt> in the worst case without incurring additional overhead in the
+average case. Most C++ library implementers already do this, and there
+is no reason not to guarantee it in the standard.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
+<p>
+In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
+</p>
+
+<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>
+</p>
+<p>
+<del><sup>266)</sup>
+If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt>partial_sort()</tt>
+(25.3.1.3) should be used.</del>
+</p>
+</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>
+<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>
+ <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>Discussion:</b></p>
 <p>
-In c++std-lib-17205, Martin writes:
+The complexity for <tt>search_n</tt> (25.1.9 [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
+element in the range more than once.
 </p>
-<blockquote><p>...was it a deliberate design choice to make narrowing
-assignments ill-formed while permitting narrowing compound assignments?
-For instance:
-</p></blockquote>
-<pre>      decimal32 d32;
-      decimal64 d64;
 
-      d32 = 64;     // error
-      d32 += 64;    // okay
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the complexity to "At most (last - first) applications of the corresponding predicate".
+</p>
+
+<blockquote>
+<pre>template&lt;class ForwardIterator, class Size, class T&gt; 
+  ForwardIterator 
+    search_n(ForwardIterator first , ForwardIterator last , Size count , 
+             const T&amp; value ); 
+
+template&lt;class ForwardIterator, class Size, class T, 
+         class BinaryPredicate&gt; 
+  ForwardIterator 
+    search_n(ForwardIterator first , ForwardIterator last , Size count , 
+             const T&amp; value , BinaryPredicate pred );
 </pre>
+<blockquote>
 <p>
-In c++std-lib-17229, Robert responds:
+<i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate
+<del>if <tt>count</tt> is positive, or 0 otherwise</del>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<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>
-<blockquote><p>It is a vestige of an old idea that I forgot to remove
-from the paper. Narrowing assignments should be permitted. The bug is
-that the converting constructors that cause narrowing should not be
-explicit. Thanks for pointing this out.
-</p></blockquote>
+
 
 <p><b>Proposed resolution:</b></p>
 <p>
-1.  In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
+Change 25.3.7 [alg.min.max] to:
 </p>
-<pre>                // <i>3.2.2.2 conversion from floating-point type:</i>
-                <del>explicit</del> decimal32(decimal64 <i>d64</i>);
-                <del>explicit</del> decimal32(decimal128 <i>d128</i>);
+
+<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>
-2.  Do the same thing in "3.2.2.2. Conversion from floating-point type."
-</p>
-<p>
-3.  In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
+<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>
-<pre>                // <i>3.2.3.2 conversion from floating-point type:</i>
-                <del>explicit</del> decimal64(decimal128 <i>d128</i>);
-</pre>
 <p>
-4.  Do the same thing in "3.2.3.2. Conversion from floating-point type."
+<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>
-
-<p><i>[
-Redmond: We prefer explicit conversions for narrowing and implicit for widening.
-]</i></p>
+</blockquote>
+</blockquote>
 
 
 
@@ -7014,47 +10577,45 @@ Redmond: We prefer explicit conversions for narrowing and implicit for widening.
 
 
 <hr>
-<h3><a name="612"></a>612. numeric_limits::is_modulo insufficently 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#Open">Open</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#Open">Open</a> status.</p>
+<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>
+<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>
-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 insufficent for the following reasons:
+TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
 </p>
 
-<ol>
-<li>Doesn't define what that value recieved 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>
+<blockquote>
+<p>
+The following productions within the ECMAScript grammar are modified as follows:
+</p>
 
-<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>
+<blockquote><pre>CharacterClass ::
+[ [lookahead &#8713; {^}] ClassRanges ]
+[ ^ ClassRanges ]
+</pre></blockquote>
+
+</blockquote>
+
+<p>
+This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
+</p>
 
+<p>
+Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
+</p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Suggest 18.2.1.2 [numeric.limits.members[numeric.limits.members], paragraph 57 is ammeded to:
+Remove this mention of the CharacterClass production.
 </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>
+<blockquote><pre><del>CharacterClass ::
+[ [lookahead &#8713; {^}] ClassRanges ]
+[ ^ ClassRanges ]</del>
+</pre></blockquote>
 
 
 
@@ -7062,65 +10623,64 @@ differs from the true value by an integer multiple of <tt>(max() - min() +
 
 
 <hr>
-<h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3>
+<h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</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>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-18</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#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-This is based on N2134, where 21.3.1/2 states:
-"... The Allocator object used shall be a copy of the Allocator object 
-passed to the basic_string object's constructor or, if the constructor does 
-not take an Allocator argument, a copy of a default-constructed Allocator 
-object."
+Paragraph 21.3 [basic.string]/3 states:
 </p>
+
+<blockquote>
 <p>
-Section 21.3.2/1 lists two constructors:
+The class template <tt>basic_string</tt> conforms to the requirements for a 
+Sequence (23.1.1) and for a Reversible Container (23.1).
 </p>
-<blockquote><pre>basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str );
+</blockquote>
 
-basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str ,
-             size_type pos , size_type n = npos,
-             const Allocator&amp; a = Allocator());
-</pre></blockquote>
 <p>
-and then says "In the first form, the Allocator value used is copied from 
-str.get_allocator().", which isn't an option according to 21.3.1.
+First of all, 23.1.1 [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.
 </p>
-<p><i>[
-Batavia:  We need blanket statement to the effect of:
-]</i></p>
-
 
-<ol>
-<li>If an allocator is passed in, use it, or,</li>
-<li>If a string is passed in, use its allocator.</li>
-</ol>
 <p><i>[
-Review constructors and functions that return a string; make sure we follow these
-rules (substr, operator+, etc.).  Howard to supply wording.
+Bellevue:
 ]</i></p>
 
 
-<p><i>[
-Bo adds:  The new container constructor which takes only a <tt>size_type</tt> is not
-consistent with 23.1 [container.requirements], p9 which says in part:
-
 <blockquote>
-All other constructors for these container types take an
-<tt>Allocator&amp;</tt> argument (20.1.2), an allocator whose value type
-is the same as the container's value type. A copy of this argument is
-used for any memory allocation performed, by these constructors and by
-all member functions, during the lifetime of each container object.
+<ul>
+<li>emplace, for example, may not make sense for strings. Is also likely suboptimal</li>
+<li>with concepts do we need to maintain string as sequence container?</li>
+<li>One approach might be to say something like: string is a sequence except it doesn't have these functions</li>
+</ul>
+<ul>
+<li>basic_string already has push_back</li>
+<li>const_iterator parameters to insert and erase should be added to basic_string</li>
+<li>this leaves emplace to handle -- we have the following options:
+<ul>
+<li>option 1: add it to string even though it's optional</li>
+<li>option 2: make emplace optional to sequences (move from table 89 to 90)</li>
+<li>option 3: say string not sequence (the proposal),</li>
+<li>option 4: add an exception to basic string wording.</li>
+</ul>
+</li>
+</ul>
+General consensus is to suggest option 2.
 </blockquote>
-]</i></p>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
+Remove this sentence, in recognition of the fact that <tt>basic_string</tt> is 
+not just a <tt>vector</tt>-light for literal types, but something quite 
+different, a string abstraction in its own right.
 </p>
 
 
@@ -7128,802 +10688,993 @@ all member functions, during the lifetime of each container object.
 
 
 <hr>
-<h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
-<p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-30</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#New">New</a> status.</p>
+<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>
+ <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>
 <p><b>Discussion:</b></p>
 <p>
-The <tt>&lt;array&gt;</tt> header is given under 23.2 [sequences].
-23.2.1 [array]/paragraph 3 says:
-</p>
-<blockquote><p>
-"Unless otherwise specified, all array operations are as described in
-23.1 [container.requirements]".
-</p></blockquote>
-<p>
-However, array isn't mentioned at all in section 23.1 [container.requirements].
-In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear) 
-that std::array does not have in 23.2.1 [array].
-</p>
-<p>
-Also, Table 83 "Optional sequence operations" lists several operations that 
-std::array does have, but array isn't mentioned.
+Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
+a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
+-11- A type is a <i>literal</i> type if it is:
 </p>
+<ul>
+<li>a scalar type; or</li>
+<li><p>a class type (clause 9) with</p>
+<ul>
+<li>a trivial copy constructor,</li>
+<li>a trivial destructor,</li>
+<li>at least one constexpr constructor other than the copy constructor,</li>
+<li>no virtual base classes, and</li>
+<li>all non-static data members and base classes of literal types; or</li>
+</ul>
+</li>
+<li>an array of literal type.</li>
+</ul>
+</blockquote>
 
-
-
-
-
-<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#Review">Review</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</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>.
+I strongly suggest that the standard provides a type traits for
+literal types in 20.4.4.3 [meta.unary.prop] for several reasons:
 </p>
 
+<ol type="a">
+<li>To keep the traits in sync with existing types.</li>
+<li>I see many reasons for programmers to use this trait in template
+   code to provide optimized template definitions for these types,
+   see below.</li>
+<li>A user-provided definition of this trait is practically impossible
+to write portably.</li>
+</ol>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 26.5.2.7 [valarray.members], paragraph 10:
+The special problem of reason (c) is that I don't see currently a
+way to portably test the condition for literal class types:
 </p>
 
 <blockquote>
+<ul>
+<li>at least one constexpr constructor other than the copy constructor,</li>
+</ul>
+</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>
+Here follows a simply example to demonstrate it's usefulness:
 </p>
-</blockquote>
-</blockquote>
 
+<blockquote><pre>template &lt;typename T&gt;
+constexpr typename std::enable_if&lt;std::is_literal&lt;T&gt;::value, T&gt;::type
+abs(T x) {
+  return x &lt; T() ? -x : x;
+}
 
+template &lt;typename T&gt;
+typename std::enable_if&lt;!std::is_literal&lt;T&gt;::value, T&gt;::type
+abs(const T&amp; x) {
+  return x &lt; T() ? -x : x;
+}
+</pre></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.
+Here we have the possibility to provide a general <tt>abs</tt> function
+template that can be used in ICE's if it's argument is a literal
+type which's value is a constant expression, otherwise we
+have an optimized version for arguments which are expensive
+to copy and therefore need the usage of arguments of
+reference type (instead of <tt>const T&amp;</tt> we could decide to
+use <tt>T&amp;&amp;</tt>, but that is another issue).
 </p>
 
-
 <p><i>[
-Kona (2007) Changed proposed wording, added rationale and set to Review.
+Alisdair is considering preparing a paper listing a number of missing
+type traits, and feels that it might be useful to handle them all
+together rather than piecemeal. This would affect issue 719 and 750.
+These two issues should move to OPEN pending AM paper on type traits.
 ]</i></p>
 
 
 
 
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.4.2 [meta.type.synop] in the group "type properties",
+just below the line
+</p>
 
-<hr>
-<h3><a name="620"></a>620. valid uses of empty valarrays</h3>
-<p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-        <p>
+<blockquote><pre>template &lt;class T&gt; struct is_pod;
+</pre></blockquote>
 
-The <i>Effects</i>  clause for the  default <code>valarray</code> ctor
-suggests  that  it  is possible  to  increase  the  size of  an  empty
-<code>valarray</code>  object   by  calling  other   non-const  member
-functions of the class besides <code>resize()</code>. However, such an
-interpretation would  be contradicted by  the requirement on  the copy
-assignment  operator  (and  apparently   also  that  on  the  computed
-assignments)  that the  assigned arrays  be  the same  size.  See  the
-reflector discussion starting with c++std-lib-17871.
+<p>
+add a new one:
+</p>
 
-        </p>
-        <p>
+<blockquote><pre>template &lt;class T&gt; struct is_literal;
+</pre></blockquote>
 
-In  addition,  <i>Footnote</i> 280  uses  some questionable  normative
-language.
+<p>
+In 20.4.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>
 
-        </p>
+<table border="1">
+<tbody><tr>
+<th>Template</th><th>Condition</th><th>Preconditions</th>
+</tr>
+<tr>
+<td><tt>template &lt;class T&gt; struct is_literal;</tt></td>
+<td><tt>T</tt> is a literal type (3.9)</td>
+<td><tt>T</tt> shall be a complete type, an
+array of unknown bound, or
+(possibly cv-qualified) <tt>void</tt>.</td>
+</tr>
+</tbody></table>
 
 
-<p><b>Proposed resolution:</b></p>
-        <p>
 
-Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.5.2.1 [valarray.cons]):
 
-        </p>
-        <blockquote>
-            <p>
 
-<code>valarray();</code>
 
-            </p>
-            <p>
+<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>
+ <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>Discussion:</b></p>
+<ol>
+<li>
+The member function <tt>bool array&lt;T,N&gt;::empty() const</tt> should be a
+<tt>constexpr</tt> because this is easily to proof and to implement following it's operational
+semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>.
+</li>
+<li>
+The member function <tt>bool bitset&lt;N&gt;::test() const</tt> must be a
+<tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
+bitset&lt;N&gt;::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
+</li>
+<li>
+I wonder how the constructor <tt>bitset&lt;N&gt;::bitset(unsigned long)</tt> can
+be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
+c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
+non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
+initialisation. What have I overlooked here?
+</li>
+</ol>
 
-<i>Effects</i>:      Constructs      an      object      of      class
-<code>valarray&lt;T&gt;</code>,<sup>279)</sup>    which    has    zero
-length<del> until it is passed into a library function as a modifiable
-lvalue or through a non-constant this pointer</del>.<sup>280)</sup>
 
-            </p>
-            <p>
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>In the class template definition of 23.2.1 [array]/p. 3 change</p>
+<blockquote><pre><ins>constexpr</ins> bool empty() const;
+</pre></blockquote>
+</li>
 
-<ins><i>Postcondition</i>: <code>size() == 0</code>.</ins>
+<li>
+<p>In the class template definition of 23.3.5 [template.bitset]/p. 1 change</p>
+<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
+</pre></blockquote>
 
-            </p>
-            <p>
+<p>
+and in 23.3.5.2 [bitset.members] change
+</p>
 
-<i>Footnote  280</i>:  This default  constructor  is essential,  since
-arrays  of  <code>valarray</code>  <del>are  likely to  prove  useful.
-There  shall also  be  a way  to change  the  size of  an array  after
-initialization;  this  is  supplied  by the  semantics</del>  <ins>may be
-useful.   The  length  of  an  empty  array  can  be  increased  after
-initialization  by  means</ins>  of the  <code>resize()</code>  member
-function.
+<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
+</pre></blockquote>
 
-            </p>
-        </blockquote>
+</li>
+</ol>
 
 
 
 
 
 <hr>
-<h3><a name="621"></a>621. non-const copy assignment operators of helper arrays</h3>
-<p><b>Section:</b> 26.5 [numarray] <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> 2007-01-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</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="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3>
+<p><b>Section:</b> 22.1.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-27</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-        <p>
-
-The computed and  "fill" assignment operators of <code>valarray</code>
-helper     array     class    templates     (<code>slice_array</code>,
-<code>gslice_array</code>,         <code>mask_array</code>,        and
-<code>indirect_array</code>) are const  member functions of each class
-template     (the     latter    by     the     resolution    of  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>
-since  they have reference  semantics and thus do  not affect
-the state of  the object on which they are  called.  However, the copy
-assignment  operators  of  these  class  templates,  which  also  have
-reference semantics,  are non-const.   The absence of  constness opens
-the door to speculation about whether they really are intended to have
-reference semantics (existing implementations vary widely).
-
-        </p>
-
 <p>
-Pre-Kona, Martin adds:
+Paragraph 3 says that the <tt>Codecvt</tt> template parameter shall meet the 
+requirements of <tt>std::codecvt</tt>, even though <tt>std::codecvt</tt> itself cannot 
+be used (because of a protected destructor).
 </p>
 
 <p>
-I realized that adding the const qualifier to the
-functions as I suggested would break the const correctness of the
-classes. A few possible solutions come to mind:
+How are we going to explain this code to beginning programmers?
 </p>
 
-<ol>
-<li>Add the const qualifier to the return types of these functions.</li>
-<li>Change the return type of all the functions to void to match
-the signatures of all the other assignment operators these classes
-define.</li>
-<li>Prohibit the copy assignment of these classes by declaring the
-copy assignment operators private (as is done and documented by
-some implementations).</li>
-</ol>
-
-
-
-<p><b>Proposed resolution:</b></p>
-        <p>
-
-Declare  the  copy  assignment  operators  of all  four  helper  array
-class templates const.
-
-        </p>
-        <p>
-
-Specifically,  make the following edits:
-
-        </p>
-        <p>
-
-Change     the    signature     in     26.5.5 [template.slice.array]    and
-26.5.5.1 [slice.arr.assign] as follows:
+<blockquote><pre>template&lt;class I, class E, class S&gt;
+struct codecvt : std::codecvt&lt;I, E, S&gt;
+{
+    ~codecvt()
+    { }
+};
 
-        </p>
-        <blockquote><pre>
-<code><ins>const</ins> slice_array&amp; operator= (const slice_array&amp;)<ins> const</ins>;</code>
+void main()
+{
+    std::wstring_convert&lt;codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt; compiles_ok;
+    
+    std::wstring_convert&lt;std::codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt;   not_ok;
+}
+</pre></blockquote>
 
-        </pre></blockquote>
-        <p>
 
-Change     the     signature     in    26.5.7 [template.gslice.array]     and
-26.5.7.1 [gslice.array.assign] as follows:
 
-        </p>
-        <blockquote><pre>
-<code><ins>const</ins> gslice_array&amp; operator= (const gslice_array&amp;)<ins> const</ins>;</code>
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
 
-        </pre></blockquote>
-        <p>
 
-Change the  signature in 26.5.8 [template.mask.array]  and 26.5.8.1 [mask.array.assign] as
-follows:
 
-        </p>
-        <blockquote><pre>
-<code><ins>const</ins> mask_array&amp; operator= (const mask_array&amp;)<ins> const</ins>;</code>
 
-        </pre></blockquote>
-        <p>
 
-Change     the     signature     in    26.5.9 [template.indirect.array] and
-26.5.9.1 [indirect.array.assign] as follows:
+<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>
 
-        </p>
-        <blockquote><pre>
-<code><ins>const</ins> indirect_array&amp; operator= (const indirect_array&amp;)<ins> const</ins>;</code>
+<blockquote><pre>float nanf(const char *tagp);
+long double nanl(const char *tagp);
+</pre></blockquote>
 
-        </pre></blockquote>
+<p>
+(Note: These functions cannot be overloaded and they are also not
+listed anywhere else)
+</p>
 
 
-<p><i>[
-Kona (2007) Added const qualification to the return types and set to Ready.
-]</i></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="622"></a>622. behavior of <code>filebuf</code> dtor and <code>close</code> on error</h3>
-<p><b>Section:</b> 27.8.1.17 [fstream.members] <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> 2007-01-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<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>
+ <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>Discussion:</b></p>
-        <p>
+<p>
+According to the current state of the standard draft, the class
+template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
+neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
+IMO it should be, because typical regex state machines tend
+to have a rather large data quantum and I have seen several
+use cases, where a factory function returns regex values,
+which would take advantage of moveabilities.
+</p>
 
-<code>basic_filebuf</code>  dtor is  specified to  have  the following
-straightforward effects:
 
-        </p>
-        <blockquote><p>
+<p><b>Proposed resolution:</b></p>
+<ol type="a">
+<li>
+<p>
+In the header <tt>&lt;regex&gt;</tt> synopsis 28.4 [re.syn], just below the function
+template <tt>swap</tt> add two further overloads:
+</p>
+<blockquote><pre>template &lt;class charT, class traits&gt; 
+  void swap(basic_regex&lt;charT, traits&gt;&amp; e1,  basic_regex&lt;charT, traits&gt;&amp; e2);
+<ins>template &lt;class charT, class traits&gt;
+  void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
+template &lt;class charT, class traits&gt;
+  void swap(basic_regex&lt;charT, traits&gt;&amp; e1,  basic_regex&lt;charT, traits&gt;&amp;&amp; e2);</ins>
+</pre></blockquote>
+<p>
+In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
+perform the following changes:
+</p>
+</li>
 
-<i>Effects</i>:       Destroys      an      object       of      class
-<code>basic_filebuf</code>. Calls <code>close()</code>.
+<li>
+<p>Just after the copy c'tor:</p>
+<blockquote><pre>basic_regex(basic_regex&amp;&amp;);
+</pre></blockquote>
+</li>
 
-        </p></blockquote>
-        <p>
+<li>
+<p>Just after the copy-assignment op.:</p>
+<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
+</pre></blockquote>
+</li>
 
-<code>close()</code> does a lot of potentially complicated processing,
-including calling <code>overflow()</code> to write out the termination
-sequence  (to   bring  the  output  sequence  to   its  initial  shift
-state). Since  any of the  functions called during the  processing can
-throw an exception, what should the  effects of an exception be on the
-dtor? Should the  dtor catch and swallow it or  should it propagate it
-to the caller?  The text doesn't  seem to provide any guidance in this
-regard  other  than  the  general  restriction on  throwing  (but  not
-propagating)  exceptions  from   destructors  of  library  classes  in
-17.4.4.8 [res.on.exception.handling].
+<li>
+<p>Just after the first <tt>assign</tt> overload insert:</p>
+<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
+</pre></blockquote>
+</li>
 
-        </p>
-        <p>
+<li>
+<p>Change the current <tt>swap</tt> function to read:</p>
+<blockquote><pre>void swap(basic_regex&amp;&amp;);
+</pre></blockquote>
+</li>
+
+<li>
+<p>In 28.8.2 [re.regex.construct], just below the copy c'tor add a
+corresponding member definition of:</p>
+<blockquote><pre>basic_regex(basic_regex&amp;&amp;);
+</pre></blockquote>
+</li>
 
-Further,  the last thing  <code>close()</code> is  specified to  do is
-call <code>fclose()</code> to close the <code>FILE</code> pointer. The
-last sentence of the <i>Effects</i> clause reads:
+<li>
+<p>Also in 28.8.2 [re.regex.construct], just below the copy assignment
+c'tor add a corresponding member definition of:</p>
+<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
+</pre></blockquote>
+</li>
+
+<li>
+<p>In 28.8.3 [re.regex.assign], just below the first <tt>assign</tt> overload add
+a corresponding member definition of:</p>
+<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
+</pre></blockquote>
+</li>
 
-        </p>
-        <blockquote><p>
+<li>
+<p>In 28.8.6 [re.regex.swap], change the signature of <tt>swap</tt> to
+say:</p>
+<blockquote><pre>void swap(basic_regex&amp;&amp; e);
+</pre></blockquote>
+</li>
 
-...   If    any   of    the   calls   to    <code>overflow</code>   or
-<code>std::fclose</code> fails then <code>close</code> fails.
+<li>
+<p>In 28.8.7.1 [re.regex.nmswap], just below the single binary <tt>swap</tt>
+function, add the two missing overloads:</p>
+<blockquote><pre>template &lt;class charT, class traits&gt;
+  void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
+template &lt;class charT, class traits&gt;
+  void swap(basic_regex&lt;charT, traits&gt;&amp; e1, basic_regex&lt;charT, traits&gt;&amp;&amp; e2);
+</pre></blockquote>
+</li>
+</ol>
 
-        </p></blockquote>
-        <p>
+<p>
+Of course there would be need of corresponding proper standardese
+to describe these additions.
+</p>
 
-This  suggests that  <code>close()</code>  might be  required to  call
-<code>fclose()</code>   if  and  only   if  none   of  the   calls  to
-<code>overflow()</code> fails, and avoid closing the <code>FILE</code>
-otherwise. This  way, if  <code>overflow()</code> failed to  flush out
-the data, the caller  would have  the opportunity to  try to  flush it
-again (perhaps  after trying  to deal with  whatever problem  may have
-caused the failure), rather than losing it outright.
 
-        </p>
-        <p>
 
-On the other hand,  the function's <i>Postcondition</i> specifies that
-<code>is_open() ==  false</code>, which  suggests that it  should call
-<code>fclose()</code>       unconditionally.       However,      since
-<i>Postcondition</i> clauses  are specified for many  functions in the
-standard,  including constructors  where they  obviously  cannot apply
-after an  exception, it's not clear  whether this <i>Postcondition</i>
-clause is intended to apply even after an exception.
 
-        </p>
-        <p>
 
-It  might  be worth  noting  that  the  traditional behavior  (Classic
-Iostreams  <code>fstream::close()</code> and  C <code>fclose()</code>)
-is  to  close  the  <code>FILE</code> unconditionally,  regardless  of
-errors.
 
-        </p>
+<hr>
+<h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</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> Pablo Halpern <b>Date:</b> 2007-09-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The <tt>DefaultConstructible</tt> requirement is referenced in
+several places in the August 2007 working draft
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
+but is not defined anywhere.
+</p>
 
 <p><i>[
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> for related issues.
+Bellevue:
 ]</i></p>
 
 
+<blockquote>
+<p>
+Walking into the default/value-initialization mess...
+</p>
+<p>
+Why two lines? Because we need both expressions to be valid.
+</p>
+<p>
+AJM not sure what the phrase "default constructed" means. This is
+unfortunate, as the phrase is already used 24 times in the library!
+</p>
+<p>
+Example: const int would not accept first line, but will accept the second.
+</p>
+<p>
+This is an issue that must be solved by concepts, but we might need to solve it independantly first.
+</p>
+<p>
+It seems that the requirements are the syntax in the proposed first
+column is valid, but not clear what semantics we need.
+</p>
+<p>
+A table where there is no post-condition seems odd, but appears to sum up our position best.
+</p>
+<p>
+At a minimum an object is declared and is destuctible.
+</p>
+<p>
+Move to open, as no-one happy to produce wording on the fly.
+</p>
+</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
-        <p>
-
-After discussing this  on the reflector (see the  thread starting with
-c++std-lib-17650) we propose that <code>close()</code> be clarified to
-match the traditional behavior, that is to close the <code>FILE</code>
-unconditionally,  even after  errors or  exceptions.  In  addition, we
-propose the dtor description be amended so as to explicitly require it
-to catch and swallow any exceptions thrown by <code>close()</code>.
+<p>
+In section 20.1.1 [utility.arg.requirements], before table 33, add the
+following table:
+</p>
 
-        </p>
-        <p>
+<p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
 
-Specifically,   we   propose   to   make  the   following   edits   in
-27.8.1.4 [filebuf.members]:
+<div align="center">
 
-        </p>
-        <blockquote>
-            <pre>
-<code>basic_filebuf&lt;charT,traits&gt;* close();</code>
+<table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0">
+ <tbody><tr>
+  <td style="border-style: solid none double solid; border-color: navy -moz-use-text-color navy navy; border-width: 1pt medium 1.5pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
+  <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p>
+  </td>
+  <td style="border-style: solid solid double none; border-color: navy navy navy -moz-use-text-color; border-width: 1pt 1pt 1.5pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
+  <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p>
+  </td>
+ </tr>
+ <tr>
+  <td style="border-style: none none solid solid; border-color: -moz-use-text-color -moz-use-text-color navy navy; border-width: medium medium 1pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
+  <p style="margin: 0in 0in 0.0001pt;"><tt>T
+  t;</tt><br>
+  <tt>T()</tt></p>
+  </td>
+  <td style="border-style: none solid solid none; border-color: -moz-use-text-color navy navy -moz-use-text-color; border-width: medium 1pt 1pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
+  <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt>
+  is <i>default constructed.</i></p>
+  </td>
+ </tr>
+</tbody></table>
 
-            </pre>
-            <p>
+</div>
 
-<i>Effects</i>:  If <code>is_open()  == false</code>,  returns  a null
-pointer.        If      a       put      area       exists,      calls
-<code>overflow(traits::eof())</code> to flush  characters. If the last
-virtual   member  function   called  on   <code>*this</code>  (between
-<code>underflow</code>,  <code>overflow</code>,  <code>seekoff</code>,
-and   <code>seekpos</code>)  was   <code>overflow</code>   then  calls
-<code>a_codecvt.unshift</code> (possibly several times) to determine a
-termination   sequence,    inserts   those   characters    and   calls
-<code>overflow(traits::eof())</code>  again.  Finally<ins>, regardless
-of whether  any of the preceding  calls fails or  throws an exception,
-the  function</ins> <del>it</del>  closes   the  file   ("as   if"  by   calling
-<code>std::fclose(file)</code>).<sup>334)</sup>  If any  of  the calls
-<ins>made    by   the    function</ins><del>to   <code>overflow</code>
-or</del><ins>,  including  </ins><code>std::fclose</code><ins>, </ins>
-fails then <code>close</code> fails<ins>  by returning a null pointer.
-If one of these calls throws an exception, the exception is caught and
-rethrown after closing the file.</ins>
 
-            </p>
-        </blockquote>
-        <p>
 
-And to make the following edits in 27.8.1.2 [filebuf.cons].
 
-        </p>
-        <blockquote>
-            <pre>
-<code>virtual ~basic_filebuf();</code>
 
-            </pre>
-            <p>
 
-<i>Effects</i>:       Destroys      an      object       of      class
-<code>basic_filebuf&lt;charT,traits&gt;</code>.                   Calls
-<code>close()</code>.    <ins>If  an   exception  occurs   during  the
-destruction of the object, including the call to <code>close()</code>,
-the     exception    is     caught    but     not     rethrown    (see
-17.4.4.8 [res.on.exception.handling]).</ins>
+<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>
+ <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>Discussion:</b></p>
+<p>
+Two overloads of <tt>regex_replace()</tt> are currently provided:
+</p>
 
-            </p>
-        </blockquote>
+<blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator, 
+    class traits, class charT&gt; 
+  OutputIterator 
+  regex_replace(OutputIterator out, 
+                BidirectionalIterator first, BidirectionalIterator last, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const basic_string&lt;charT&gt;&amp; fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+ 
+template &lt;class traits, class charT&gt; 
+  basic_string&lt;charT&gt; 
+  regex_replace(const basic_string&lt;charT&gt;&amp; s, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const basic_string&lt;charT&gt;&amp; fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
+</pre></blockquote>
 
+<ol>
+<li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
+<tt>regex_search()</tt>, but not <tt>regex_replace()</tt>.  This is inconsistent.</li>
+<li>
+<p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
 
+<blockquote><pre>const string s("kitten");
+const regex r("en");
+cout &lt;&lt; regex_replace(s, r, "y") &lt;&lt; endl;
+</pre></blockquote>
 
+<p>
+The compiler error message will be something like "could not deduce
+template argument for 'const std::basic_string&lt;_Elem&gt; &amp;' from 'const
+char[1]'".
+</p>
 
+<p>
+Users expect that anything taking a <tt>basic_string&lt;charT&gt;</tt> can also take a
+<tt>const charT *</tt>.  In their own code, when they write a function taking
+<tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
+wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor.  Because the
+regex algorithms are templated on <tt>charT</tt>, they can't rely on
+<tt>basic_string</tt>'s implicit constructor (as the compiler error message
+indicates, template argument deduction fails first).
+</p>
 
-<hr>
-<h3><a name="623"></a>623. <code>pubimbue</code> forbidden to call <code>imbue</code></h3>
-<p><b>Section:</b> 27.1.1 [iostream.limits.imbue] <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> 2007-01-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-        <p>
+<p>
+If a user figures out what the compiler error message means, workarounds
+are available - but they are all verbose.  Explicit template arguments
+could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
+constructor to be invoked - but <tt>charT</tt> is the last template argument, not
+the first, so this would be extremely verbose.  Therefore, constructing
+a <tt>basic_string</tt> from each C string is the simplest workaround.
+</p>
+</li>
 
-27.1.1 [iostream.limits.imbue]  specifies  that  "no  function  described  in
-clause 27 except  for <code>ios_base::imbue</code> causes any instance
-of                   <code>basic_ios::imbue</code>                  or
-<code>basic_streambuf::imbue</code> to be called."
+<li>
+There is an efficiency consideration: constructing <tt>basic_string</tt>s can
+impose performance costs that could be avoided by a library
+implementation taking C strings and dealing with them directly. 
+(Currently, for replacement sources, C strings can be converted into
+iterator pairs at the cost of verbosity, but for format strings, there
+is no way to avoid constructing a <tt>basic_string</tt>.)
+</li>
+</ol>
 
-        </p>
-        <p>
 
-That      contradicts      the      <i>Effects</i>     clause      for
-<code>basic_streambuf::pubimbue()</code>  which requires  the function
-to do just that: call <code>basic_streambuf::imbue()</code>.
 
-        </p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Provide additional overloads for <tt>regex_replace()</tt>: one additional
+overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
+additional overloads of the convenience form (one taking <tt>const charT*
+str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
+charT* str</tt> and <tt>const charT* fmt</tt>).  28.11.4 [re.alg.replace]:
+</p>
 
+<blockquote>
+<pre>template &lt;class OutputIterator, class BidirectionalIterator, 
+    class traits, class charT&gt; 
+  OutputIterator 
+  regex_replace(OutputIterator out, 
+                BidirectionalIterator first, BidirectionalIterator last, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const basic_string&lt;charT&gt;&amp; fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
 
-<p><b>Proposed resolution:</b></p>
-        <p>
+<ins>template &lt;class OutputIterator, class BidirectionalIterator, 
+    class traits, class charT&gt; 
+  OutputIterator 
+  regex_replace(OutputIterator out, 
+                BidirectionalIterator first, BidirectionalIterator last, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const charT* fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);</ins>
+</pre>
+<p>...</p>
+<pre>template &lt;class traits, class charT&gt; 
+  basic_string&lt;charT&gt; 
+  regex_replace(const basic_string&lt;charT&gt;&amp; s, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const basic_string&lt;charT&gt;&amp; fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);
 
-To    fix   this,    rephrase    the   sentence    above   to    allow
-<code>pubimbue</code> to do what  it was designed to do. Specifically.
-change 27.1.1 [iostream.limits.imbue], p1 to read:
+<ins>template &lt;class traits, class charT&gt; 
+  basic_string&lt;charT&gt; 
+  regex_replace(const basic_string&lt;charT&gt;&amp; s, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const charT* fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);</ins>
 
-        </p>
-        <blockquote><p>
+<ins>template &lt;class traits, class charT&gt; 
+  basic_string&lt;charT&gt; 
+  regex_replace(const charT* s, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const basic_string&lt;charT&gt;&amp; fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);</ins>
 
-No     function    described     in    clause     27     except    for
-<code>ios_base::imbue</code>  <ins>and <code>basic_filebuf::pubimbue</code></ins>
-causes    any    instance    of    <code>basic_ios::imbue</code>    or
-<code>basic_streambuf::imbue</code> to be called. ...
+<ins>template &lt;class traits, class charT&gt; 
+  basic_string&lt;charT&gt; 
+  regex_replace(const charT* s, 
+                const basic_regex&lt;charT, traits&gt;&amp; e, 
+                const charT* fmt, 
+                regex_constants::match_flag_type flags = 
+                  regex_constants::match_default);</ins>
+</pre>
+</blockquote>
 
-        </p></blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="624"></a>624. <code>valarray</code> assignment and arrays of unequal length</h3>
-<p><b>Section:</b> 26.5.2.2 [valarray.assign] <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> 2007-01-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
+<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>Discussion:</b></p>
-        <p>
-
-The behavior of the  <code>valarray</code> copy assignment operator is
-defined only when both sides have  the same number of elements and the
-spec is explicit about assignments of arrays of unequal lengths having
-undefined behavior.
+<p>
+<tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string&lt;charT, ST,
+SA&gt;&amp;</tt>.  <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</tt>.  This prevents
+<tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
+allocators.
+</p>
 
-        </p>
-        <p>
 
-However, the generalized  subscripting assignment operators overloaded
-on <code>slice_array</code>  et al (26.5.2.2 [valarray.assign])  don't have any
-such restriction, leading  the reader to believe that  the behavior of
-these  overloads is  well defined  regardless  of the  lengths of  the
+<p><b>Proposed resolution:</b></p>
+<p>
+Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
+templated on <tt>class ST, class SA</tt> and take <tt>const basic_string&lt;charT, ST,
+SA&gt;&amp;</tt>.  Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
+<tt>class ST, class SA</tt> as the first template arguments; compatibility with
+existing code using TR1 and giving explicit template arguments to
+<tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
 arguments.
+</p>
 
-        </p>
-        <p>
-
-For example,  based on  the reading  of the spec  the behavior  of the
-snippet below can be expected to be well-defined:
-
-        </p>
-        <pre>    const std::slice from_0_to_3 (0, 3, 1);   // refers to elements 0, 1, 2
-    const std::valarray&lt;int&gt; a (1, 3);        // a = { 1, 1, 1 }
-    std::valarray&lt;int&gt;       b (2, 4);        // b = { 2, 2, 2, 2 }
 
-    b = a [from_0_to_3];
-        </pre>
-        <p>
 
-In practice, <code>b</code> may end up being <code>{ 1, 1, 1 }</code>,
-<code>{  1,  1, 1,  2  }</code>,  or  anything else,  indicating  that
-existing implementations vary.
 
-        </p>
 
+<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>
+ <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>Discussion:</b></p>
 <p>
-Quoting from Section 3.4, Assignment operators, of Al Vermeulen's
-Proposal for Standard C++ Array Classes (see c++std-lib-704;
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>):
+The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given 
+as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization 
+of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate 
+for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in 
+which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M. 
+Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
+[<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-64.c">reference</a>].
 </p>
-<blockquote><p>
-  ...if the size of the array on the right hand side of the equal
-  sign differs from the size of the array on the left, a run time
-  error occurs. How this error is handled is implementation
-  dependent; for compilers which support it, throwing an exception
-  would be reasonable.
-</p></blockquote>
 
 <p>
-And see more history in
-<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1993/N0280.pdf">N0280</a>.
+I see two possible resolutions: 
 </p>
 
-        <p>
-
-It has  been argued in  discussions on the committee's  reflector that
-the semantics of all <code>valarray</code> assignment operators should
-be permitted to be undefined unless  the  length  of the arrays  being
-assigned is the same as the length of the one being assigned from. See
-the thread starting at c++std-lib-17786.
-
-        </p>
-        <p>
-
-In order  to reflect  such views, the  standard must specify  that the
-size of the  array referred to by the argument  of the assignment must
-match the size of the array  under assignment, for example by adding a
-<i>Requires</i> clause to 26.5.2.2 [valarray.assign] as follows:
+<ol type="a">
+<li>Restrict the parameter <tt>W</tt> of the <tt>mersenne_twister_template</tt> to values of 32 or 64 and use the 
+multiplier from [the above reference] for the 64-bit case (my preference)</li>
+<li>Interpret the state array for any <tt>W</tt> as a 32-bit array of appropriate length (and a specified byte 
+order) and always employ the 32-bit algorithm for seeding
+</li>
+</ol>
 
-        </p>
-        <blockquote><p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for further discussion.
+</p>
 
-<i>Requires</i>: The length of the  array to which the argument refers
-equals <code>size()</code>.
+<p><i>[
+Bellevue:
+]</i></p>
 
-        </p></blockquote>
 
-        <p>
+<blockquote>
+<p>
+Stephan Tolksdorf has additional comments on N2424. He comments: "there
+is a typo in the required behaviour for mt19937_64: It should be the
+10000th (not 100000th) invocation whose value is given, and the value
+should be 9981545732273789042 (not 14002232017267485025)." These values
+need checking.
+</p>
+<p>
+Take the proposed recommendation in N2424 and move to REVIEW.
+</p>
+</blockquote>
 
-Note that it's  far from clear that such leeway  is necessary in order
-to implement <code>valarray</code> efficiently.
 
-        </p>
 
 
 <p><b>Proposed resolution:</b></p>
+
 <p>
-Insert new paragraph into 26.5.2.2 [valarray.assign]:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
 </p>
 
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
+
+
 <blockquote>
-<pre>valarray&lt;T&gt;&amp; operator=(const slice_array&lt;T&gt;&amp;); 
-valarray&lt;T&gt;&amp; operator=(const gslice_array&lt;T&gt;&amp;); 
-valarray&lt;T&gt;&amp; operator=(const mask_array&lt;T&gt;&amp;); 
-valarray&lt;T&gt;&amp; operator=(const indirect_array&lt;T&gt;&amp;);
-</pre>
-<blockquote>
-<p><ins>
-<i>Requires</i>: The length of the  array to which the argument refers
-equals <code>size()</code>.
-</ins></p>
-<p>
-These operators allow the results of a generalized subscripting operation to be assigned directly to a <tt>valarray</tt>.
-</p>
-</blockquote>
+I support the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>,
+but there is a typo in the
+required behaviour for <tt>mt19937_64</tt>: It should be the 10000<sup>th</sup> (not
+100000<sup>th</sup>) invocation whose value is given, and the value should be
+9981545732273789042 (not 14002232017267485025). The change to para. 8
+proposed by Charles Karney should also be included in the proposed
+wording.
 </blockquote>
 
 
 
 
 
+
 <hr>
-<h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3>
+<p><b>Section:</b> 26.4.8.5.3 [rand.dist.samp.genpdf] <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> 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.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</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#795">795</a></p>
 <p><b>Discussion:</b></p>
-        <p>
-
-Many  member functions  of  <code>basic_string</code> are  overloaded,
-with  some of  the  overloads taking  a <code>string</code>  argument,
-others  <code>value_type*</code>,  others <code>size_type</code>,  and
-others still <code>iterators</code>. Often, the requirements on one of
-the   overloads  are   expressed  in   the  form   of  <i>Effects</i>,
-<i>Throws</i>,      and     in      the     Working      Paper     
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
-also <i>Remark</i> clauses,  while those on the rest  of the overloads
-via a reference to this overload and using a <i>Returns</i> clause.
-
-        </p><p>
-        </p>
+<p>
+26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is 
+meant to simulate random numbers from any general distribution given only the density and the 
+support of the distribution. I'm not aware of any general purpose algorithm that would be capable 
+of correctly and efficiently implementing the described functionality. From what I know, this is 
+essentially an unsolved research problem. Existing algorithms either require more knowledge 
+about the distribution and the problem domain or work only under very limited circumstances. 
+Even the state of the art special purpose library UNU.RAN does not solve the problem in full 
+generality, and in any case, testing and customer support for such a library feature would be a 
+nightmare.
+</p>
 
-The  difference between  the two  forms of  specification is  that per
-17.3.1.3 [structure.specifications],  p3,  an  <i>Effects</i> clause  specifies
-<i>"actions  performed  by the  functions,"</i>  i.e., its  observable
-effects,  while a <i>Returns</i>  clause is  <i>"a description  of the
-return  value(s)   of  a  function"</i>  that  does   not  impose  any
-requirements on the function's observable effects.
+<p>
+<b>Possible resolution:</b> For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
+</p>
 
-        <p>
-        </p>
+<p><i>[
+Bellevue:
+]</i></p>
 
-Since only  <i>Notes</i> are explicitly defined to  be informative and
-all  other paragraphs  are explicitly  defined to  be  normative, like
-<i>Effects</i> and <i>Returns</i>,  the new <i>Remark</i> clauses also
-impose normative requirements.
 
-        <p>
-        </p>
+<blockquote>
+<p>
+Disagreement persists.
+</p>
+<p>
+Objection to this issue is that this function takes a general functor.
+The general approach would be to normalize this function, integrate it,
+and take the inverse of the integral, which is not possible in general.
+An example function is sin(1+n*x) -- for any spatial frequency that the
+implementor chooses, there is a value of n that renders that choice
+arbitrarily erroneous.
+</p>
+<p>
+Correction: The formula above should instead read 1+sin(n*x).
+</p>
+<p>
+Objector proposes the following possible compromise positions:
+</p>
+<ul>
+<li>
+rand.dist.samp.genpdf takes an number of points so that implementor need not guess.
+</li>
+<li>replace rand.disk.samp.genpdf with an extension to either or both
+of the discrete functions to take arguments that take a functor and
+number of points in place of the list of probabilities. Reference
+issues 793 and 794.
+</li>
+</ul>
+</blockquote>
 
-So  by this  strict  reading of  the  standard there  are some  member
-functions of  <code>basic_string</code> that are required  to throw an
-exception under  some conditions or use specific  traits members while
-many other otherwise equivalent overloads, while obliged to return the
-same  values, aren't required  to follow  the exact  same requirements
-with regards to the observable effects.
 
-        <p>
-        </p>
 
-Here's an example of this  problem that was precipitated by the change
-from informative Notes to normative <i>Remark</i>s (presumably made to
-address <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>):
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
 
-        <p>
-        </p>
 
-In the Working  Paper, <code>find(string, size_type)</code> contains a
-<i>Remark</i>  clause (which  is  just a  <i>Note</i>  in the  current
-standard) requiring it to use <code>traits::eq()</code>.
 
-        <p>
-        </p>
 
-<code>find(const  charT  *s,  size_type  pos)</code> is  specified  to
-return  <code>find(string(s), pos)</code>  by a  <i>Returns</i> clause
-and so  it is not required to  use <code>traits::eq()</code>. However,
-the Working  Paper has  replaced the original  informative <i>Note</i>
-about   the  function   using  <code>traits::length()</code>   with  a
-normative  requirement  in  the   form  of  a  <i>Remark</i>.  Calling
-<code>traits::length()</code> may be  suboptimal, for example when the
-argument is a  very long array whose initial  substring doesn't appear
-anywhere in <code>*this</code>.
 
-        <p>
-        </p>
+<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>
+ <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>Discussion:</b></p>
+<p>
+<tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt>
+have parameters for the "degrees of freedom" <tt>n</tt> and <tt>m</tt> that are specified as integers. For the 
+following two reasons this is an unnecessary restriction: First, in many applications such as 
+Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param- 
+eters as continuous variables. Second, the standard non-naive algorithms (i.e. 
+O(1) algorithms) 
+for simulating from these distributions work with floating-point parameters anyway (all three 
+distributions could be easily implemented using the Gamma distribution, for instance).
+</p>
 
-Here's another  similar example,  one that existed  even prior  to the
-introduction of <i>Remark</i>s:
+<p>
+Similar arguments could in principle be made for the parameters <tt>t</tt> and <tt>k</tt> of the discrete 
+<tt>binomial_distribution</tt> and <tt>negative_binomial_distribution</tt>, though in both cases continuous
+parameters are less frequently used in practice and in case of the <tt>binomial_distribution</tt>
+the implementation would be significantly complicated by a non-discrete parameter (in most 
+implementations one would need an approximation of the log-gamma function instead of just the 
+log-factorial function).
+</p>
 
-        <p>
-        </p>
+<p>
+<b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters 
+to double.
+</p>
 
-<code> insert(size_type  pos, string, size_type,  size_type)</code> is
-required   to   throw   <code>out_of_range</code>   if   <code>pos   &gt;
-size()</code>.
+<p><i>[
+Bellevue:
+]</i></p>
 
-        <p>
-        </p>
 
-<code>insert(size_type pos, string  str)</code> is specified to return
-<code>insert(pos, str, 0, npos)</code>  by a <i>Returns</i> clause and
-so its  effects when <code>pos  &gt; size()</code> are  strictly speaking
-unspecified.
+<blockquote>
+In N2424. Not wildly enthusiastic, not really felt necessary. Less
+frequently used in practice. Not terribly bad either. Move to OPEN.
+</blockquote>
 
-        
-        <p>
 
-I  believe  a  careful   review  of  the  current  <i>Effects</i>  and
-<i>Returns</i>  clauses  is  needed  in  order to  identify  all  such
-problematic cases. In  addition, a review of the  Working Paper should
-be done to make sure that the newly introduced normative <i>Remark</i>
-clauses do not impose  any undesirable normative requirements in place
-of the original informative <i>Notes</i>.
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
 
-        </p>
 <p><i>[
-Batavia:  Alan and Pete to work.
+Stephan Tolksdorf adds pre-Bellevue:
 ]</i></p>
 
 
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
+In 26.4.8.4.3 [rand.dist.norm.chisq]:
 </p>
 
+<blockquote>
+<p>
+Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
+</p>
 
+<p>
+Replace both occurrences of "<tt>explicit chi_squared_distribution(int n = 1);</tt>"
+with "<tt>explicit chi_squared_distribution(RealType n = 1);</tt>".
+</p>
 
+<p>
+Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
+</p>
 
+</blockquote>
 
-<hr>
-<h3><a name="626"></a>626. new <i>Remark</i> clauses not documented</h3>
-<p><b>Section:</b> 17.3.1.3 [structure.specifications] <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-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
-<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>
+<p>
+In 26.4.8.4.5 [rand.dist.norm.f]:
+</p>
+<blockquote>
+<p>
+Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph.
+</p>
 
-The <i>Remark</i> clauses newly  introduced into the Working Paper 
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
-are  not mentioned  in  17.3.1.3 [structure.specifications] where  we list  the
-meaning  of <i>Effects</i>, <i>Requires</i>,  and other  clauses (with
-the exception  of <i>Notes</i> which are documented  as informative in
-17.3.1.1 [structure.summary], p2, and which they replace in many cases).
+<p>
+Replace both occurrences of
+</p>
+<blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1);
+</pre></blockquote>
+<p>
+with
+</p>
+<blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
+</pre></blockquote>
 
-        </p>
-        <p>
+<p>
+Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>".
+</p>
 
-Propose add a bullet for <i>Remarks</i> along with a brief description.
+<p>
+Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>".
+</p>
+</blockquote>
 
-        </p>
-<p><i>[
-Batavia:  Alan and Pete to work.
-]</i></p>
+<p>
+In 26.4.8.4.6 [rand.dist.norm.t]:
+</p>
 
+<blockquote>
+<p>
+Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
+</p>
 
+<p>
+Replace both occurrences of "<tt>explicit student_t_distribution(int n = 1);</tt>"
+with "<tt>explicit student_t_distribution(RealType n = 1);</tt>".
+</p>
 
-<p><b>Proposed resolution:</b></p>
 <p>
+Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
 </p>
+</blockquote>
+
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="627"></a>627. Low memory and exceptions</h3>
-<p><b>Section:</b> 18.5.1.1 [new.delete.single] <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> 2007-01-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<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>
 <p><b>Discussion:</b></p>
 <p>
-I recognize the need for nothrow guarantees in the exception reporting
-mechanism, but I strongly believe that implementors also need an escape hatch
-when memory gets really low. (Like, there's not enough heap to construct and
-copy exception objects, or not enough stack to process the throw.) I'd like to
-think we can put this escape hatch in 18.5.1.1 [new.delete.single],
-<tt>operator new</tt>, but I'm not sure how to do it. We need more than a
-footnote, but the wording has to be a bit vague. The idea is that if
-<tt>new</tt> can't allocate something sufficiently small, it has the right to
-<tt>abort</tt>/call <tt>terminate</tt>/call <tt>unexpected</tt>.
+Please don't provide <tt>*_ptr&lt;T[N]&gt;</tt>. It doesn't enable any useful
+bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
+<tt>shared_ptr&lt;T[N]&gt;</tt> yields a <tt>shared_ptr&lt;T[N-1]&gt;</tt>, but that promising path
+immediately falters on <tt>op--</tt> which can't reliably dereference because we
+don't know the lower bound). Also, most buffers you'd want to point to
+don't have a compile-time known size.
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
+To enable any bounds-checking would require run-time information, with
+the usual triplet: base (lower bound), current offset, and max offset
+(upper  bound). And I can sympathize with the point of view that you
+wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
+follow the <tt>&lt;T[N]&gt;</tt> path, especially not with additional functions to
+query the bounds etc., because this sets wrong user expectations by
+embarking on a path that doesn't go all the way to bounds checking as it
+seems to imply.
 </p>
 
+<p>
+If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
+<tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
+user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
+debug builds and not doing so on release builds (for example).
+</p>
 
-
-
-
-<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#Open">Open</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#Open">Open</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.
+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>
-Further notes/ideas from the lib-reflector, messages 17982-17984:
-</p>
+<p><i>[
+Bellevue:
+]</i></p>
+
 
 <blockquote>
-<p>
-Add additional entries in num_punct to cover the complex separator (French would be ';').
+<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>
-Insert a space before the comma, which should eliminate the ambiguity.
+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>
-Solve the problem for ordered sequences in general, perhaps with a
-dedicated facet.  Then complex should use that solution.
+straw poll unanimous move to Ready.
 </p>
 </blockquote>
 
@@ -7931,946 +11682,815 @@ dedicated facet.  Then complex should use that solution.
 
 <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="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>
-        <p>
-
-Section 26.1 [numeric.requirements], p1     suggests     that     a
-<code>valarray</code>  specialization on  a  type <code>T</code>  that
-satisfies  the requirements enumerated  in the  paragraph is  itself a
-valid  type   on  which  <code>valarray</code>   may  be  instantiated
-(Footnote       269        makes       this       clear).        I.e.,
-<code>valarray&lt;valarray&lt;T&gt;  &gt;</code> is  valid as  long as
-<code>T</code>   is   valid.    However,  since   implementations   of
-<code>valarray</code> are permitted to initialize storage allocated by
-the class by  invoking the default ctor of  <code>T</code> followed by
-the    copy    assignment    operator,   such    implementations    of
-<code>valarray</code>   wouldn't  work  with   (perhaps  user-defined)
-specializations of <code>valarray</code> whose assignment operator had
-undefined behavior when the size of its argument didn't match the size
-of <code>*this</code>.  By <i>"wouldn't work"</i> I mean that it would
-be  impossible  to resize  such  an array  of  arrays  by calling  the
-<code>resize()</code> member  function on it if the  function used the
-copy  assignment operator  after constructing  all elements  using the
-default  ctor (e.g.,  by invoking  <code>new  value_type[N]</code>) to
-obtain default-initialized storage) as it's permitted to do.
-
-        </p>
-        <p>
-
-Stated      more     generally,      the      problem     is      that
-<code>valarray&lt;valarray&lt;T&gt;  &gt;::resize(size_t)</code> isn't
-required or  guaranteed to have well-defined semantics  for every type
-<code>T</code>     that      satisfies     all     requirements     in
-26.1 [numeric.requirements].
 
-        </p>
-        <p>
 
-I  believe  this  problem  was  introduced  by  the  adoption  of  the
-resolution                outlined                in                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
-<i>Assignment  of  valarrays</i>,  from  1996.   The  copy  assignment
-operator  of  the original  numerical  array  classes  proposed in  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0280.pdf">N0280</a>,
-as      well       as      the      one       proposed      in      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
-(both  from 1993), had  well-defined semantics  for arrays  of unequal
-size (the  latter explicitly  only when <code>*this</code>  was empty;
-assignment of non empty arrays of unequal size was a runtime error).
 
-        </p>
-        <p>
 
-The  justification for  the  change given  in  N0857 was the "loss  of
-performance [deemed]  only significant  for very simple  operations on
-small arrays or for architectures with very few registers."
 
-        </p>
-        <p>
+<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>
 
-Since tiny  arrays on a  limited subset of hardware  architectures are
-likely  to  be  an   exceedingly  rare  case  (despite  the  continued
-popularity of  x86) I  propose to revert  the resolution and  make the
-behavior    of   all   <code>valarray</code>    assignment   operators
-well-defined even  for non-conformal  arrays (i.e., arrays  of unequal
-size).   I have implemented  this change  and measured  no significant
-degradation  in performance in  the common  case (non-empty  arrays of
-equal size).  I  have measured a 50% (and in  some cases even greater)
-speedup  in the  case of  assignments to  empty arrays  versus calling
-<code>resize()</code>  first followed  by  an invocation  of the  copy
-assignment operator.
+<p>
+This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators.  Here
+is example code:
+</p>
 
-        </p>
+<blockquote><pre>namespace Mine {
 
+template &lt;class T&gt;
+struct proxy {...};
 
-<p><b>Proposed resolution:</b></p>
-        <p>
+template &lt;class T&gt;
+struct proxied_iterator
+{
+   typedef T value_type;
+   typedef proxy&lt;T&gt; reference;
+   reference operator*() const;
+   ...
+};
 
-Change 26.5.2.2 [valarray.assign], p1 as follows:
+struct A
+{
+   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
+   void swap(A&amp;);
+   ...
+};
 
-        </p>
-        <blockquote>
-            <p>
-                <code>
+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;);
 
-valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;<ins> x</ins>);
+}  // Mine
 
-                </code>
-            </p>
-            <p>
+...
 
--1- Each element of the <code>*this</code> array is assigned the value
-of  the  corresponding  element   of  the  argument  array.   <del>The
-resulting behavior is undefined if </del><ins>When </ins>the length of
-the  argument  array  is  not   equal  to  the  length  of  the  *this
-array<del>.</del><ins>  resizes  <code>*this</code>  to make  the  two
-arrays     the      same     length,     as      if     by     calling
-<code>resize(x.size())</code>, before performing the assignment.</ins>
+Mine::proxied_iterator&lt;Mine::A&gt; i(...)
+Mine::A a;
+<b>swap(*i1, a);</b>
+</pre></blockquote>
 
-            </p>
-        </blockquote>
-        <p>
+<p>
+The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
+and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
+same type).  A secondary point is that to support proxies, one must be able to pass rvalues
+to <tt>swap</tt>.  But note that I am not stating that the general purpose <tt>std::swap</tt>
+should accept rvalues!  Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
+to take rvalues.
+</p>
 
-And  add a new  paragraph just  below paragraph  1 with  the following
-text:
+<p>
+That is, no standard library code needs to change.  We simply need to have a more flexible
+definition of <tt>Swappable</tt>.
+</p>
 
-        </p>
-        <blockquote>
-            <p>
+<p><i>[
+Bellevue:
+]</i></p>
 
-<ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
 
-            </p>
-        </blockquote>
-        <p>
+<blockquote>
+<p>
+While we believe Concepts work will define a swappable concept, we
+should still resolve this issue if possible to give guidance to the
+Concepts work.
+</p>
+<p>
+Would an ambiguous swap function in two namespaces found by ADL break
+this wording? Suggest that the phrase "valid expression" means such a
+pair of types would still not be swappable.
+</p>
+<p>
+Motivation is proxy-iterators, but facility is considerably more
+general. Are we happy going so far?
+</p>
+<p>
+We think this wording is probably correct and probably an improvement on
+what's there in the WP. On the other hand, what's already there in the
+WP is awfully complicated. Why do we need the two bullet points? They're
+too implementation-centric. They don't add anything to the semantics of
+what swap() means, which is there in the post-condition. What's wrong
+with saying that types are swappable if you can call swap() and it
+satisfies the semantics of swapping?
+</p>
+</blockquote>
 
-Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4:
 
-        </p>
-        <blockquote>
-            <p>
 
-<ins>-?- When the length,  <i><code>N</code></i> of the array referred
-to by the  argument is not equal to  the length of <code>*this</code>,
-the  operator resizes <code>*this</code>  to make  the two  arrays the
-same  length, as if  by calling  <code>resize(<i>N</i>)</code>, before
-performing the assignment.</ins>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.1.1 [utility.arg.requirements]:
+</p>
 
-            </p>
-        </blockquote>
+<blockquote>
 
+<p>
+-1- The template definitions in the C++ Standard Library refer to various
+named requirements whose details are set out in tables 31-38. In these
+tables, <tt>T</tt> <ins>and <tt>V</tt> are</ins> <del>is a</del> type<ins>s</ins> to be supplied by a C++ program
+instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
+values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
+lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
+<tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
+rvalue of type <tt>T</tt><ins>; <tt>w</tt> is a value of type <tt>T</tt>; and <tt>v</tt> is a value of type <tt>V</tt></ins>.
+</p>
+
+<table border="1">
+<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
+<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
+<tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
+<td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
+held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
+<del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
+by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
+<tr><td colspan="3">
+<p>
+The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
+</p>
+<ul>
+<li>
+<tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
+the same type and </ins> <tt>T</tt> satisfies the
+<del><tt>CopyConstructible</tt></del>
+<ins><tt>MoveConstructible</tt></ins> requirements (Table <del>34</del>
+<ins>33</ins>) and the <del><tt>CopyAssignable</tt></del>
+<ins><tt>MoveAssignable</tt></ins> requirements (Table <del>36</del>
+<ins>35</ins>);
+</li>
+<li>
+<tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
+<tt>swap</tt> exists in the same namespace as the definition of
+<tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
+<tt>swap(<del>t</del><ins>w</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the
+semantics described in this table.
+</li>
+</ul>
+</td></tr>
+</tbody></table>
+</blockquote>
 
-<p><i>[
-Kona (2007): Gaby to propose wording for an alternative resolution in
-which you can assign to a <tt>valarray</tt> of size 0, but not to any other
-<tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
-]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3>
-<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> James Kanze <b>Date:</b> 2007-01-31</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<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>
-The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for
-some functions. In particular, it says that:
+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>
-[...] if an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt>
-as its argument and <tt><i>first1</i></tt> and <i>first2</i> as its
-iterator arguments, it should work correctly in the construct <tt>if
-(binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt>.
-<tt>BinaryPredicate</tt> always takes the first iterator type as its
-first argument, that is, in those cases when <tt>T <i>value</i></tt> is
-part of the signature, it should work correctly in the context of <tt>if
-(binary_pred (*<i>first1</i> , <i>value</i>)){...}</tt>.
+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>
-In the description of <tt>upper_bound</tt> (25.3.3.2 [upper.bound]/2), however, the use is described as
-"<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an
-element of the sequence (a result of dereferencing
-<tt>*<i>first</i></tt>).
+This issue was opened in response to that note.
 </p>
 
 <p>
-In the description of <tt>lexicographical_compare</tt>, we have both
-"<tt>*<i>first1</i> &lt; *<i>first2</i></tt>" and "<tt>*<i>first2</i>
-&lt; *<i>first1</i></tt>" (which presumably implies "<tt>comp(
-*<i>first1</i>, *<i>first2</i> )</tt>" and "<tt>comp( *<i>first2</i>,
-*<i>first1</i> )</tt>".
+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>[
-Toronto:  Moved to Open.  ConceptGCC seems to get <tt>lower_bound</tt>
-and <tt>upper_bound</tt> to work withoutt these changes.
+Bellevue:
 ]</i></p>
 
 
-
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
-Logically, the <tt>BinaryPredicate</tt> is used as an ordering
-relationship, with the semantics of "less than".  Depending on the
-function, it may be used to determine equality, or any of the inequality
-relationships; doing this requires being able to use it with either
-parameter first.  I would thus suggest that the requirement be:
+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>
-
-<blockquote><p>
-[...] <tt>BinaryPredicate</tt> always takes the first iterator
-<tt>value_type</tt> as one of its arguments, it is unspecified which. If
-an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt> as its
-argument and <tt><i><i>first1</i></i></tt> and <i>first2</i> as its
-iterator arguments, it should work correctly both in the construct
-<tt>if (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt> and
-<tt>if (binary_pred (*<i>first2</i>, *<i>first1</i>)){...}</tt>.  In
-those cases when <tt>T <i>value</i></tt> is part of the signature, it
-should work correctly in the context of <tt>if (binary_pred
-(*<i>first1</i> , <i>value</i>)){...}</tt> and of <tt>if (binary_pred
-(<i>value</i>, *<i>first1</i>)){...}</tt>. [<i>Note:</i> if the two
-types are not identical, and neither is convertable to the other, this
-may require that the <tt>BinaryPredicate</tt> be a functional object
-with two overloaded <tt>operator()()</tt> functions. <i>--end note</i>]
-</p></blockquote>
-
 <p>
-Alternatively, one could specify an order for each function. IMHO, this
-would be more work for the committee, more work for the implementors,
-and of no real advantage for the user: some functions, such as
-<tt>lexicographical_compare</tt> or <tt>equal_range</tt>, will still require both
-functions, and it seems like a much easier rule to teach that both
-functions are always required, rather than to have a complicated list of
-when you only need one, and which one.
+Adopt issue as written.
 </p>
+</blockquote>
 
 
-
-
-
-<hr>
-<h3><a name="632"></a>632. Time complexity of size() for std::set</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> Lionel B <b>Date:</b> 2007-02-01</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>
-A recent news group discussion:
-</p>
-<blockquote>
-<p>
-Anyone know if the Standard has anything to say about the time complexity
-of size() for std::set?   I need to access a set's size (/not/ to know if it is empty!) heavily
-during an algorithm and was thus wondering whether I'd be better off
-tracking the size "manually" or whether that'd be pointless.
-</p>
-<p>
-That would be pointless. size() is O(1).
-</p>
+<p><b>Proposed resolution:</b></p>
 <p>
-Nit: the standard says "should" have constant time. Implementations may take
-license to do worse. I know that some do this for <tt>std::list&lt;&gt;</tt> as a part of
-some trade-off with other operation.
+Change the synopsis in 20.6.12.2 [util.smartptr.shared]:
 </p>
 
-<p>
-I was aware of that, hence my reluctance to use size() for std::set.
-</p>
-<p>
-However, this reason would not apply to <tt>std::set&lt;&gt;</tt> as far as I can see.
-</p>
-<p>
-Ok, I guess the only option is to try it and see...
-</p>
-</blockquote>
+<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>
-If I have any recommendation to the C++ Standards Committee it is that
-implementations must (not "should"!) document clearly[1], where known, the
-time complexity of *all* container access operations.
-</p>
-<p>
-[1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()
-for std::set is not documented... but if it is it's certainly well hidden
-away.
+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><b>Proposed resolution:</b></p>
 <p>
+Change 20.6.12.2.9 [util.smartptr.shared.spec]:
 </p>
 
-
-<p><i>[
-Kona (2007): This issue affects all the containers. We'd love to see a
-paper dealing with the broad issue. We think that the complexity of the
-<tt>size()</tt> member of every container -- except possibly <tt>list</tt> -- should be
-O(1). Alan has volunteered to provide wording.
-]</i></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="635"></a>635. domain of <tt>allocator::address</tt></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> Howard Hinnant <b>Date:</b> 2007-02-08</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="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>
-The table of allocator requirements in 20.1.2 [allocator.requirements] describes
-<tt>allocator::address</tt> as:
+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>
-<blockquote><pre>a.address(r)
-a.address(s)
-</pre></blockquote>
 <p>
-where <tt>r</tt> and <tt>s</tt> are described as:
+(Peter Dimov agreed it should be clearer, maybe a non-normative note to
+explain?)
 </p>
-<blockquote><p>
-a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>. 
-</p></blockquote>
 
-<p>
-and <tt>p</tt> is 
-</p>
+<p><i>[
+Bellevue:
+]</i></p>
 
-<blockquote><p>
-a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>, 
-where <tt>a1 == a</tt>
-</p></blockquote>
 
+<blockquote>
 <p>
-This all implies that to get the address of some value of type <tt>T</tt> that
-value must have been allocated by this allocator or a copy of it.
+Agree the issue is real.
 </p>
-
 <p>
-However sometimes container code needs to compare the address of an external value of
-type <tt>T</tt> with an internal value.  For example <tt>list::remove(const T&amp; t)</tt>
-may want to compare the address of the external value <tt>t</tt> with that of a value
-stored within the list.  Similarly <tt>vector</tt> or <tt>deque insert</tt> may
-want to make similar comparisons (to check for self-referencing calls).
+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>
-Mandating that <tt>allocator::address</tt> can only be called for values which the
-allocator allocated seems overly restrictive.
+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 20.1.2 [allocator.requirements]:
+Change 18.7.5 [propagation]/7:
 </p>
 
 <blockquote>
-<p>
-<tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
-</p>
-<p>
-<tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the 
-expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
-</p>
+-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>
 
-<p><i>[
-post Oxford:  This would be rendered NAD Editorial by acceptance of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
-]</i></p>
-
-
-<p><i>[
-Kona (2007):  This issue is section 8 of N2387.  There was some discussion of it but
-no resolution to this issue was recorded.  Moved to Open.
-]</i></p>
-
-
-
 
 
 
 
 <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#Review">Review</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#Review">Review</a> status.</p>
+<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>
-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.
+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>
-Something like:
+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>
-Any time the last element is erased, iterators to end are invalidated.
-</p></blockquote>
-
+</blockquote>
 <p>
-This would handle situations like:
+I think we should allow similar freedom here (or add a blanket
+compatible-exception freedom paragraph in 17)
 </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><b>Proposed resolution:</b></p>
 <p>
-Change 23.2.2.3 [deque.modifiers], p4:
+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>
 
-<blockquote>
-<pre>iterator erase(const_iterator position); 
-iterator erase(const_iterator first, const_iterator last);
-</pre>
+<p><i>[
+Bellevue:
+]</i></p>
+
 
 <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>.
+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>
 </blockquote>
 
 
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following exemption clause to 17.4.4.8 [res.on.exception.handling]:
+</p>
 
-<p><i>[
-Kona (2007): Proposed wording added and moved to Review.
-]</i></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="645"></a>645. Missing members in match_results</h3>
-<p><b>Section:</b> 28.10 [re.results] <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-02-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.results">active issues</a> in [re.results].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</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="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>
+ <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>
 <p>
-According to the description given in 28.10 [re.results]/2 the class template
-match_results "shall satisfy the requirements of a Sequence, [..],
-except that only operations defined for const-qualified Sequences
-are supported".
-Comparing the provided operations from 28.10 [re.results]/3 with the
-sequence/container tables 80 and 81 one recognizes the following
-missing operations:
+We have 3 separate type traits to identify classes supporting no-throw
+operations, which are very useful when trying to provide exception safety
+guarantees.  However, I'm not entirely clear on what the current wording
+requires of a conforming implementation.  To quote from
+<tt>has_nothrow_default_constructor</tt>:
+</p>
+<blockquote><p>
+or <tt>T</tt> is a class type with a default constructor that is known not to throw
+any exceptions
+</p></blockquote>
+<p>
+What level of magic do we expect to deduce if this is known?
 </p>
-
 <p>
-1) The members
+E.g.
 </p>
 
-<blockquote><pre>const_iterator rbegin() const;
-const_iterator rend() const;
+<blockquote><pre>struct test{
+ int x;
+ test() : x() {}
+};
 </pre></blockquote>
-
 <p>
-should exists because 23.1/10 demands these for containers
-(all sequences are containers) which support bidirectional
-iterators. Aren't these supported by match_result? This is not
-explicitely expressed, but it's somewhat implied by two arguments:
+Should I expect a conforming compiler to 
+ <tt>assert( has_nothrow_constructor&lt;test&gt;::value )</tt>
 </p>
 <p>
-(a) Several typedefs delegate to
-<tt>iterator_traits&lt;BidirectionalIterator&gt;</tt>.
+Is this a QoI issue?
 </p>
 <p>
-(b) The existence of <tt>const_reference operator[](size_type n) const</tt>
-implies even random-access iteration.
-I also suggest, that <tt>match_result</tt> should explicitly mention,
-which minimum iterator category is supported and if this does
-not include random-access the existence of <tt>operator[]</tt> is
-somewhat questionable.
+Should I expect to 'know' only if-and-only-if there is an inline definition
+available?
 </p>
 <p>
-2) The new "convenience" members
+Should I never expect that to be true, and insist that the user supplies an
+empty throw spec if they want to assert the no-throw guarantee?
 </p>
-<blockquote><pre>const_iterator cbegin() const;
-const_iterator cend() const;
-const_iterator crbegin() const;
-const_iterator crend() const;
-</pre></blockquote>
 <p>
-should be added according to tables 80/81.
+It would be helpful to maybe have a footnote explaining what is required,
+but right now I don't know what to suggest putting in the footnote.
 </p>
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.10 [re.results]
-para 3:
+(agreement since is that trivial ops and explicit no-throws are required.
+Open if QoI should be allowed to detect further)
 </p>
 
-<blockquote><pre>const_iterator cbegin() const; 
-const_iterator cend() const;
-</pre></blockquote>
+<p><i>[
+Bellevue:
+]</i></p>
 
-<p>
-In section 28.10.3 [re.results.acc] change:
-</p>
 
 <blockquote>
-<pre>const_iterator begin() const;
-<ins>const_iterator cbegin() const;</ins>
-</pre>
-<blockquote>
-<p>
--7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
-</p>
+This looks like a QoI issue.
+In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI.
+Move to OPEN. Need to talk to Core about this.
 </blockquote>
 
-<pre>const_iterator end() const;
-<ins>const_iterator cend() const;</ins>
-</pre>
-<blockquote>
+
+<p><b>Proposed resolution:</b></p>
 <p>
--8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
 </p>
-</blockquote>
-</blockquote>
-
-
-
-<p><i>[
-Kona (2007): Voted to adopt proposed wording in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>
-except removing the entry in the table container requirements.  Moved to Review.
-]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="653"></a>653. Library reserved names</h3>
-<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-03-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<h3><a name="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>
-<blockquote>
-<p>
-1.2 [intro.refs] Normative references
-</p>
-
 <p>
-The following standards contain provisions which, through reference in
-this text, constitute provisions of this Interna- tional Standard. At
-the time of publication, the editions indicated were valid. All
-standards are subject to revision, and parties to agreements based on
-this International Standard are encouraged to investigate the
-possibility of applying the most recent editions of the standards
-indicated below. Members of IEC and ISO maintain registers of currently
-valid International Standards.
+For instance:
 </p>
-
-<ul>
-<li>Ecma International, ECMAScript Language Specification, Standard
-Ecma-262, third edition, 1999.</li>
-<li>ISO/IEC 2382 (all parts), Information technology - Vocabulary</li>
-<li>ISO/IEC 9899:1990, Programming languages - C</li>
-<li>ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C
-Integrity</li>
-<li>ISO/IEC 9899:1999, Programming languages - C</li>
-<li>ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C</li>
-<li>ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C</li>
-<li>ISO/IEC 9945:2003, Information Technology-Portable Operating System
-Interface (POSIX)</li>
-<li>ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet
-Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual
-Plane</li>
-</ul>
+<blockquote>
+<pre>struct awkward {
+ awkward( const awkward &amp; ) throw() {}
+ awkward( awkward &amp; ) { throw "oops"; } };
+</pre>
 </blockquote>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-I'm not sure how many of those reserve naming patterns that might affect
-us, but I am equally sure I don't own a copy of any of these to check!
-</p>
-<p>
-The point is to list the reserved naming patterns, rather than the
-individual names themselves - although we may want to list C keywords
-that are valid identifiers in C++ but likely to cause trouble in shared
-headers (e.g. restrict)
+Change 20.4.4.3 [meta.unary.prop]:
 </p>
 
-<p><i>[
-Kona (2007): Recommend NAD.  No one has identified a specific defect, just the possibility of one.
-]</i></p>
-
-
-<p><i>[
-Post-Kona: Alisdair request Open. A good example of the problem was a
-discussion of the system error proposal, where it was pointed out an all-caps
-identifier starting with a capital E conflicted with reserved macro names for
-both Posix and C.  I had absolutely no idea of this rule, and suspect I was
-not the only one in the room.<br>
-<br>
-Resolution will require someone with access to all the listed documents to
-research their respective name reservation rules, or people with access to
-specific documents add their rules to this issue until the list is complete.
-]</i></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>
 
-<p><b>Proposed resolution:</b></p>
 
 
 
 
 
 <hr>
-<h3><a name="659"></a>659. istreambuf_iterator should have an operator-&gt;()</h3>
-<p><b>Section:</b> 24.5.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-03-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
+<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>
+ <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>
 <p>
-Greg Herlihy has clearly demonstrated that a user defined input
-iterator should have an operator-&gt;(), even if its
-value type is a built-in type (comp.std.c++, "Re: Should any iterator
-have an operator-&gt;() in C++0x?", March 2007). &nbsp;And as Howard
-Hinnant remarked in the same thread that the input iterator
-<tt>istreambuf_iterator</tt> doesn't have one, this must be a
-defect!
+With the pending arrival of explicit conversion functions though, I'm
+wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
 </p>
-<p>
-Based on Greg's example, the following code demonstrates the issue:
-</p><pre>&nbsp;#include &lt;iostream&gt; 
-&nbsp;#include &lt;fstream&gt;
-&nbsp;#include &lt;streambuf&gt; 
 
-&nbsp;typedef char C;
-&nbsp;int main ()
-&nbsp;{
-&nbsp;&nbsp;&nbsp;std::ifstream s("filename", std::ios::in);
-&nbsp;&nbsp;&nbsp;std::istreambuf_iterator&lt;char&gt; i(s);
+<p><i>[
+Bellevue:
+]</i></p>
 
-&nbsp;&nbsp;&nbsp;(*i).~C(); &nbsp;// This is well-formed...
-&nbsp;&nbsp;&nbsp;i-&gt;~C(); &nbsp;// ... so this should be supported!
-&nbsp;}
-</pre>
 
-<p>
-Of course, operator-&gt; is also needed when the value_type of
-istreambuf_iterator is a class.
-</p>
-<p>
-The operator-&gt; could be implemented in various ways. &nbsp;For instance,
-by storing the current value inside the iterator, and returning its
-address. &nbsp;Or by returning a proxy, like operator_arrow_proxy, from
-<a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
-</p>
-<p>
-I hope that the resolution of this issue will contribute to getting a
-clear and consistent definition of iterator concepts.
-</p>
+<blockquote>
+Alisdair is considering preparing a paper listing a number of missing
+type traits, and feels that it might be useful to handle them all
+together rather than piecemeal. This would affect issue 719 and 750.
+These two issues should move to OPEN pending AM paper on type traits.
+</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add to the synopsis in 24.5.3 [istreambuf.iterator]:
 </p>
 
-<blockquote><pre>charT operator*() const;
-<ins>pointer operator-&gt;() const;</ins>
-istreambuf_iterator&lt;charT,traits&gt;&amp; operator++();
-</pre></blockquote>
 
-<p>
-Change 24.5.3 [istreambuf.iterator], p1:
-</p>
 
-<blockquote><p>
-The class template <tt>istreambuf_iterator</tt> reads successive
-characters from the <tt>streambuf</tt> for which it was constructed.
-<tt>operator*</tt> provides access to the current input character, if
-any. <ins><tt>operator-&gt;</tt> may return a proxy.</ins> Each time
-<tt>operator++</tt> is evaluated, the iterator advances to the next
-input character. If the end of stream is reached
-(<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
-iterator becomes equal to the end of stream iterator value. The default
-constructor <tt>istreambuf_iterator()</tt> and the constructor
-<tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
-object suitable for use as an end-of-range.
-</p></blockquote>
 
 
+<hr>
+<h3><a name="751"></a>751. change pass-by-reference members of <tt>vector&lt;bool&gt;</tt> to pass-by-value?</h3>
+<p><b>Section:</b> 23.2.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+A number of vector&lt;bool&gt; members take const bool&amp; as arguments.
+Is there any chance we could change them to pass-by-value or would I 
+be wasting everyone's time if wrote up an issue?
+</p>
 
 <p><i>[
-Kona (2007): The proposed resolution is inconsistent because the return
-type of <tt>istreambuf_iterator::operator-&gt;()</tt> is specified to be <tt>pointer</tt>,
-but the proposed text also states that "<tt>operator-&gt;</tt> may return a proxy."
+post Bellevue:
 ]</i></p>
 
 
-<p><i>[
-Niels Dekker (mailed to Howard Hinnant):
-]</i></p>
-
 <blockquote>
 <p>
-The proposed resolution does
-not seem inconsistent to me. <tt>istreambuf_iterator::operator-&gt;()</tt> should
-have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
-may in fact be a proxy.
+As we understand it, the original requester (Martin Sebor) would like
+for implementations to be permitted to pass-by-value. Alisdair suggests
+that if this is to be resolved, it should be resolved more generally,
+e.g. in other containers as well.
 </p>
 <p>
-AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt>
-unspecified for some iterator categories") implies that for any iterator
-class <tt>Iter</tt>, the return type of <tt>operator-&gt;()</tt> is <tt>Iter::pointer</tt>, by
-definition. &nbsp;I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
+We note that this would break ABI. However, we also suspect that this
+might be covered under the "as-if" rule in section 1.9.
 </p>
 <p>
-Still I wouldn't mind if the text "<tt>operator-&gt;</tt> may return a proxy" would
-be removed from the resolution. I think it's up to the library
-implementation, how to implement <tt>istreambuf_iterator::operator-&gt;()</tt>. &nbsp;As
-longs as it behaves as expected: <tt>i-&gt;m</tt> should have the same effect as
-<tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i-&gt;~C()</tt>. &nbsp;The main issue
-is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</tt>!
+Many in the group feel that for vector&lt;bool&gt;, this is a "don't care",
+and that at this point in the process it's not worth the bandwidth.
+</p>
+<p>
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a> -- which was in ready status pre-Bellevue and is
+now in the working paper -- is related to this, though not a duplicate.
+</p>
+<p>
+Moving to Open with a task for Alisdair to craft a informative note to
+be put whereever appropriate in the WP. This note would clarify places
+where pass-by-const-ref can be transformed to pass-by-value under the
+as-if rule.
 </p>
 </blockquote>
 
 
 
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
 
 <hr>
-<h3><a name="661"></a>661. New 27.6.1.2.2 changes make special extractions useless</h3>
-<p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-04-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="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>
+ <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>Discussion:</b></p>
 <p>
-To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
-the explicit description of the extraction of the types short and int in
-terms of as-if code fragments.
+Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
+on the allocators are expected to be amortized constant time."?
+</p>
+<p>
+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
+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
+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
+the constants, not the asymptotic complexity.
 </p>
 
-<ol>
-<li>
-The corresponding as-if extractions in paragraph 2 and 3 will never
-result in a change of the operator&gt;&gt; argument val, because the
-contents of the local variable lval is in no case written into val.
-Furtheron both fragments need a currently missing parentheses in the
-beginning of the if-statement to be valid C++.
-</li>
-<li>I would like to ask whether the omission of a similar explicit
-extraction of unsigned short and unsigned int in terms of long -
-compared to their corresponding new insertions, as described in
-27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or
-an
-oversight.
-</li>
-</ol>
-
 
 <p><b>Proposed resolution:</b></p>
-<ol>
-<li>
 <p>
-In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
+Change 20.1.2 [allocator.requirements]/2:
 </p>
-<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
-iostate err = 0;
-long lval;
-use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
-if (err == 0) <ins>{</ins>
-  <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval)<del>)</del>
-      err = ios_base::failbit;
-  <ins>else
-    val = static_cast&lt;short&gt;(lval);
-}</ins>
-setstate(err);
-</pre></blockquote>
 
+<blockquote>
 <p>
-Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
+-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
+requirements on allocator types.
 </p>
-
-<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
-iostate err = 0;
-long lval;
-use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
-if (err == 0) <ins>{</ins>
-  <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval)<del>)</del>
-      err = ios_base::failbit;
-  <ins>else
-    val = static_cast&lt;int&gt;(lval);
-}</ins>
-setstate(err);
-</pre></blockquote>
-</li>
-<li>
----
-</li>
-</ol>
-
-
-<p><i>[
-Kona (2007): Note to the editor: the name lval in the call to <tt>use_facet</tt>
-is incorrectly italicized in the code fragments corresponding to
-<tt>operator&gt;&gt;(short &amp;)</tt> and <tt>operator &gt;&gt;(int &amp;)</tt>. Also, val -- which appears
-twice on the line with the <tt>static_cast</tt> in the proposed resolution --
-should be italicized. Also, in response to part two of the issue: this
-is deliberate.
-]</i></p>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt&lt;char, char, mbstate_t&gt;</tt></h3>
-<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt.virtuals">active issues</a> in [locale.codecvt.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="753"></a>753. Move constructor in draft</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> Yechezkel Mett <b>Date:</b> 2007-10-14</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>
-22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>):
+The draft standard n2369 uses the term <i>move constructor</i> in a few
+places, but doesn't seem to define it.
 </p>
 
-<blockquote><p>
-<i>Effects:</i> Places characters starting at to that should be appended to
-terminate a sequence when the current <tt>stateT</tt> is given by
-<tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> -
-<i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt>
-pointer pointing one beyond the last element successfully stored.
-<em><tt>codecvt&lt;char, char, mbstate_t&gt;</tt> stores no characters.</em>
-</p></blockquote>
-
 <p>
-The following objection has been raised:
+<tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as
+follows:
 </p>
 
-<blockquote><p>
-Since the C++ Standard permits a nontrivial conversion for the required
-instantiations of <tt>codecvt</tt>, it is overly restrictive to say that
-<tt>do_unshift</tt> must store no characters and return <tt>noconv</tt>.
-</p></blockquote>
+<blockquote>
+<table border="1">
+<caption><tt>MoveConstructible</tt> requirements</caption>
+<tbody><tr>
+<th>expression</th> <th>post-condition</th>
+</tr>
+<tr>
+<td><tt>T t = rv</tt></td> <td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
+</tr>
+<tr>
+<td colspan="2">[<i>Note:</i> There is no requirement on the value of <tt>rv</tt> after the 
+construction. <i>-- end note</i>]</td>
+</tr>
+</tbody></table>
+</blockquote>
 
 <p>
-[Plum ref _222152Y50]
+(where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
+So I assume the move constructor is the constructor that would be used
+in filling the above requirement.
 </p>
 
-<blockquote>
 <p>
-<i>Effects:</i> Places characters starting at <i>to</i> that should be
-appended to terminate a sequence when the current <tt>stateT</tt> is
-given by state.<sup>237)</sup> Stores no more than (<i>to_limit -to</i>)
-destination elements, and leaves the <i>to_next</i> pointer pointing one
-beyond the last element successfully stored. <del><tt>codecvt&lt;char, char,
-mbstate_t&gt;</tt> stores no characters.</del>
+For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in
+23.2.6.4 [vector.modifiers] we have
 </p>
-</blockquote>
-
-
-
 
+<blockquote>
+<i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall
+not throw any exceptions.
+</blockquote>
 
-<hr>
-<h3><a name="665"></a>665. <tt>do_unshift</tt> return value</h3>
-<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt.virtuals">active issues</a> in [locale.codecvt.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
+Firstly "If <tt>value_type</tt> has a move constructor" is superfluous; every
+type which can be put into a <tt>vector</tt> has a move constructor (a copy
+constructor is also a move constructor). Secondly it means that for
+any <tt>value_type</tt> which has a throwing copy constructor and no other move
+constructor these functions cannot be used -- which I think will come
+as a shock to people who have been using such types in <tt>vector</tt> until
+now!
 </p>
 
-<blockquote><p>
-<tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.
-</p></blockquote>
-
 <p>
-The following objection has been raised:
+I can see two ways to correct this. The simpler, which is presumably
+what was intended, is to say "If <tt>value_type</tt> has a move constructor and
+no copy constructor, the move constructor shall not throw any
+exceptions" or "If <tt>value_type</tt> has a move constructor which changes the
+value of its parameter,".
 </p>
 
-<blockquote><p>
-Despite what the C++ Standard&nbsp;
-says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since&nbsp;
-they can be nontrivial. At least one implementation does whatever the&nbsp;
-C functions do.
-</p></blockquote>
-
 <p>
-[Plum ref _222152Y62]
+The other alternative is add to <tt>MoveConstructible</tt> the requirement that
+the expression does not throw. This would mean that not every type
+that satisfies the <tt>CopyConstructible</tt> requirements also satisfies the
+<tt>MoveConstructible</tt> requirements. It would mean changing requirements in
+various places in the draft to allow either <tt>MoveConstructible</tt> or
+<tt>CopyConstructible</tt>, but I think the result would be clearer and
+possibly more concise too.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
+Add new defintions to 17.1 [definitions]:
 </p>
 
 <blockquote>
-<p><i>Returns:</i> An enumeration value, as summarized in Table 76:</p>
-<p>...</p>
 <p>
-<del><tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.</del>
+<b>move constructor</b>
+</p>
+<p>
+a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a
+side effect during the construction.
+</p>
+<p>
+<b>move assignment operator</b>
+</p>
+<p>
+an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a
+side effect during the assignment.
+</p>
+<p>
+<b>move assignment</b>
+</p>
+<p>
+use of the move assignment operator.
+</p>
+</blockquote>
+
+<p><i>[
+Howard adds post-Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect.  <tt>reserve</tt> et. al. will use a move constructor
+if one is available, else it will use a copy constructor.  A type may have both.  If the move constructor is
+used, it must not throw.  If the copy constructor is used, it can throw.  The sentence in the proposed wording
+is correct without the recommended insertion.  The Bellevue LWG recommended moving this issue to Ready.  I am
+unfortunately pulling it back to Open.  But I'm drafting wording to atone for this egregious action. :-)
 </p>
 </blockquote>
 
@@ -8880,48 +12500,84 @@ Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
 
 
 <hr>
-<h3><a name="666"></a>666. <tt>moneypunct::do_curr_symbol()</tt></h3>
-<p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <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> 2007-04-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p>
+<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>
 <p><b>Discussion:</b></p>
 <p>
-22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
+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>
-<sup>257)</sup> For international&nbsp;
-specializations (second template parameter <tt>true</tt>) this is always four&nbsp;
-characters long, usually three letters and a space.
+or:
 </p></blockquote>
+<pre>swap(v, vector&lt;int&gt;(v));  // shrink to fit
+</pre>
+</blockquote>
 
 <p>
-The following objection has been raised:
+A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via:
 </p>
 
-<blockquote><p>
-The international currency&nbsp;
-symbol is whatever the underlying locale says it is, not necessarily&nbsp;
-four characters long.
-</p></blockquote>
+<blockquote><pre>string s;
+...
+s.reserve(0);
+</pre></blockquote>
 
 <p>
-[Plum ref _222632Y41]
+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>
-Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
+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>
+<blockquote><pre>    
+void shrink_to_fit();
+</pre></blockquote>
+
 <p>
-<sup>253)</sup> For international specializations (second template
-parameter <tt>true</tt>) this is <del>always</del> <ins>typically</ins>
-four characters long, usually three letters and a space.
+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>
 
 
@@ -8929,830 +12585,1080 @@ four characters long, usually three letters and a space.
 
 
 <hr>
-<h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3>
-<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
+<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>
-22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
+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><p>
-The result is returned as an integral value&nbsp;
-stored in <tt>units</tt> or as a sequence of digits possibly preceded by a&nbsp;
-minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range&nbsp;
-from '0' through '9', inclusive) stored in <tt>digits</tt>.
-</p></blockquote>
+<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>
-The following
-objection has been raised:
+Change 23.2.5.1.1 [queue.defn]:
 </p>
 
-<blockquote><p>
-Some implementations interpret this to mean that a facet derived from
-<tt>ctype&lt;wchar_t&gt;</tt> can provide its own member <tt>do_widen(char)</tt>
-which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
-<tt>'@'</tt> symbol will appear in the resulting sequence of digits.&nbsp; Other
-implementations have assumed that one or more places in the standard permit the
-implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign.&nbsp; Are
-both interpretations permissible, or only&nbsp; one?
-</p></blockquote>
+<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>
-[Plum ref _222612Y14]
+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>
-Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
-parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
+Change 23.2.5.2.2 [priqueue.members]:
 </p>
 
-<p><i>[
-Kona (2007): Bill and Dietmar to provide proposed wording.
-]</i></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><b>Proposed resolution:</b></p>
 <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="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
-<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<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>
-22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
+Consider the following program:
 </p>
 
-<blockquote><p>
-If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
-optional, and if no sign is detected, the result is given the sign&nbsp;
-that corresponds to the source of the empty string.
-</p></blockquote>
+<blockquote><pre>int main() {
+   shared_ptr&lt;int&gt; p(nullptr); 
+   return 0;
+}
+</pre></blockquote>
 
 <p>
-The following
-objection has been raised:
+This program will fail to compile because <tt>shared_ptr</tt> uses the following 
+template constructor to construct itself from pointers:
 </p>
 
-<blockquote><p>
-A <tt>negative_sign</tt> of "" means "there is no&nbsp;
-way to write a negative sign" not "any null sequence is a negative&nbsp;
-sign, so it's always there when you look for it".
-</p></blockquote>
+<blockquote><pre>template &lt;class Y&gt; shared_ptr(Y *);
+</pre></blockquote>
 
 <p>
-[Plum ref _222612Y32]
+According
+to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a>,
+the conversion from <tt>nullptr_t</tt> to <tt>Y *</tt> is not
+deducible, so the above constructor will not be found.  There are similar problems with the
+constructors that take a pointer and a <tt>deleter</tt> or a
+pointer, a <tt>deleter</tt> and an allocator, as well as the
+corresponding forms of <tt>reset()</tt>. Note that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a>
+will solve this problem for constructing from just <tt>nullptr</tt>, but not for constructors that use
+<tt>deleters</tt> or allocators or for <tt>reset()</tt>.
+</p>
+
+<p>
+In the case of the functions that take deleters, there is the additional
+question of what argument should be passed to the deleter when it is
+eventually called.  There are two reasonable possibilities: <tt>nullptr</tt> or
+<tt>static_cast&lt;T *&gt;(0)</tt>, where <tt>T</tt> is the template argument of the
+<tt>shared_ptr</tt>.  It is not immediately clear which of these is better.  If
+<tt>D::operator()</tt> is a template function similar to <tt>shared_ptr</tt>'s
+constructor, then <tt>d(static_cast&lt;T*&gt;(0))</tt> will compile and <tt>d(nullptr)</tt>
+will not.  On the other hand, if <tt>D::operator()()</tt> takes a parameter that
+is a pointer to some type other that <tt>T</tt> (for instance <tt>U*</tt> where <tt>U</tt> derives
+from <tt>T</tt>) then <tt>d(nullptr)</tt> will compile and <tt>d(static_cast&lt;T *&gt;(0))</tt> may not.
 </p>
 
 <p><i>[
-Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
+Bellevue:
 ]</i></p>
 
 
-
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
+The general idea is right, we need to be able to pass a nullptr to a
+shared_ptr, but there are a few borderline editorial issues here. (For
+example, the single-argument nullptr_t constructor in the class synopsis
+isn't marked explicit, but it is marked explicit in the proposed wording
+for 20.6.6.2.1. There is a missing empty parenthesis in the form that
+takes a nullptr_t, a deleter, and an allocator.)
 </p>
-
-
-
-
-
-<hr>
-<h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
-<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
+More seriously: this issue says that a shared_ptr constructed from a
+nullptr is empty. Since "empty" is undefined, it's hard to know whether
+that's right. This issue is pending on handling that term better.
+</p>
+<p>
+Peter suggests definition of empty should be "does not own anything"
+</p>
+<p>
+Is there an editorial issue that post-conditions should refer to get() =
+nullptr, rather than get() = 0?
+</p>
+<p>
+No strong feeling towards accept or NAD, but prefer to make a decision than leave it open.
 </p>
-
-<blockquote><p>
-If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>,&nbsp;
-or if both strings are empty, the result is given a positive sign.
-</p></blockquote>
-
 <p>
-One interpretation is that an input sequence must match either the
-positive pattern or the negative pattern, and then in either event it
-is interpreted as positive.&nbsp; The following objections has been raised:
+Seems there are no technical merits between NAD and Ready, comes down to
+"Do we intentially want to allow/disallow null pointers with these
+functions". Staw Poll - support null pointers 5 - No null pointers 0
 </p>
-
-<blockquote><p>
-The input can successfully match only a positive sign, so the negative
-pattern is an unsuccessful match.
-</p></blockquote>
-
 <p>
-[Plum ref _222612Y34, 222612Y51b]
+Move to Ready, modulo editorial comments
 </p>
+</blockquote>
 
 <p><i>[
-Bill to provide proposed wording and interpretation of existing wording.
+post Bellevue Peter adds:
 ]</i></p>
 
 
-
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
+The following wording changes are less intrusive:
 </p>
 
+<p>
+In 20.6.12.2.1 [util.smartptr.shared.const], add:
+</p>
 
+<blockquote><pre>shared_ptr(nullptr_t);
+</pre></blockquote>
 
+<p>
+after:
+</p>
 
+<blockquote><pre>shared_ptr();
+</pre></blockquote>
 
-<hr>
-<h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
-<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>Discussion:</b></p>
 <p>
-22.2.6.3 [locale.moneypunct], para 2 says:
+(Absence of explicit intentional.)
 </p>
 
-<blockquote><p>
-The value <tt>space</tt> indicates that at least one space is required at&nbsp;
-that position.
-</p></blockquote>
-
 <p>
-The following objection has been raised:
+<tt>px.reset( nullptr )</tt> seems a somewhat contrived way to write <tt>px.reset()</tt>, so
+I'm not convinced of its utility.
+</p>
+<p>
+It's similarly not clear to me whether the deleter constructors need to be
+extended to take <tt>nullptr</tt>, but if they need to:
+</p>
+<p>
+Add
 </p>
 
-<blockquote><p>
-Whitespace&nbsp;is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
-</p></blockquote>
+<blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
+template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
+</pre></blockquote>
 
 <p>
-[Plum ref _22263Y22]
+after
 </p>
 
-<p><i>[
-Kona (2007): Bill to provide proposed wording. We agree that C++03 is
-ambiguous, and that we want C++0X to say "space" means 0 or more
-whitespace characters on input.
-]</i></p>
+<blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
+template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
+</pre></blockquote>
 
+<p>
+Note that this changes the semantics of the new constructors such that they
+consistently call <tt>d(p)</tt> instead of <tt>d((T*)0)</tt> when <tt>p</tt> is <tt>nullptr</tt>.
+</p>
+<p>
+The ability to be able to pass <tt>0/NULL</tt> to a function that takes a <tt>shared_ptr</tt>
+has repeatedly been requested by users, but the other additions that the
+proposed resolution makes are not supported by real world demand or
+motivating examples.
+</p>
+<p>
+It might be useful to split the obvious and non-controversial <tt>nullptr_t</tt>
+constructor into a separate issue. Waiting for "empty" to be clarified is
+unnecessary; this is effectively an alias for the default constructor.
+</p>
+</blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
+Add the following constructors to 20.6.12.2 [util.smartptr.shared]:
 </p>
 
+<blockquote><pre>shared_ptr(nullptr_t);
+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]:
+</p>
 
-<hr>
-<h3><a name="671"></a>671. precision of hexfloat</h3>
-<p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> John Salmon <b>Date:</b> 2007-04-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
+<pre> explicit shared_ptr(nullptr_t);
+</pre>
+<blockquote>
 <p>
-I am trying to understand how TR1 supports hex float (%a) output.
+<i>Effects:</i> Constructs an empty shared_ptr object.
 </p>
 <p>
-As far as I can tell, it does so via the following:
+<i>Postconditions:</i> <tt>use_count() == 0 &amp;&amp; get() == 0</tt>.
 </p>
 <p>
-8.15 Additions to header &lt;locale&gt; [tr.c99.locale]
+<i>Throws:</i> nothing.
 </p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>template &lt;class D&gt; shared_ptr(nullptr_t, D d);
+template &lt;class D, class A&gt; shared_ptr&lt;nullptr_t, D d, A a);
+</pre>
+<blockquote>
 <p>
-In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
-the line:
-floatfield == ios_base::scientific %E
+<i>Requires:</i> <tt>D</tt> shall be <tt>CopyConstructible</tt>. The copy constructor and
+destructor of <tt>D</tt> shall not throw exceptions. The expression
+<tt>d(static_cast&lt;T *&gt;(0))</tt> shall be well-formed, shall have well defined behavior,
+and shall not throw exceptions. <tt>A</tt> shall be an allocator (20.1.2 [allocator.requirements]).
+The copy constructor and destructor of <tt>A</tt> shall not throw
+exceptions.
 </p>
 <p>
-add the two lines:
+<i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that owns a null pointer of type <tt>T *</tt>
+and  deleter <tt>d</tt>.  The
+second constructor shall use a copy of <tt>a</tt> to allocate memory for
+internal use.
 </p>
-<blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase %a
-floatfield == ios_base::fixed | ios_base::scientific %A 2
-</pre></blockquote>
 <p>
-[Note: The additional requirements on print and scan functions, later
-in this clause, ensure that the print functions generate hexadecimal
-floating-point fields with a %a or %A conversion specifier, and that
-the scan functions match hexadecimal floating-point fields with a %g
-conversion specifier. &nbsp;end note]
+<i>Postconditions:</i> <tt>use_count() == 1</tt> and <tt>get() == 0</tt>.
 </p>
 <p>
-Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
+<i>Throws:</i> <tt>bad_alloc</tt>, or an implementation-defined exception when a
+resource other than memory could not be obtained.
 </p>
 <p>
-For conversion from a floating-point type, if (flags &amp; fixed) != 0 or
-if str.precision() &gt; 0, then str.precision() is specified in the
-conversion specification.
+<i>Exception safety:</i> If an exception is thrown, <tt>d(static_cast&lt;Y *&gt;(nullptr))</tt> is called.
 </p>
+</blockquote>
+</blockquote>
+
 <p>
-This would seem to imply that when floatfield == fixed|scientific, the
-precision of the conversion specifier is to be taken from
-str.precision(). &nbsp;Is this really what's intended? &nbsp;I sincerely hope
-that I'm either missing something or this is an oversight. &nbsp;Please
-tell me that the committee did not intend to mandate that hex floats
-(and doubles) should by default be printed as if by %.6a.
+Add the following method definitions to 20.6.12.2.4 [util.smartptr.shared.mod]:
 </p>
 
-<p><i>[
-Howard: I think the fundamental issue we overlooked was that with %f,
-%e, %g, the default precision was always 6. &nbsp;With %a the default
-precision is not 6, it is infinity. &nbsp;So for the first time, we need to
-distinguish between the default value of precision, and the precision
-value 6.
-]</i></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>
 
-<p><i>[
-Kona (2007): Robert volunteers to propose wording.
-]</i></p>
 
 
 
 
 
 <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#Review">Review</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#Review">Review</a> status.</p>
+<h3><a name="760"></a>760. The emplace issue</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> Paolo Carlini <b>Date:</b> 2007-11-11</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The current <tt>Swappable</tt> is:
+In an emplace member function the function parameter pack may be bound
+to a priori unlimited number of objects: some or all of them can be
+elements of the container itself. Apparently, in order to conform to the
+blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for
+that possibility. A possible solution can involve extending the
+exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the
+<tt>push_back</tt> and <tt>push_front</tt> member functions are luckily not affected by
+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>
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></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:
+The proposed addition (13) is partially redundant with the existing
+paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why
+does it not cover subelements and pointers?
+</p>
+<p>
+Resolution: Alan Talbot to rework language, then set state to Review.
 </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>
 
+
+
+<p><b>Proposed resolution:</b></p>
 <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.
+Add after 23.1 [container.requirements]/12:
 </p>
 
+<blockquote>
 <p>
-Additionally we may want to support proxy references such that the following code is acceptable:
+-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No 
+diagnostic required.
+</p>
+<p>
+<ins>
+-13- Objects bound to the function parameter pack of the <tt>emplace</tt> member function shall not be elements or
+sub-objects of elements of the container. No diagnostic required.
+</ins>
 </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;
-   ...
-};
+</blockquote>
 
-struct A
-{
-   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
-   void swap(A&amp;);
-   ...
-};
 
-void swap(A&amp;, A&amp;);
-void swap(proxy&lt;A&gt;, A&amp;);
-void swap(A&amp;, proxy&lt;A&gt;);
-void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
 
-}  // Mine
 
-...
 
-Mine::proxied_iterator&lt;Mine::A&gt; i(...)
-Mine::A a;
-swap(*i1, a);
-</pre></blockquote>
 
+<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>
-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 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>
 
-<p><b>Proposed resolution:</b></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>
-Change 20.1.1 [utility.arg.requirements]:
+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>
--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>.
+<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>
-
-<table border="1">
-<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
-<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
-<tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td>
-<td><tt>t</tt> has the value originally
-held by <tt>u</tt>, and
-<tt>u</tt> has the value originally held
-by <tt>t</tt></td></tr>
-<tr><td colspan="3">
 <p>
-The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
+<i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element 
+is present.
 </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>
-
-
+</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).
+Bellevue:  Editorial note: the "(unique)" differs from map.
 ]</i></p>
 
 
 
 
 
+
+
 <hr>
-<h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
-<p><b>Section:</b> 20.6.5 [unique.ptr] <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-04</p>
+<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>
+ <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>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">reference implmenation</a>
-for all of these changes.
+In contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt>
+does currently not support incomplete types, because it
+gives no explicit grant - thus instantiating <tt>unique_ptr</tt> with
+an incomplete pointee type <tt>T</tt> automatically belongs to
+undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last
+bullet. This is an unnecessary restriction and prevents
+many well-established patterns - like the bridge pattern -
+for <tt>std::unique_ptr</tt>.
 </p>
 
-<ul>
+<p><i>[
+Bellevue:
+]</i></p>
 
-<li>
+
+<blockquote>
+Move to open. The LWG is comfortable with the intent of allowing
+incomplete types and making <tt>unique_ptr</tt> more like <tt>shared_ptr</tt>, but we are
+not comfortable with the wording. The specification for <tt>unique_ptr</tt>
+should be more like that of <tt>shared_ptr</tt>. We need to know, for individual
+member functions, which ones require their types to be complete. The
+<tt>shared_ptr</tt> specification is careful to say that for each function, and
+we need the same level of care here. We also aren't comfortable with the
+"part of the operational semantic" language; it's not used elsewhere in
+the standard, and it's not clear what it means. We need a volunteer to
+produce new wording.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
 <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 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>.
 </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.
+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:
+"<tt>T</tt> shall be a complete type, if used as template argument of
+<tt>unique_ptr&lt;T[], D&gt;</tt>
 </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 (reference 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>.
+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
+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
+with the here discussed
+ones, provided that <tt>D::pointer</tt>'s operations (including default
+construction, copy construction/assignment,
+and pointer conversion) are specified <em>not</em> to throw, otherwise this
+would have impact on the
+current specification of <tt>unique_ptr</tt>.
 </p>
-</li>
 
+<ol>
 <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.
+In 20.6.11 [unique.ptr]/2 add as the last sentence to the existing para:
 </p>
 
-<blockquote><pre>unique_ptr&lt;A, void(*)(void*)&gt; p(new A);  // error, no function given to delete the pointer!
-</pre></blockquote>
-
+<blockquote>
+The <tt>unique_ptr</tt> provides a semantics of strict ownership. A
+<tt>unique_ptr</tt> owns the object it holds a pointer to. A
+<tt>unique_ptr</tt> is not <tt>CopyConstructible</tt>, nor
+<tt>CopyAssignable</tt>, however it is <tt>MoveConstructible</tt> and
+<tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of
+<tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The
+uses of <tt>unique_ptr</tt> include providing exception safety for
+dynamically allcoated memory, passing ownership of dynamically allocated
+memory to a function, and returning dynamically allocated memory from a
+function. -- <i>end note</i> ]
+</blockquote>
 </li>
 
-</ul>
+<li>
+<p>
+20.6.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
+</p>
 
+<blockquote>
 <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.
+N.B.: We only need the requirement that <tt>D</tt> is <tt>DefaultConstructible</tt>.
+The current wording says just this.
 ]</i></p>
 
+</blockquote>
+</li>
 
-<p><i>[
-Post Kona: Howard adds example user code related to the first bullet:
-]</i></p>
-
+<li>
+<p>
+In 20.6.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
+</p>
 
 <blockquote>
-<pre>void legacy_code(void*, std::size_t);
+<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.
+<ins>
+<tt>D</tt> shall be default constructible, and that construction
+shall not throw an exception.
+</ins>
+</p>
+<p><i>[
+N.B.: There is no need that the expression <tt>D()(p)</tt> is well-formed at
+this point. I assume that the current wording is based on the
+corresponding <tt>shared_ptr</tt> wording. In case of <tt>shared_ptr</tt> this
+requirement is necessary, because the corresponding c'tor *can* fail
+and must invoke delete <tt>p/d(p)</tt> in this case. <tt>Unique_ptr</tt> is simpler in
+this regard. The *only* functions that must insist on well-formedness
+and well-definedness of the expression <tt>get_deleter()(get())</tt> are (1)
+the destructor and (2) <tt>reset</tt>. The reasoning for the wording change to
+explicitly require <tt>DefaultConstructible</tt> of <tt>D</tt> is to guarantee that
+invocation of
+<tt>D</tt>'s default c'tor is both well-formed and well-defined. Note also that
+we do *not* need the
+requirement that <tt>T</tt> must be complete, also in contrast to <tt>shared_ptr</tt>.
+<tt>Shared_ptr</tt> needs this, because it's c'tor is a template c'tor which
+potentially requires <tt>Convertible&lt;Y*, X*&gt;</tt>, which
+again requires Completeness of <tt>Y</tt>, if <tt>!SameType&lt;X, Y&gt;</tt>
+]</i></p>
 
-void foo(std::size_t N)
-{
-    std::unique_ptr&lt;void, void(*)(void*)&gt; ptr(std::malloc(N), std::free);
-    legacy_code(ptr.get(), N);
-}   // unique_ptr used for exception safety purposes
-</pre>
 </blockquote>
+</li>
 
+<li>
 <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:
+Merge 20.6.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
+of 12, but transferring the "requires" to 13:
 </p>
 
-<blockquote><pre>T&amp; operator*() const;
-T* operator-&gt;() const;
-</pre></blockquote>
-
+<blockquote>
+<p>
+<i>Requires:</i> If <tt>D</tt> is not an lvalue-reference type then[..]
+</p>
+<p><i>[
+N.B.: For the same reasons as for (3), there is no need that <tt>d(p)</tt> is
+well-formed/well-defined at this point. The current wording guarantees
+all what we need, namely that the initialization of both the <tt>T*</tt>
+pointer and the <tt>D</tt> deleter are well-formed and well-defined.
+]</i></p>
 
+</blockquote>
+</li>
 
-<p><b>Proposed resolution:</b></p>
+<li>
+20.6.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><i>[
-I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
-the proposed resolutions below.
+N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt>
+is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt> is
+true. If the committee wishes this explicit requirement can be added,
+e.g. "<tt>U</tt> shall be a complete type."
 ]</i></p>
 
+</li>
 
-<ul>
 <li>
-
 <p>
-Change 20.6.5.2 [unique.ptr.single]:
+20.6.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
 </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;
-   ...
-};
-</pre></blockquote>
-
+<blockquote>
 <p>
-Change 20.6.5.2.4 [unique.ptr.single.observers]:
+<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
+shall have well-defined behavior, and shall not throw exceptions.
 </p>
+<p><i>[
+N.B.: This requirement ensures that the whole responsibility on
+type-completeness of <tt>T</tt> is delegated to this expression.
+]</i></p>
 
-<blockquote><pre><del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
-</pre></blockquote>
-
+</blockquote>
 </li>
 
 <li>
 <p>
-Change 20.6.5.2 [unique.ptr.single]:
+20.6.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>
 
-<blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
-public:
-  <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
-   ...
-   explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
-   ...
-   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
-   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
-   ...
-   <del>T*</del> <ins>pointer</ins> operator-&gt;() const;
-   <del>T*</del> <ins>pointer</ins> get() const;
-   ...
-   <del>T*</del> <ins>pointer</ins> release();
-   void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-};
-</pre></blockquote>
+<p><i>[
+N.B. The current wording is sufficient, because we can delegate all
+further requirements on the requirements of the effects clause
+]</i></p>
 
-<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> must be <tt>CopyConstructible</tt>
-and <tt>CopyAssignable</tt>.
-</ins>
-</p>
+</li>
 
+<li>
 <p>
-Change 20.6.5.2.1 [unique.ptr.single.ctor]:
+20.6.11.2.3 [unique.ptr.single.asgn]/6: No changes necessary.
 </p>
+<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>
+is true, see (6)+(8).
+]</i></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>
+</li>
 
+<li>
 <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>
-must be well formed and not throw an exception. If <tt>D</tt> is a
-reference type, then <tt>E</tt> must 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>
-must be implicitly convertible to <del><tt>T*</tt></del>
-<ins>pointer</ins>.
+20.6.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
 </p>
+<p><i>[
+N.B.: Delegation to requirements of effects clause is sufficient.
+]</i></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>.
+</li>
+
+<li>
+20.6.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: No changes necessary.
+</li>
+
+<li>
+20.6.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:
 </p>
+<blockquote>
+<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
+shall have well-defined behavior, and shall not throw exceptions.
+</blockquote>
+</li>
+
+<li>
+20.6.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
+</li>
 
+<li>
 <p>
-Change 20.6.5.2.3 [unique.ptr.single.asgn]:
+20.6.11.3.1 [unique.ptr.runtime.ctor]: Add one additional paragraph just
+before the current one:
 </p>
 
 <blockquote>
 <p>
--8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
-<tt>D</tt> must not throw an exception. <del><tt>U*</tt></del>
-<ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> must be implicitly
-convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
+<i>Requires:</i> <tt>T</tt> shall be a complete type.
 </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>
 
-<p>
-Change 20.6.5.2.4 [unique.ptr.single.observers]:
-</p>
+<li>
+20.6.11.3.2 [unique.ptr.runtime.observers]/1: Change the clause to says:
+</li>
 
 <blockquote>
-<pre><del>T*</del> <ins>pointer</ins> operator-&gt;() const;</pre>
-...
-<pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
+<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>
-Change 20.6.5.2.5 [unique.ptr.single.modifiers]:
+20.6.11.3.3 [unique.ptr.runtime.modifiers]/1: Change the first sentence of the
+paragraph to say:
 </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>
+<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>
+
 </blockquote>
 
+</li>
+</ol>
+
+<p><i>[
+post Bellevue: Daniel provided revised wording.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="765"></a>765. more on iterator validity</h3>
+<p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-12-14</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+       <p>
+
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>
+defines the meaning of the term "invalid iterator" as one that may be
+singular.
+
+       </p>
+       <p>
+
+Consider the following code:
+
+       </p>
+       <pre>   std::deque&lt;int&gt; x, y;
+   std::deque&lt;int&gt;::iterator i = x.end(), j = y.end();
+   x.swap(y);
+       </pre>
+       <p>
+
+Given that <code>swap()</code> is required not to invalidate iterators
+and using the definition above, what should be the expected result of
+comparing <code>i</code> and <code>j</code> to <code>x.end()</code>
+and <code>y.end()</code>, respectively, after the <code>swap()</code>?
+
+       </p>
+       <p>
+
+I.e., is the expression below required to evaluate
+to <code>true</code>?
+
+       </p>
+       <pre>   i == y.end() &amp;&amp; j == x.end()
+       </pre>
+       <p>
+
+(There are at least two implementations where the expression
+returns <code>false</code>.)
+
+       </p>
+       <p>
+
+More generally, is the definition introduced in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a> meant to
+make any guarantees about whether iterators actually point to the same
+elements or be associated with the same containers after a
+non-invalidating operation as they did before?
+
+       </p>
+       <p>
+
+Here's a motivating example intended to demonstrate the importance of
+the question:
+
+       </p>
+       <pre>   Container x, y ({ 1, 2});   // pseudocode to initialize y with { 1, 2 }
+   Container::iterator i = y.begin() + 1;
+   Container::iterator j = y.end();
+   std::swap(x, y);
+   std::find(i, j, 3);
+       </pre>
+       <p>
+
+<code>swap()</code> guarantees that <code>i</code> and <code>j</code>
+continue to be valid. Unless the spec says that even though they are
+valid they may no longer denote a valid range the code above must be
+well-defined. Expert opinions on this differ as does the behavior of
+popular implementations for some standard <code>Containers</code>.
+
+       </p>
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Change 20.6.5.3 [unique.ptr.runtime]:
 </p>
 
-<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>
 
+
+
+
+<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>
+<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 20.6.5.3.1 [unique.ptr.runtime.ctor]:
+23.1 [container.requirements]p10 states:
 </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>
-
 <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>]
+Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
+additional requirements:
 </p>
+<ul>
+
+<li>[...]</li>
+
+<li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li>
+
+</ul>
 </blockquote>
 
 <p>
-Change 20.6.5.3.3 [unique.ptr.runtime.modifiers]:
+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>:
 </p>
 
 <blockquote>
-<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-</pre>
+No <tt>erase()</tt> function throws an exception unless that exception
+is thrown by the container's Hash or Pred object (if any).
+</blockquote>
 
 <p>
--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>]
+Summary:
 </p>
-</blockquote>
 
 <p>
-Change 20.6.5.4 [unique.ptr.compiletime]:
+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.
 </p>
 
-<blockquote><pre>template &lt;class T, class D,  size_t N&gt; class unique_ptr&lt;T[N], 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>
-
 <p>
-Change 20.6.5.4.3 [unique.ptr.compiletime.modifiers]:
+In contrast, associative containers have no exception safety guarantees
+section so no <tt>erase()</tt> function should throw, <em>including
+<tt>erase(k)</tt></em> that needs to use the predicate function to
+perform its work. This means that the predicate of an associative
+container is not allowed to throw.
 </p>
 
-<blockquote>
-<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-</pre>
-
 <p>
--1- <i>Requires:</i> Does not accept pointer types which are convertible
-to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (dignostic required). [<i>Note:</i> One implementation
-technique is to create a private templated overload. <i>--end note</i>]
+So:
 </p>
 
-</blockquote>
-
+<ol>
+<li>
+<tt>erase(k)</tt> for associative containers is not allowed to throw. On
+the other hand, <tt>erase(k)</tt> for unordered associative containers
+is allowed to throw.
+</li>
+<li>
+<tt>erase(q)</tt> for associative containers is not allowed to throw. On
+the other hand, <tt>erase(q)</tt> for unordered associative containers
+is allowed to throw if it uses the hash or predicate.
+</li>
+<li>
+To fulfill 1), predicates of associative containers are not allowed to throw.
+Predicates of unordered associative containers are allowed to throw.
 </li>
-
 <li>
+2) breaks a widely used programming pattern (flyweight pattern) for
+unordered containers, where objects are registered in a global map in
+their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is
+allowed to throw, the destructor of the object would need to rethrow the
+exception or swallow it, leaving the object registered.
+</li>
+</ol>
+
 
+<p><b>Proposed resolution:</b></p>
 <p>
-Change 20.6.5.2.1 [unique.ptr.single.ctor]:
+Create a new sub-section of 23.1.2 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
+safety guarantees".
 </p>
 
-<blockquote>
-<pre>unique_ptr();</pre>
 <blockquote>
 <p>
-<i>Requires:</i> <tt>D</tt> must be default constructible, and that
-construction must not throw an exception. <tt>D</tt> must not be a
-reference type <ins>or pointer type (diagnostic required)</ins>.
+1 For associative containers, no <tt>clear()</tt> function throws an exception.
+<tt>erase(k)</tt> does not throw an exception unless that exception is thrown by
+the container's Pred object (if any).
 </p>
-</blockquote>
-<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
-<blockquote>
+
 <p>
-<i>Requires:</i>  The expression <tt>D()(p)</tt> must be well formed.
-The default constructor of <tt>D</tt> must not throw an exception.
-<tt>D</tt> must not be a reference type <ins>or pointer type (diagnostic
-required)</ins>.
+2 For associative containers, if an exception is thrown by any operation
+from within an <tt>insert()</tt> function inserting a single element, the
+<tt>insert()</tt> function has no effect.
+</p>
+
+<p>
+3 For associative containers, no <tt>swap</tt> function throws an exception
+unless that exception is thrown by the copy constructor or copy
+assignment operator of the container's Pred object (if any).
 </p>
-</blockquote>
 </blockquote>
 
 <p>
-Change 20.6.5.2.1 [unique.ptr.single.ctor]:
+Change 23.1.3.1 [unord.req.except]p1:
 </p>
 
 <blockquote>
-<pre>unique_ptr();</pre>
-<blockquote>
+For unordered associative containers, no <tt>clear()</tt> function
+throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt>
+<del>function</del> <ins>does not</ins> throw<del>s</del> an exception
+unless that exception is thrown by the container's Hash or Pred object
+(if any).
+</blockquote>
+
 <p>
-<i>Requires:</i> <tt>D</tt> must be default constructible, and that
-construction must not throw an exception. <tt>D</tt> must not be a
-reference type <ins>or pointer type (diagnostic required)</ins>.
+Change 23.1 [container.requirements]p10 to add references to new sections:
 </p>
-</blockquote>
-<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
+
 <blockquote>
+Unless otherwise specified (see [deque.modifiers]<ins>,</ins>
+<del>and</del> [vector.modifiers]<ins>, [associative.req.except],
+[unord.req.except]</ins>) all container types defined in this clause meet
+the following additional requirements:
+</blockquote>
+
 <p>
-<i>Requires:</i>  The expression <tt>D()(p)</tt> must be well formed.
-The default constructor of <tt>D</tt> must not throw an exception.
-<tt>D</tt> must not be a reference type <ins>or pointer type (diagnostic
-required)</ins>.
+Change 23.1 [container.requirements]p10 referring to <tt>swap</tt>:
 </p>
-</blockquote>
-</blockquote>
 
+<blockquote>
+<ul>
+<li>
+no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown
+by the copy constructor or assignment operator of the container's
+Compare object (if any; see [associative.reqmts])</del>.
 </li>
-
 </ul>
+</blockquote>
 
 
 
@@ -9760,777 +13666,683 @@ required)</ins>.
 
 
 <hr>
-<h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3>
-<p><b>Section:</b> 20.6.6.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-05-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="767"></a>767. Forwarding and backward compatibility</h3>
+<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-28</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose
-any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate
-and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>.
+Playing with g++'s C++0X mode, I noticed that the following
+code, which used to compile:
 </p>
 
+<blockquote><pre>#include &lt;vector&gt;
 
-<p><b>Proposed resolution:</b></p>
+int main()
+{
+    std::vector&lt;char *&gt; v;
+    v.push_back(0);
+}
+</pre></blockquote>
 
 <p>
-Change 20.6.6.2 [util.smartptr.shared] as follows:
+now fails with the following error message:
 </p>
 
-<blockquote>
-<pre>template&lt;class Y&gt; explicit shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
-<ins>template&lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
-template&lt;class Y, class D&gt; explicit shared_ptr(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins>
-...
-template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
-<ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
-template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
+<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>
-Change 20.6.6.2.1 [util.smartptr.shared.const] as follows:
+As far as I know, g++ follows the current draft here.
 </p>
-
-<blockquote>
-<pre><ins>template&lt;class Y&gt; shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</ins></pre>
-</blockquote>
-
 <p>
-Add to 20.6.6.2.1 [util.smartptr.shared.const]:
+Does the committee really intend to break compatibility for such cases?
 </p>
 
-<blockquote>
-<pre><ins>template&lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);</ins></pre>
-<blockquote>
-
-<p><ins>
-<i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is
-          not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt>
-          otherwise.
-</ins></p>
-
-<p><ins>
-<i>Exception safety:</i> If an exception is thrown, the constructor has no effect.
-</ins></p>
-</blockquote>
-
-</blockquote>
+<p><i>[
+Sylvain adds: 
+]</i></p>
 
-<p>
-Change 20.6.6.2.3 [util.smartptr.shared.assign] as follows:
-</p>
 
 <blockquote>
-<pre>template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</pre>
-</blockquote>
-
 <p>
-Add to 20.6.6.2.3 [util.smartptr.shared.assign]:
+I just noticed that <tt>std::pair</tt> has the same issue.
+The following now fails with GCC's -std=c++0x mode:
 </p>
 
-<blockquote>
-<pre><ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
+<blockquote><pre>#include &lt;utility&gt;
 
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>.
-</ins></p>
-<p><ins>
--5- <i>Returns:</i> <tt>*this</tt>.
-</ins></p>
-</blockquote>
+int main()
+{
+   std::pair&lt;char *, char *&gt; p (0,0);
+}
+</pre></blockquote>
 
+<p>
+I have not made any general audit for such problems elsewhere.
+</p>
 </blockquote>
 
-
-
 <p><i>[
-Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>) to deal with the question of
-whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
+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>
 
-
-
-<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#Ready">Ready</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#Ready">Ready</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>
-
+
+<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.
+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>
-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>.
+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>
-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.
+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>
+</blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 23.1 [container.requirements]:
+Add the following rows to Table 90 "Optional sequence container operations", 23.1.1 [sequence.reqmts]:
 </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>
+<th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</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>
+<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>
-<td><del>constant</del> <ins>linear in <tt>a.size()</tt></ins></td>
 </tr>
-</tbody></table>
-</blockquote>
-
 
+<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="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#Ready">Ready</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#Ready">Ready</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.
+Change the synopsis in 23.2.2 [deque]:
 </p>
 
+<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
+<ins>void push_front(T&amp;&amp; x);</ins>
+<ins>void push_back(const T&amp; x);</ins>
+<ins>void push_back(T&amp;&amp; x);</ins>
+template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
+template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
+</pre></blockquote>
+
 <p>
-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".
+Change 23.2.2.3 [deque.modifiers]:
 </p>
 
-
-
-<p><b>Proposed resolution:</b></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>
-Add to 23.4 [unord]:
+Change the synopsis in 23.2.4 [list]:
 </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>
-
-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>
+<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><b><tt>unordered_map</tt></b></p>
-
 <p>
-Change 23.4.1 [unord.map]:
+Change 23.2.4.3 [list.modifiers]:
 </p>
 
-<blockquote><pre>class unordered_map
-{
-    ...
-    unordered_map(const unordered_map&amp;);
-    <ins>unordered_map(unordered_map&amp;&amp;);</ins>
-    ~unordered_map();
-    unordered_map&amp; operator=(const unordered_map&amp;);
-    <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
-    ...
-    // modifiers 
-    <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj); 
-    <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
-    iterator       insert(iterator hint, const value_type&amp; obj);
-    <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
-    const_iterator insert(const_iterator hint, const value_type&amp; obj);
-    <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
-    ...
-    void swap(unordered_map&amp;<ins>&amp;</ins>);
-    ...
-    mapped_type&amp; operator[](const key_type&amp; k);
-    <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
-    ...
-};
-
-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>
+<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>
-Add to 23.4.1.1 [unord.map.cnstr]:
+Change the synopsis in 23.2.6 [vector]:
 </p>
 
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
-  unordered_map(InputIterator f, InputIterator l, 
-                size_type n = <i>implementation-defined</i>, 
-                const hasher&amp; hf = hasher(), 
-                const key_equal&amp; eql = key_equal(), 
-                const allocator_type&amp; a = allocator_type());
-</pre>
-
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
-then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
-<tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
+<blockquote><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>
-Add to 23.4.1.2 [unord.map.elem]:
+Change 23.2.6.4 [vector.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>
+<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>
 
-<pre><ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins></pre>
 
-<blockquote>
-<p><ins>
-<i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
-element whose key is equivalent to <tt>k</tt> , inserts the value
-<tt>std::pair&lt;const key_type, mapped_type&gt;(std::move(k), mapped_type())</tt>.
-</ins></p>
 
-<p><ins>
-<i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
-</ins></p>
 
-<p><ins>
-<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
-(unique) element whose key is equivalent to <tt>k</tt>.
-</ins></p>
 
-</blockquote>
 
-</blockquote>
 
+<hr>
+<h3><a name="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>
-Add new section [unord.map.modifiers]:
+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:
 </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><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; 
 
-<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>
+  atomic() = default; 
+  constexpr explicit atomic(T); 
+  atomic(const atomic&amp;) = delete; 
+  atomic&amp; operator=(const atomic&amp;) = delete; 
 
-<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>
+  T* operator=(T*) volatile; 
+  T* operator++(int) volatile; 
+  T* operator--(int) volatile; 
+  T* operator++() volatile; 
+  T* operator--() volatile; 
+  T* operator+=(ptrdiff_t) volatile;
+  T* operator-=(ptrdiff_t) volatile; 
+};
+</pre></blockquote>
+
+<p>
+First of all, there is a typo in the non-default constructor which
+should take a <tt>T*</tt> rather than a <tt>T</tt>.
+</p>
+
+<p>
+As you can see, the specialization redefine and therefore hide a few
+methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>,
+<tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened
+to the other methods, in particular these ones:
+</p>
 
-<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><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>
 
-</blockquote>
+<p>
+By reading paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>,
+I see that the
+definition of the specialization <tt>atomic&lt;T*&gt;</tt> matches the one in the
+draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt>
+and <tt>compare_swap()</tt> are indeed present.
+</p>
 
-</blockquote>
+<p>
+Strangely, the example implementation does not redefine the method
+<tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not
+hiding the <tt>void*</tt> signature from the base class makes the class
+error-prone to say the least: it lets you assign pointers of any type to
+a <tt>T*</tt>, without any hint from the compiler.
+</p>
 
 <p>
-Add to 23.4.1.3 [unord.map.swap]:
+Is there a true intent to remove them from the specialization or are
+they just missing from the definition because of a mistake?
 </p>
 
+<p><i>[
+Bellevue:
+]</i></p>
+
+
 <blockquote>
-<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>
+<p>
+The proposed revisions are accepted.
+</p>
+<p>
+Further discussion: why is the ctor labeled "constexpr"? Lawrence said
+this permits the object to be statically initialized, and that's
+important because otherwise there would be a race condition on
+initialization.
+</p>
 </blockquote>
 
-<p><b><tt>unordered_multimap</tt></b></p>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-Change 23.4.2 [unord.multimap]:
+Change the synopsis in 29.4.3 [atomics.types.generic]:
 </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>);
-    ...
-};
+<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>
 
-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);
+  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
+  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
 
-<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>
+  atomic() = default; 
+  constexpr explicit atomic(T<ins>*</ins>); 
+  atomic(const atomic&amp;) = delete; 
+  atomic&amp; operator=(const atomic&amp;) = delete; 
 
-<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>
+  T* operator=(T*) volatile; 
+  T* operator++(int) volatile; 
+  T* operator--(int) volatile; 
+  T* operator++() volatile; 
+  T* operator--() volatile; 
+  T* operator+=(ptrdiff_t) volatile;
+  T* operator-=(ptrdiff_t) volatile; 
+};
 </pre></blockquote>
 
+
+
+
+
+
+<hr>
+<h3><a name="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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Add to 23.4.2.1 [unord.multimap.cnstr]:
+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".
 </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><b>Proposed resolution:</b></p>
 
 <p>
-Add new section [unord.multimap.modifiers]:
+In 20.5 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis replace:
 </p>
 
-<blockquote>
-<pre><ins>iterator insert(const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; iterator       insert(P&amp;&amp; x);</ins>
-<ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
-  void insert(InputIterator first, InputIterator last);</ins>
-</pre>
+<blockquote><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>
 
-<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>
+In the class function synopsis of 20.5.15.2 [func.wrap.func] replace
+</p>
 
-<p><ins>
-<tt>P</tt> shall be convertible to <tt>value_type</tt>.
- If <tt>P</tt> is instantiated as a reference
-type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
-is considered to be an rvalue as it is converted to <tt>value_type</tt>
-and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
-cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
-<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
-requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
-mapped_type&gt;</tt>, then <tt>key_type</tt> must be
-<tt>CopyConstructible</tt>).
-</ins></p>
+<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><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>
+<p>
+In 20.5.15.2 [func.wrap.func], "Null pointer comparisons" replace:
+</p>
 
-</blockquote>
+<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>
-Add to 23.4.2.2 [unord.multimap.swap]:
+In 20.5.15.2.1 [func.wrap.func.con], replace
 </p>
 
-<blockquote>
-<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre>
-</blockquote>
+<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><b><tt>unordered_set</tt></b></p>
+<p>
+In 20.5.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>
-Change 23.4.3 [unord.set]:
+and replace
 </p>
 
-<blockquote><pre>class unordered_set
-{
-    ...
-    unordered_set(const unordered_set&amp;);
-    <ins>unordered_set(unordered_set&amp;&amp;);</ins>
-    ~unordered_set();
-    unordered_set&amp; operator=(const unordered_set&amp;);
-    <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
-    ...
-    // modifiers 
-    <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj); 
-    <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
-    iterator       insert(iterator hint, const value_type&amp; obj);
-    <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
-    const_iterator insert(const_iterator hint, const value_type&amp; obj);
-    <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
-    ...
-    void swap(unordered_set&amp;<ins>&amp;</ins>);
-    ...
-};
+<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>
 
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
 
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
 
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
+
+
+
+<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>
+<p><b>Discussion:</b></p>
+<p>
+It is expected that typical implementations of <tt>std::function</tt> will
+use dynamic memory allocations at least under given conditions,
+so it seems appropriate to change the current lvalue swappabilty of
+this class to rvalue swappability.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.5 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis, just below of
+</p>
+
+<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
+<ins>template&lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
+template&lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
 </pre></blockquote>
 
 <p>
-Add to 23.4.3.1 [unord.set.cnstr]:
+In 20.5.15.2 [func.wrap.func] class <tt>function</tt> definition, change
 </p>
 
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
-  unordered_set(InputIterator f, InputIterator l, 
-                size_type n = <i>implementation-defined</i>, 
-                const hasher&amp; hf = hasher(), 
-                const key_equal&amp; eql = key_equal(), 
-                const allocator_type&amp; a = allocator_type());
-</pre>
+<blockquote><pre>void swap(function&amp;<ins>&amp;</ins>);
+</pre></blockquote>
 
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>value_type</tt>, then the
-<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
+<p>
+In 20.5.15.2 [func.wrap.func], just below of
+</p>
+
+<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
+<ins>template &lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
+template &lt;class R, class... ArgTypes&gt;
+  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
+</pre></blockquote>
 
 <p>
-Add new section [unord.set.modifiers]:
+In 20.5.15.2.2 [func.wrap.func.mod] change
 </p>
 
-<blockquote>
-<pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
-<ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; x);</ins>
-<ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
-<ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
-  void insert(InputIterator first, InputIterator last);</ins>
-</pre>
+<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>
+
+<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>
 
-<blockquote>
 
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const
-value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
-be <tt>CopyConstructible</tt>.
-</ins></p>
 
-<p><ins>
-The signature taking <tt>InputIterator</tt> parameters requires
-<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
 
-</blockquote>
 
-</blockquote>
 
+<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>
+<p><b>Discussion:</b></p>
 <p>
-Add to 23.4.3.2 [unord.set.swap]:
+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>
-<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre>
+<i>Throws:</i> nothing
 </blockquote>
 
-<p><b><tt>unordered_multiset</tt></b></p>
-
 <p>
-Change 23.4.4 [unord.multiset]:
+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><pre>class unordered_multiset
-{
-    ...
-    unordered_multiset(const unordered_multiset&amp;);
-    <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
-    ~unordered_multiset();
-    unordered_multiset&amp; operator=(const unordered_multiset&amp;);
-    <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
-    ...
-    // modifiers 
-    iterator insert(const value_type&amp; obj); 
-    <ins>iterator insert(value_type&amp;&amp; obj);</ins>
-    iterator       insert(iterator hint, const value_type&amp; obj);
-    <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
-    const_iterator insert(const_iterator hint, const value_type&amp; obj);
-    <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
-    ...
-    void swap(unordered_multiset&amp;<ins>&amp;</ins>);
-    ...
-};
+<blockquote>
+<i>Throws:</i> Nothing if the string construction throws nothing
+</blockquote>
 
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
+<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).
+</p>
 
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
 
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-Add to 23.4.4.1 [unord.multiset.cnstr]:
+In 21.4 [string.conversions], remove the paragraphs 8 and 16.
 </p>
 
 <blockquote>
-<pre>template &lt;class InputIterator&gt;
-  unordered_multiset(InputIterator f, InputIterator l, 
-                size_type n = <i>implementation-defined</i>, 
-                const hasher&amp; hf = hasher(), 
-                const key_equal&amp; eql = key_equal(), 
-                const allocator_type&amp; a = allocator_type());
+<pre>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><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>value_type</tt>, then the
-<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
+<blockquote>
+<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#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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Add new section [unord.multiset.modifiers]:
+The return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
+overloads says:
 </p>
 
 <blockquote>
-<pre><ins>iterator insert(const value_type&amp; x);</ins>
-<ins>iterator insert(value_type&amp;&amp; x);</ins>
-<ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
-<ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
-  void insert(InputIterator first, InputIterator last);</ins>
-</pre>
+<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>
 
-<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:
+</p>
 
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const
-value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
-be <tt>CopyConstructible</tt>.
-</ins></p>
+<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><ins>
-The signature taking <tt>InputIterator</tt> parameters requires
-<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
 
-</blockquote>
 
+<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>
-Add to 23.4.4.2 [unord.multiset.swap]:
+[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>
-<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x, 
-            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt; 
-  void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x, 
-            unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre>
+<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>
 
 
@@ -10539,1166 +14351,1276 @@ Add to 23.4.4.2 [unord.multiset.swap]:
 
 
 <hr>
-<h3><a name="679"></a>679. resize parameter by value</h3>
-<p><b>Section:</b> 23.2 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="774"></a>774. Member swap undefined for most containers</h3>
+<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>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>
-The C++98 standard specifies that one member function alone of the containers
-passes its parameter (<tt>T</tt>) by value instead of by const reference:
+It appears most containers declare but do not define a member-swap
+function.
 </p>
 
-<blockquote><pre>void resize(size_type sz, T c = T());
-</pre></blockquote>
-
 <p>
-This fact has been discussed / debated repeatedly over the years, the first time
-being even before C++98 was ratified.  The rationale for passing this parameter by
-value has been:
+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>
 <p>
-So that self referencing statements are guaranteed to work, for example:
+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>
-<blockquote><pre>v.resize(v.size() + 1, v[0]);
-</pre></blockquote>
-</blockquote>
 
 <p>
-However this rationale is not convincing as the signature for <tt>push_back</tt> is:
+A quick survey of clause 23 shows that the following containers provide a
+definition for member-swap:
 </p>
 
-<blockquote><pre>void push_back(const T&amp; x);
+<blockquote><pre>array
+queue
+stack
+vector
 </pre></blockquote>
 
 <p>
-And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append).
-And <tt>push_back</tt> must also work in the self referencing case:
+Whereas the following declare it, but do not define the semantics:
 </p>
 
-<blockquote><pre>v.push_back(v[0]);  // must work
+<blockquote><pre>deque
+list
+map
+multimap
+multiset
+priority_queue
+set
+unordered_map
+unordered_multi_map
+unordered_multi_set
+unordered_set
 </pre></blockquote>
 
 <p>
-The problem with passing <tt>T</tt> by value is that it can be significantly more
-expensive than passing by reference.  The converse is also true, however when it is
-true it is usually far less dramatic (e.g. for scalar types).
+Suggested resolution:
 </p>
+<blockquote>
+Provide a definition for each of the affected containers...
+</blockquote>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Move to Open and ask Alisdair to provide wording.
+</blockquote>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Even with move semantics available, passing this parameter by value can be expensive.
-Consider for example <tt>vector&lt;vector&lt;int&gt;&gt;</tt>:
+Wording provided in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>.
 </p>
 
-<blockquote><pre>std::vector&lt;int&gt; x(1000);
-std::vector&lt;std::vector&lt;int&gt;&gt; v;
-...
-v.resize(v.size()+1, x);
-</pre></blockquote>
 
+
+
+
+<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>
-In the pass-by-value case, <tt>x</tt> is copied once to the parameter of
-<tt>resize</tt>.  And then internally, since the code can not know at compile
-time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is
-usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place
-within the <tt>vector</tt>.
+The tuple element access API identifies the element in the sequence
+using signed integers, and then goes on to enforce the requirement that
+I be &gt;= 0.  There is a much easier way to do this - declare I as
+<tt>unsigned</tt>.
 </p>
-
 <p>
-With pass-by-const-reference, the <tt>x</tt> in the above example need be copied
-only once.  In this case, <tt>x</tt> has an expensive copy constructor and so any
-copies that can be saved represents a significant savings.
+In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API.
 </p>
-
 <p>
-If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt>
-as well.  The resize taking a reference parameter has been coded and shipped in the
-CodeWarrior library with no reports of problems which I am aware of.
+A second suggestion is that it is hard to imagine an API that deduces
+and index at compile time and returns a reference throwing an exception.
+Add a specific <em>Throws:</em> Nothing paragraph to each element
+access API.
+</p>
+<p>
+In addition to <code>tuple</code>, update the API applies to
+<code>pair</code> and <code>array</code>, and should be updated
+accordingly.
 </p>
 
+<p>
+A third observation is that the return type of the <code>get</code>
+functions for <code>std::pair</code> is pseudo-code, but it is not
+clearly marked as such.  There is actually no need for pseudo-code as
+the return type can be specified precisely with a call to
+<code>tuple_element</code>.  This is already done for
+<code>std::tuple</code>, and <code>std::array</code> does not have a
+problem as all elements are of type <code>T</code>.
+</p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 23.2.2 [deque], p2:
+Update header &lt;utility&gt; synopsis in 20.2 [utility]
 </p>
+<pre><em>// 20.2.3, tuple-like access to pair:</em>
+template &lt;class T&gt; class tuple_size;
+template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element;
 
-<blockquote><pre>class deque {
-   ...
-   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></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;;
 
+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>
-Change 23.2.2.2 [deque.capacity], p3:
+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>
-
-<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
-
 <p>
-Change 23.2.3 [list], p2:
+<ins><em>Throws:</em> Nothing.</ins>
 </p>
 
-<blockquote><pre>class list {
-   ...
-   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
 
 <p>
-Change 23.2.3.2 [list.capacity], p3:
+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;;
 
-<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
+<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>
-Change 23.2.5 [vector], p2:
+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>
 </p>
 
-<blockquote><pre>class vector {
-   ...
-   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
 
 <p>
-Change 23.2.5.2 [vector.capacity], p11:
+Update header &lt;array&gt; synopsis in 20.2 [utility]
 </p>
+<pre>template &lt;class T&gt; class tuple_size; <em>// forward declaration</em>
+template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// forward declaration</em>
+template &lt;class T, size_t N&gt;
+  struct tuple_size&lt;array&lt;T, N&gt; &gt;;
+template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
+  struct tuple_element&lt;I, array&lt;T, N&gt; &gt;;
+template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
+  T&amp; get(array&lt;T, N&gt;&amp;);
+template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
+  const T&amp; get(const array&lt;T, N&gt;&amp;);
+</pre>
 
-<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
+<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>
+</p>
+<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; const T&amp; get(const array&lt;T, N&gt;&amp; a);
+</pre>
+<p>
+6 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
+</p>
+<p>
+7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
+</p>
+<p>
+<ins><em>Throws:</em> Nothing.</ins>
+</p>
 
 
+<p><i>[
+Bellevue: Note also that the phrase "The program is ill-formed if I is
+out of bounds" in the requires clauses are probably unnecessary, and
+could be removed at the editor's discretion. Also std:: qualification
+for pair is also unnecessary.
+]</i></p>
 
 
 
 
 <hr>
-<h3><a name="680"></a>680. move_iterator operator-&gt; return</h3>
-<p><b>Section:</b> 24.4.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<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>
-<tt>move_iterator</tt>'s <tt>operator-&gt;</tt> return type <tt>pointer</tt>
-does not consistently match the type which is returned in the description
-in 24.4.3.3.5 [move.iter.op.ref].
+The class template array synopsis in 23.2.1 [array]/3 declares a member
+function
 </p>
 
-<blockquote><pre>template &lt;class Iterator&gt;
-class move_iterator {
-public:
-    ...
-    typedef typename iterator_traits&lt;Iterator&gt;::pointer pointer;
-    ...
-    pointer operator-&gt;() const {return current;}
-    ...
-private: 
-    Iterator current; // exposition only
-};
+<blockquote><pre>void assign(const T&amp; u);
 </pre></blockquote>
 
+<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>
-There are two possible fixes.
+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>
 
-<ol>
-<li><tt>pointer operator-&gt;() const {return &amp;*current;}</tt></li>
-<li><tt>typedef Iterator pointer;</tt></li>
-</ol>
+<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>
+
+<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.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Just after the section 23.2.1.4 [array.data] add the following new section:
+</p>
+
+<p>
+23.2.1.5 array::fill [array.fill]
+</p>
+
+<blockquote>
+<pre>void fill(const T&amp; u);
+</pre>
 
 <p>
-The first solution is the one chosen by <tt>reverse_iterator</tt>.  A potential
-disadvantage of this is it may not work well with iterators which return a
-proxy on dereference and that proxy has overloaded <tt>operator&amp;()</tt>.  Proxy
-references often need to overloaad <tt>operator&amp;()</tt> to return a proxy
-pointer.  That proxy pointer may or may not be the same type as the iterator's
-<tt>pointer</tt> type.
+1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
 </p>
+</blockquote>
 
 <p>
-By simply returning the <tt>Iterator</tt> and taking advantage of the fact that
-the language forwards calls to <tt>operator-&gt;</tt> automatically until it
-finds a non-class type, the second solution avoids the issue of an overloaded
-<tt>operator&amp;()</tt> entirely.
+[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>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change the synopsis in 24.4.3.1 [move.iterator]:
+Change the synopsis in 23.2.1 [array]/3:
 </p>
 
-<blockquote><pre>typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
+<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><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Suggest substituting "fill" instead of "assign".
+</p>
+<p>
+Set state to Review given substitution of "fill" for "assign".
+</p>
+</blockquote>
 
 
 
 
 <hr>
-<h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3>
-<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.results">active issues</a> in [re.results].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</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="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>
 <p>
-In 28.4 [re.syn] of N2284, two template functions 
-are declared here: 
+The load functions are defined as
 </p>
-<blockquote><pre>// 28.10, class template match_results: 
-&nbsp; &lt;<i>snip</i>&gt;
-// match_results comparisons 
-&nbsp; template &lt;class BidirectionalIterator, class Allocator&gt; 
-&nbsp; &nbsp; bool operator== (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2); 
-&nbsp; template &lt;class BidirectionalIterator, class Allocator&gt; 
-&nbsp; &nbsp; bool operator!= (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2); 
 
-// 28.10.6, match_results swap:
+<blockquote><pre>C atomic_load(volatile A* object);
+C atomic_load_explicit(volatile A* object, memory_order);
+C A::load(memory_order order = memory_order_seq_cst) volatile;
 </pre></blockquote>
 
 <p>
-But the details of these two bool operator functions (i.e., which members of
-<tt>match_results</tt> should be used in comparison) are not described in any
-following sections.
+which prevents their use in <tt>const</tt> contexts.
 </p>
 
 <p><i>[
-John adds:
+post Bellevue Peter adds:
 ]</i></p>
 
 
-<blockquote><p>
-That looks like a bug: <tt>operator==</tt> should return <tt>true</tt> only if
-the two objects refer to the same match - ie if one object was constructed as a
-copy of the other.
-</p></blockquote>
-
-<p><i>[
-Kona (2007): Bill and Pete to add minor wording to that proposed in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
-]</i></p>
+<blockquote>
+<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:
+</p>
 
+<blockquote><pre>const atomic_int x{};
 
+int main()
+{
+  x.load();
+}
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Add a new section after 28.10.6 [re.results.swap], which reads:
+dump core under a straightforward implementation that puts const objects in
+a read-only section.
 </p>
 <p>
-28.10.7 match_results non-member functions.
+There are ways to sidestep the problem, but it needs to be considered.
 </p>
-
-<blockquote>
-<pre>template&lt;class BidirectionalIterator, class Allocator&gt; 
-  bool operator==(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
-                  const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
-</pre>
-<blockquote>
 <p>
-<i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match.
+The tradeoff is between making the data member of the atomic types
+mutable and requiring the user to explicitly mark atomic members as
+mutable, as is already the case with mutexes.
 </p>
 </blockquote>
-</blockquote>
 
-<blockquote>
-<pre>template&lt;class BidirectionalIterator, class Allocator&gt; 
-  bool operator!=(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
-                  const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>!(m1 == m2)</tt>.
-</p>
-</blockquote>
-</blockquote>
 
-<blockquote>
-<pre>template&lt;class BidirectionalIterator, class Allocator&gt; 
-  void swap(match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
-            match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
-</pre>
-<blockquote>
+
+<p><b>Proposed resolution:</b></p>
 <p>
-<i>Returns:</i> <tt>m1.swap(m2)</tt>.
+Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>.
 </p>
-</blockquote>
-</blockquote>
+
+<blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object);
+C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order);
+C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
+</pre></blockquote>
+
 
 
 
 
 
 <hr>
-<h3><a name="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#Review">Review</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#Review">Review</a> status.</p>
+<h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3>
+<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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>
 <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. 
+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>
-In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff] 
+Suggestion: Add
 </p>
-<blockquote><pre>template&lt;class Iterator1, class Iterator2&gt; 
-typename reverse_iterator&lt;Iterator&gt;::difference_type 
-&nbsp; &nbsp;operator-(const reverse_iterator&lt;Iterator1&gt;&amp; x, 
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const reverse_iterator&lt;Iterator2&gt;&amp; y);
+
+<blockquote><pre>explicit bitset( const char* str );
 </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]. 
+to std::bitset.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change the synopsis in 24.4.1.1 [reverse.iterator]:
+Add to synopsis in 23.3.5 [template.bitset]
 </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(operator-(Iterator1, Iterator2))</ins>;
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>y.current - x.current</tt>.
-</p>
-</blockquote>
-</blockquote>
+<blockquote><pre>explicit bitset( const char* str );
+</pre></blockquote>
 
 <p>
-Change 24.4.1.3.19 [reverse.iter.opdiff]:
+Add to synopsis in 23.3.5.1 [bitset.cons]
 </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(operator-(Iterator1, Iterator2))</ins>;
+<blockquote><pre>explicit bitset( const char* str );
 </pre>
-<blockquote>
 <p>
-<i>Returns:</i> <tt>y.current - x.current</tt>.
+<i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>.
 </p>
 </blockquote>
-</blockquote>
 
 
+
+
+
+
+<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>
-Change the synopsis in 24.4.3.1 [move.iterator]:
+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 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(operator-(Iterator1, Iterator2))</ins>;
-</pre>
-<blockquote>
+
+<p><b>Proposed resolution:</b></p>
 <p>
-<i>Returns:</i> <tt>y.current - x.current</tt>.
+In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with one of:
 </p>
-</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>
 
 <p>
-Change 24.4.3.3.14 [move.iter.nonmember]:
+or
 </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(operator-(Iterator1, Iterator2))</ins>;
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>x.base() - y.base()</tt>.
-</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>
 
 
 
 
 
+
 <hr>
-<h3><a name="686"></a>686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type</h3>
-<p><b>Section:</b> 20.6.5.2.4 [unique.ptr.single.observers], 20.6.6.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> Beman Dawes <b>Date:</b> 2007-06-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</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>
-The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in
-five places. In three of those places (20.5.15.2.3 [func.wrap.func.cap], function capacity 
-for example) the returned value is constrained to disallow
-unintended conversions to int. The standardese is
-</p>
-<blockquote><p>
-The return type shall not be convertible to <tt>int</tt>.
-</p></blockquote>
-<p>
-This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those.
+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>
-To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>()
-const</tt>
-of 20.6.5.2.4 [unique.ptr.single.observers] paragraph 11 and 20.6.6.2.5
-[util.smartptr.shared.obs] paragraph 16, add the sentence:
+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><p>
-The return type shall not be convertible to <tt>int</tt>.
-</p></blockquote>
 
+<ul>
+<li>
+no assignment requirements are specified (neither implicit nor explicit).
+</li>
 
-<p><i>[
-Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue.
-]</i></p>
+<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>
 
 
 
-<hr>
-<h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3>
-<p><b>Section:</b> 20.6.6.2.1 [util.smartptr.shared.const], 20.6.6.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-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><b>Proposed resolution:</b></p>
 <p>
-Since all conversions from <tt>shared_ptr&lt;T&gt;</tt> to <tt>shared_ptr&lt;U&gt;</tt> have the same
-rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user
-code that works with raw pointers fails with <tt>shared_ptr</tt>:
+In 25.3.4 [alg.merge] replace p.1+ 2:
 </p>
 
-<blockquote><pre>void f( shared_ptr&lt;void&gt; );
-void f( shared_ptr&lt;int&gt; );
-
-int main()
-{
-&nbsp;&nbsp;f( shared_ptr&lt;double&gt;() ); // ambiguous
-}
-</pre></blockquote>
-
+<blockquote>
 <p>
-Now that we officially have <tt>enable_if</tt>, we can constrain the constructor
-and the corresponding assignment operator to only participate in the
-overload resolution when the pointer types are compatible.
+<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>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-In 20.6.6.2.1 [util.smartptr.shared.const], change:
+<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><p>
--14- <i>Requires:</i> <del>For the second constructor</del> <ins>The
-second constructor shall not participate in the overload resolution
-unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible
-to <tt>T*</tt>.
-</p></blockquote>
+</blockquote>
 
 <p>
-In 20.6.6.3.1 [util.smartptr.weak.const], change:
+[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>
 
-<blockquote>
-<pre><del>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</del>
-<del>weak_ptr(weak_ptr const&amp; r);</del>
-<del>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</del>
-<ins>weak_ptr(weak_ptr const&amp; r);</ins>
-<ins>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</ins>
-<ins>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</ins>
-</pre>
-<blockquote><p>
--4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and
-third constructors<del>,</del> <ins>shall not participate in the
-overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del>
-<ins>is implicitly</ins> convertible to <tt>T*</tt>.
-</p></blockquote>
-</blockquote>
-
 
 
 
 
 
 <hr>
-<h3><a name="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#Ready">Ready</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#refwrap.const">active issues</a> in [refwrap.const].</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>
+<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 <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
-the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
-to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
-Now that we have a mechanism to detect an rvalue, we can fix them to
-disallow this source of undefined behavior.
-</p>
-
-<p>
-Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+A comparision of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.synopsis])
+with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
+some complex functions that are missing in C++. These are:
 </p>
 
+<ol>
+<li>
+7.3.9.4: (required elements of the C99 library)<br>
+The <tt>cproj</tt> functions
+</li>
+<li>
+7.26.1: (optional elements of the C99 library)<br>
+<pre>cerf    cerfc    cexp2
+cexpm1  clog10   clog1p
+clog2   clgamma  ctgamma
+</pre>
+</li>
+</ol>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-In 20.5.5 [refwrap], add:
+I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent
+C++ functions. This addition is easy to do in one sentence (delegation to C99
+function).
 </p>
 
-<blockquote><pre><ins>private:</ins>
-<ins>&nbsp;&nbsp;explicit reference_wrapper(T&amp;&amp;);</ins>
-</pre></blockquote>
-
 <p>
-In 20.5.5.1 [refwrap.const], add:
+Please note also that the current entry <tt>polar</tt>
+in 26.3.9 [cmplx.over]/1
+should be removed from the mentioned overload list. It does not make sense to require that a
+function already expecting <em>scalar</em> arguments
+should cast these arguments into corresponding
+<tt>complex&lt;T&gt;</tt> arguments, which are not accepted by
+this function.
 </p>
 
-<blockquote>
-<pre><ins>explicit reference_wrapper(T&amp;&amp;);</ins>
-</pre>
-<blockquote><p>
-<ins>-?- Not defined to disallow creating a <tt>reference_wrapper</tt> from an rvalue.</ins>
-</p></blockquote>
-</blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-In the synopsis of <tt>&lt;functional&gt;</tt> (20.5.5 [refwrap]), change the declarations
-of <tt>ref</tt> and <tt>cref</tt> to:
+In 26.3.1 [complex.synopsis] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>:
 </p>
 
-<blockquote><pre>template&lt;class T&gt; reference_wrapper&lt;T&gt; ref(T&amp;<ins>&amp;</ins>);
-template&lt;class T&gt; reference_wrapper&lt;const T&gt; cref(<del>const</del> T&amp;<ins>&amp;</ins>);
+<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 20.5.5.5 [refwrap.helpers], change:
+In 26.3.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add:
 </p>
 
 <blockquote>
-<pre>template&lt;class T&gt; reference_wrapper&lt;T&gt; ref(T&amp;<ins>&amp;</ins> t);
+<pre>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp; x);
 </pre>
 <blockquote>
-<p>
-<ins>-1- <i>Requires:</i> <tt>t</tt> shall be an lvalue.</ins>
-</p>
+
+<i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in
+subclause 7.3.9.4."
 </blockquote>
 </blockquote>
 
-<p>and change:</p>
+<p>
+In 26.3.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to
+the overload list.
+</p>
 
-<blockquote>
-<pre>template&lt;class T&gt; reference_wrapper&lt;const T&gt; cref(<del>const</del> T&amp;<ins>&amp;</ins> t);
-</pre>
 <blockquote>
 <p>
-<ins>-6- <i>Requires:</i> <tt>t</tt> shall be an lvalue.</ins>
+The following function templates shall have additional overloads:
 </p>
+<blockquote><pre>arg           norm 
+conj          <del>polar</del> <ins>proj</ins>
+imag          real
+</pre></blockquote>
 </blockquote>
-</blockquote>
-
 
 
-<p><i>[
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
-addresses the first part of the resolution but not the second.
-]</i></p>
-
 
 
 
 
 <hr>
-<h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3>
-<p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#refwrap.const">active issues</a> in [refwrap.const].</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>
+<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>
+<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>Discussion:</b></p>
 <p>
-The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
-motivation behind this is the safety problem with respect to rvalues,
-which is addressed by the proposed resolution of the previous issue.
-Therefore we should consider relaxing the requirements on the
-constructor since requests for the implicit conversion keep resurfacing.
-</p>
-<p>
-Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+Part of the resolution of n2423, issue 8 was the proposal to
+extend the <tt>seed_seq</tt> constructor accepting an input range
+as follows (which is now part of N2461):
 </p>
 
+<blockquote><pre>template&lt;class InputIterator,
+size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits&gt;
+seed_seq(InputIterator begin, InputIterator end);
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the
-proposed resolution of the previous issue is accepted, remove the
-<tt>explicit</tt> from the <tt>T&amp;&amp;</tt> constructor as well to keep them in sync.
+First, the expression <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt>
+is invalid due to missing <tt>typename</tt> keyword, which is easy to
+fix.
 </p>
 
+<p>
+Second (and worse), while the language now supports default
+template arguments of function templates, this customization
+point via the second <tt>size_t</tt> template parameter is of no advantage,
+because <tt>u</tt> can never be deduced, and worse - because it is a
+constructor function template - it can also never be explicitly
+provided (14.8.1 [temp.arg.explicit]/7).
+</p>
 
+<p>
+The question arises, which advantages result from a compile-time
+knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge
+suffices, this parameter should be provided as normal function
+default argument [Resolution marked (A)], if compile-time knowledge
+is important, this could be done via a tagging template or more
+user-friendly via a standardized helper generator function
+(<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)].
+</p>
 
+<p><i>[
+Bellevue:
+]</i></p>
 
 
-<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>
- <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>Discussion:</b></p>
+<blockquote>
 <p>
-The last version of TR1 does not include the following member
-functions
-for unordered containers:
+Fermilab does not have a strong opinion. Would prefer to go with
+solution A. Bill agrees that solution A is a lot simpler and does the
+job.
 </p>
-
-<blockquote><pre>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-</pre></blockquote>
-
 <p>
-which looks like an oversight to me. I've checked th TR1 issues lists
-and the latest working draft of the C++0x std (N2284) and haven't
-found any mention to these menfuns or to their absence.
+Proposed Resolution: Accept Solution A.
 </p>
+</blockquote>
+
 <p>
-Is this really an oversight, or am I missing something?
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> claims to make this issue moot.
 </p>
 
 
 
 <p><b>Proposed resolution:</b></p>
+<ol type="A">
+<li>
 <p>
-Add the following two rows to table 93 (unordered associative container
-requirements) in section 23.1.3 [unord.req]:
+In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace:
 </p>
 
-<blockquote>
-<table border="1">
-<caption>Unordered associative container requirements (in addition to container)</caption>
-<tbody><tr>
-<th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
-</tr>
-<tr>
-<td><ins><tt>b.cbegin(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>. Note: <tt>[b.cbegin(n), b.cend(n))</tt> is a valid range containing all of the elements in the <tt>n</tt><sup><i>th</i></sup> bucket.</ins></td> <td><ins>Constant</ins></td> 
-</tr>
-<tr>
-<td><ins><tt>b.cend(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>.</ins></td> <td><ins>Constant</ins></td> 
-</tr>
-</tbody></table>
-</blockquote>
+<blockquote><pre>class seed_seq 
+{ 
+public:
+   ...
+   template&lt;class InputIterator<del>,
+      size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
+          seed_seq(InputIterator begin, InputIterator end<ins>,
+          size_t u = numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</ins>);
+   ...
+};
+</pre></blockquote>
 
 <p>
-Add to the synopsis in 23.4.1 [unord.map]:
+and do a similar replacement in the member description between
+p.3 and p.4.
 </p>
+</li>
 
-<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;</ins>
-</pre></blockquote>
-
+<li>
 <p>
-Add to the synopsis in 23.4.2 [unord.multimap]:
+In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the
+member description between p.3 and p.4 replace:
 </p>
 
-<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;</ins>
+<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>
-Add to the synopsis in 23.4.3 [unord.set]:
+In 26.4.2 [rand.synopsis], header <tt>&lt;random&gt;</tt> synopsis, immediately after the
+class <tt>seed_seq</tt> declaration <em>and</em> in 26.4.7.1 [rand.util.seedseq]/2, immediately
+after the class <tt>seed_seq</tt> definition add:
 </p>
 
-<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;</ins>
+<blockquote><pre>template&lt;size_t u, class InputIterator&gt;
+  seed_seq make_seed_seq(InputIterator begin, InputIterator end);
 </pre></blockquote>
 
 <p>
-Add to the synopsis in 23.4.4 [unord.multiset]:
+In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
 </p>
 
-<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;</ins>
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be&nbsp;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>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
 <p>
-In a private email Bill Plauger notes:
-</p>
-<blockquote><p>
-I &nbsp;believe that &nbsp;the function &nbsp;that &nbsp;implements <code>get_money</code>
-[from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
-should behave &nbsp;as a &nbsp;formatted input function, &nbsp;and the &nbsp;function that
-implements <code>put_money</code> should &nbsp;behave as a formatted output
-function. This &nbsp;has implications regarding the &nbsp;skipping of whitespace
-and the handling of errors, among other things.
+The first constructor behaves as if it would provide an
+integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value
+<tt>numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</tt>.
 </p>
 <p>
-The words &nbsp;don't say that &nbsp;right now and &nbsp;I'm far from &nbsp;convinced that
-such a change is editorial.
-</p></blockquote>
-<p>
-Martin's response:
-</p>
-<blockquote><p>
-I agree that the manipulators should handle exceptions the same way as
-formatted I/O functions do. The text in N2072 assumes so but the
-<i>Returns</i> clause explicitly omits exception handling for the sake
-of brevity. The spec should be clarified to that effect.
+The second constructor uses an implementation-defined mechanism
+to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and
+is called by the function <tt>make_seed_seq</tt>.
 </p>
-<p>
-As for dealing &nbsp;with whitespace, I also agree it &nbsp;would make sense for
-the extractors &nbsp;and inserters involving the new &nbsp;manipulators to treat
-it the same way as formatted I/O.
-</p></blockquote>
+</blockquote>
 
+<p>
+In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
+</p>
 
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+<pre>template&lt;size_t u, class InputIterator&gt;
+   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+</pre>
+<blockquote>
 <p>
-Add &nbsp;a new &nbsp;paragraph immediately &nbsp;above &nbsp;p4 of 27.6.4 [ext.manip] with &nbsp;the
-following text:
+where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type.
 </p>
-<blockquote><p>
-<i>Effects</i>: &nbsp;The &nbsp;&nbsp;expression &nbsp;<code><i>in</i> &gt;&gt; get_money(mon, intl)</code>
-described below behaves as a formatted input function (as
-described in 27.6.1.2.1 [istream.formatted.reqmts]).
-</p></blockquote>
 <p>
-Also change p4 of 27.6.4 [ext.manip] as follows:
+<i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>;
 </p>
-<blockquote><p>
-<i>Returns</i>: An object <code>s</code> of unspecified type such that
-if <code>in</code> is &nbsp;an object of type <code>basic_istream&lt;charT,
-traits&gt;</code> &nbsp;&nbsp;&nbsp;then &nbsp;&nbsp;&nbsp;the &nbsp;&nbsp;&nbsp;expression &nbsp;&nbsp;<code><i>in</i> &gt;&gt; get_money(mon, intl)</code> behaves as <ins>a formatted input function
-that &nbsp;&nbsp;&nbsp;calls &nbsp;&nbsp;&nbsp;</ins><code>f(in, mon, intl)</code><del> &nbsp;&nbsp;&nbsp;were
-called</del>. The function <code>f</code> can be defined as...
-</p></blockquote>
+</blockquote>
+</blockquote>
+
+</li>
+</ol>
+
 
 
 
 
 
 <hr>
-<h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3>
-<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</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#template.bitset">active issues</a> in [template.bitset].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
+<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>
 <p><b>Discussion:</b></p>
 <p>
-The  <code>bitset</code> class template  provides the  member function
-<code>any()</code> to determine whether an  object of the type has any
-bits  set, and  the member  function <code>none()</code>  to determine
-whether all of an object's  bits are clear. However, the template does
-not   provide  a   corresponding  function   to  discover   whether  a
-<code>bitset</code>  object  has  all  its  bits  set.   While  it  is
-possible,  even easy,  to  obtain this  information  by comparing  the
-result of <code>count()</code>  with the result of <code>size()</code>
-for  equality  (i.e.,  via  <code>b.count()  ==  b.size()</code>)  the
-operation  is   less  efficient   than  a  member   function  designed
-specifically  for that purpose  could be.   (<code>count()</code> must
-count  all non-zero bits  in a  <code>bitset</code> a  word at  a time
-while <code>all()</code> could stop counting as soon as it encountered
-the first word with a zero bit).
+The current working paper 
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>,
+integrated just before Bellevue) is
+not completely clear whether a given <tt>thread::id</tt> value may be reused once
+a thread has exited and has been joined or detached.  Posix allows
+thread ids (<tt>pthread_t</tt> values) to be reused in this case.  Although it is
+not completely clear whether this originally was the right decision, it
+is clearly the established practice, and we believe it was always the
+intent of the C++ threads API to follow Posix and allow this.  Howard
+Hinnant's example implementation implicitly relies on allowing reuse
+of ids, since it uses Posix thread ids directly.
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Add  a declaration of the new  member function <code>all()</code> to the
-defintion of the <code>bitset</code> template in 23.3.5 [template.bitset], p1,
-right above the declaration of <code>any()</code> as shown below:
+It is important to be clear on this point, since it the reuse of thread
+ids often requires extra care in client code, which would not be
+necessary if thread ids were unique across all time.  For example, a
+hash table indexed by thread id may have to be careful not to associate
+data values from an old thread with a new one that happens to reuse the
+id.  Simply removing the old entry after joining a thread may not be
+sufficient, if it creates a visible window between the join and removal
+during which a new thread with the same id could have been created and
+added to the table.
 </p>
 
-<blockquote><pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
-bool test(size_t pos) const;
-<ins>bool all() const;</ins>
-bool any() const;
-bool none() const;
-</pre></blockquote>
+<p><i>[
+post Bellevue Peter adds:
+]</i></p>
 
-<p>
-Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
-</p>
-<blockquote><p>
-<code>bool all() const;</code>
-</p>
-<blockquote>
-<i>Returns</i>: <code>count() == size()</code>.
-</blockquote>
-</blockquote>
 
+<blockquote>
 <p>
-In  addition,   change  the  description   of  <code>any()</code>  and
-<code>none()</code>   for  consistency   with   <code>all()</code>  as
-follows:
+There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to
+reconsider fixing this by disallowing reuse, rather than explicitly allowing
+it. Dealing with thread id reuse is an incredibly painful exercise that
+would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over
+and over.
 </p>
-<blockquote><p>
-<code>bool any() const;</code>
+<p>
+In addition, it would be nice if a <tt>thread::id</tt> could be manipulated
+atomically in a lock-free manner, as motivated by the recursive lock
+example:
 </p>
-<blockquote>
+
 <p>
-<i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code>
-is one</del><ins><code>count() != 0</code></ins>.
+<a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a>
 </p>
 </blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-<code>bool none() const;</code>
+Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
 </p>
+
 <blockquote>
 <p>
-<i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code>
-is one</del><ins><code>count() == 0</code></ins>.
+An object of type <code>thread::id</code> provides
+a unique identifier for each thread of execution
+and a single distinct value for all thread objects
+that do not represent a thread of execution ([thread.threads.class]).
+Each thread of execution has a <code>thread::id</code>
+that is not equal to the <code>thread::id</code>
+of other threads of execution
+and that is not equal to
+the <code>thread::id</code> of <code>std::thread</code> objects
+that do not represent threads of execution.
+<ins>The library may reuse the value of a <code>thread::id</code> of a
+terminated thread that can no longer be joined.</ins>
 </p>
 </blockquote>
-</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></h3>
-<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</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#template.bitset">active issues</a> in [template.bitset].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<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>
-Objects of the  <code>bitset</code> class template specializations can
-be constructed from  and explicitly converted to values  of the widest
-C++ integer  type, <code>unsigned long</code>.   With the introduction
-of  <code>long long</code> into  the language  the template  should be
-enhanced to make it possible  to interoperate with values of this type
-as well, or  perhaps <code>uintmax_t</code>.  See c++std-lib-18274 for
-a brief discussion in support of this change.
+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>
-For simplicity,  instead of  adding overloads for  <code>unsigned long
-long</code> and dealing with possible ambiguities in the spec, replace
-the <code>bitset</code> ctor  that takes an <code>unsigned long</code>
-argument  with  one  taking  <code>unsigned long  long</code>  in  the
-definition  of the  template as  shown below.   (The  standard permits
-implementations  to add  overloads on  other integer  types  or employ
-template tricks to  achieve the same effect provided  they don't cause
-ambiguities or changes in behavior.)
+member function that is equivalent to:
 </p>
-<blockquote>
-<pre>// [bitset.cons] constructors:
-bitset();
-bitset(unsigned <ins>long</ins> long val);
-template&lt;class charT, class traits, class Allocator&gt;
-explicit bitset(
-                const basic_string&lt;charT,traits,Allocator&gt;&amp; str,
-                typename basic_string&lt;charT,traits,Allocator&gt;::size_type pos = 0,
-                typename basic_string&lt;charT,traits,Allocator&gt;::size_type n =
-                    basic_string&lt;charT,traits,Allocator&gt;::npos);
-</pre>
-</blockquote>
+
+<blockquote><pre>mygen = Generator(s)
+</pre></blockquote>
+
 <p>
-Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
 </p>
-<blockquote>
+
+<blockquote><pre>template &lt;class Gen&gt;
+seed(Gen&amp;);
+</pre></blockquote>
+
 <p>
-<code>bitset(unsigned <ins>long</ins> long val);</code>
+member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
 </p>
-<blockquote>
-<i>Effects</i>:  Constructs   an  object  of   class  bitset&lt;N&gt;,
-initializing  the  first <code><i>M</i></code>  bit  positions to  the
-corresponding      bit     values      in     <code><i>val</i></code>.
-<code><i>M</i></code> is the  smaller of <code><i>N</i></code> and the
-number of bits in  the value representation (section [basic.types]) of
-<code>unsigned  <ins> long</ins> long</code>.   If  <code><i>M</i> &lt;
-<i>N</i></code>  <ins>is  <code>true</code></ins>,  the remaining  bit
-positions are initialized to zero.
-</blockquote>
-</blockquote>
 
 <p>
-Additionally, introduce a new member function <code>to_ullong()</code>
-to make  it possible to  convert <code>bitset</code> to values  of the
-new  type. Add  the following  declaration  to the  definition of  the
-template, immediate  after the declaration  of <code>to_ulong()</code>
-in 23.3.5 [template.bitset], p1, as shown below:
+So... is this a bug in TR1?
 </p>
-<blockquote>
-<pre>// element access:
-bool operator[](size_t pos) const; // for b[i];
-reference operator[](size_t pos); // for b[i];
-unsigned long to_ulong() const;
-<ins>unsigned long long to_ullong() const;</ins>
-template &lt;class charT, class traits, class Allocator&gt;
-basic_string&lt;charT, traits, Allocator&gt; to_string() const;
-</pre>
-</blockquote>
-<p>
-And add a description of  the new member function to 23.3.5.2 [bitset.members],
-below  the  description of  the  existing <code>to_ulong()</code>  (if
-possible), with the following text:
+
+<p>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>
+
+<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>
-<code>unsigned long long to_ullong() const;</code>
 </p>
-<blockquote>
-<i>Throws</i>:  <code>overflow_error</code>   if  the  integral  value
-<code><i>x</i></code> corresponding to  the bits in <code>*this</code>
-cannot be represented as type <code>unsigned long long</code>.
-</blockquote>
-<blockquote>
-<i>Returns:</i> <code><i>x</i></code>.
-</blockquote>
-</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="695"></a>695. ctype&lt;char&gt;::classic_table() not accessible</h3>
-<p><b>Section:</b> 22.2.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<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>
 <p>
-The   <code>ctype&lt;char&gt;::classic_table()</code>   static  member
-function    returns    a    pointer    to   an    array    of    const
-<code>ctype_base::mask</code>    objects    (enums)   that    contains
-<code>ctype&lt;char&gt;::table_size</code>    elements.    The   table
-describes the properties of the character set in the "C" locale (i.e.,
-whether a  character at an index  given by its value  is alpha, digit,
-punct,   etc.),   and   is    typically   used   to   initialize   the
-<code>ctype&lt;char&gt;</code>  facet in the  classic "C"  locale (the
-protected      <code>ctype&lt;char&gt;</code>      member     function
-<code>table()</code>    then    returns     the    same    value    as
-<code>classic_table()</code>).
+The draft C++0x thread library requires that the time points of type
+<tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated
+Universal Time (UTC) (section X [datetime.system]). This can lead to
+surprising behavior when a library user performs a duration-based wait,
+such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the
+problem may be found in the
+<a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a>
+section in POSIX, but in summary:
 </p>
+
+<ul>
+<li>
+Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX
+equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times
+to address the problem of spurious wakeups.
+</li>
+
+<li>
+The typical use of the timed wait operations is to perform a relative
+wait. This may be achieved by first calculating an absolute time as the
+sum of the current time and the desired duration. In fact, the C++0x
+thread library includes duration-based overloads of
+<tt>condition_variable::timed_wait()</tt> that behave as if by calling the
+corresponding absolute time overload with a time point value of
+<tt>get_system_time() + rel_time</tt>.
+</li>
+
+<li>
+A UTC clock may be affected by changes to the system time, such as
+synchronization with an external source, leap seconds, or manual changes
+to the clock.
+</li>
+
+<li>
+Should the clock change during a timed wait operation, the actual
+duration of the wait will not be the expected length. For example, a
+user may intend a timed wait of one second duration but, due to an
+adjustment of the system clock backwards by a minute, the wait instead
+takes 61 seconds.
+</li>
+</ul>
+
 <p>
-However, while <code>ctype&lt;char&gt;::table_size</code> (the size of
-the   table)    is   a   public    static   const   member    of   the
-<code>ctype&lt;char&gt;</code>           specialization,           the
-<code>classic_table()</code> static member function is protected. That
-makes getting at the classic  data less than convenient (i.e., one has
-to create  a whole derived class just  to get at the  masks array). It
-makes  little sense  to expose  the size  of the  table in  the public
-interface while making the table itself protected, especially when the
-table is a constant object.
+POSIX solves the problem by introducing a new monotonic clock, which is
+unaffected by changes to the system time. When a condition variable is
+initialized, the user may specify whether the monotonic clock is to be
+used. (It is worth noting that on POSIX systems it is not possible to
+use <tt>condition_variable::native_handle()</tt> to access this facility, since
+the desired clock type must be specified during construction of the
+condition variable object.)
 </p>
+
 <p>
-The  same argument  can be  made for  the non-static  protected member
-function <code>table()</code>.
+In the context of the C++0x thread library, there are added dimensions
+to the problem due to the need to support platforms other than POSIX:
 </p>
 
+<ul>
+<li>
+Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
+</li>
+
+<li>
+Some environments do not have a monotonic clock, but do have a UTC clock.
+</li>
+
+<li>
+The Microsoft Windows API's synchronization functions use relative
+timeouts based on an implied monotonic clock. A program that switches
+from the Windows API to the C++0x thread library will now find itself
+susceptible to clock changes.
+</li>
+</ul>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Make     the    <code>ctype&lt;char&gt;::classic_table()</code>    and
-<code>ctype&lt;char&gt;::table()</code>  member  functions  public  by
-moving their declarations into the public section of the definition of
-specialization in 22.2.1.3 [facet.ctype.special] as shown below:
+One possible minimal solution:
 </p>
-<blockquote>
-<pre>  static locale::id id;
-  static const size_t table_size = IMPLEMENTATION_DEFINED;
-<del>protected:</del>
-  const mask* table() const throw();
-  static const mask* classic_table() throw();
-<ins>protected:</ins>
 
-~ctype(); // virtual
-virtual char do_toupper(char c) const;
-</pre>
-</blockquote>
+<ul>
+<li>
+Strike normative references to UTC and an epoch based on 1970-01-01.
+</li>
+
+<li>
+Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt>
+implementation-defined (i.e standard library implementors may choose the
+appropriate underlying clock based on the capabilities of the target
+platform).
+</li>
+
+<li>
+Add a non-normative note encouraging use of a monotonic clock.
+</li>
+
+<li>
+Remove <tt>system_time::seconds_since_epoch()</tt>.
+</li>
+
+<li>
+Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns
+= 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>.
+</li>
+</ul>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
 
 
 
 
 
 <hr>
-<h3><a name="696"></a>696. <code>istream::operator&gt;&gt;(int&amp;)</code> broken</h3>
-<p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <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> 2007-06-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
+<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>
 <p>
-From message c++std-lib-17897:
-</p>
-<p>
-The  code  shown  in  27.6.1.2.2 [istream.formatted.arithmetic] as  the  "as  if"
-implementation  of the  two arithmetic  extractors that  don't  have a
-corresponding     <code>num_get</code>     interface    (i.e.,     the
-<code>short</code> and <code>int</code>  overloads) is subtly buggy in
-how  it  deals  with  <code>EOF</code>, overflow,  and  other  similar
-conditions (in addition to containing a few typos).
+In 25.3.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as
 </p>
+
+<blockquote>
+At most <tt>log(last - first) + 2</tt> comparisons.
+</blockquote>
+
 <p>
-One  problem is  that if  <code>num_get::get()</code> reaches  the EOF
-after reading in  an otherwise valid value that  exceeds the limits of
-the    narrower    type     (but    not    <code>LONG_MIN</code>    or
-<code>LONG_MAX</code>),   it  will   set   <code><i>err</i></code>  to
-<code>eofbit</code>.   Because   of  the  if   condition  testing  for
-<code>(<i>err</i> == 0)</code>,    the   extractor    won't   set
-<code>failbit</code>  (and presumably,  return  a bogus  value to  the
-caller).
+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>
+
 <p>
-Another  problem with  the code  is that  it never  actually  sets the
-argument to  the extracted  value. It can't  happen after the  call to
-<code>setstate()</code> since  the function may  throw, so we  need to
-show when  and how it's done (we  can't just punt as  say: "it happens
-afterwards"). However, it  turns out that showing how  it's done isn't
-quite so  easy since  the argument is  normally left unchanged  by the
-facet on error  except when the error is due  to a misplaced thousands
-separator,  which causes  <code>failbit</code> to  be set  but doesn't
-prevent the facet from storing the value.
+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><b>Proposed resolution:</b></p>
 <p>
+Change 25.3.3.4 [binary.search]/3
 </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>
+
 
 
 
 
 <hr>
-<h3><a name="697"></a>697. New <tt>&lt;system_error&gt;</tt> header leads to name clashes</h3>
-<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-24</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 most recent state of 
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>
-as well as the current draft
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
-(section 19.4 [syserr], p.2) proposes a
-new
-enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
-the enumerators has the name <tt>invalid_argument</tt>, or fully qualified:
-<tt>std::invalid_argument</tt>. This name clashes with the exception type
-<tt>std::invalid_argument</tt>, see 19.1 [std.exceptions]/p.3. This clash makes
-e.g. the following snippet invalid:
+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><pre>#include &lt;system_error&gt;
-#include &lt;stdexcept&gt;
-
-void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
-</pre></blockquote>
+<blockquote>
+<tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
+input stream for which it was constructed. After it is constructed, and
+every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
+the end of stream is reached (<tt>operator void*()</tt> on the stream returns
+<tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
+The constructor with no arguments <tt>istream_iterator()</tt> always constructs
+an end of stream input iterator object, which is the only legitimate
+iterator to be used for the end condition. The result of <tt>operator*</tt> on an
+end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
+returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
+For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
+store things into istream iterators. The main peculiarity of the istream
+iterators is the fact that <tt>++</tt> operators are not equality preserving,
+that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
+is used a new value is read.
+</blockquote>
 
 <p>
-I propose that this enumeration type (and probably the remaining parts
-of
-<tt>&lt;system_error&gt;</tt> as well) should be moved into one additional inner
-namespace, e.g. <tt>sys</tt> or <tt>system</tt> to reduce foreseeable future clashes
-due
-to the great number of members that <tt>std::posix_errno</tt> already contains
-(Btw.: Why has the already proposed <tt>std::sys</tt> sub-namespace from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a>
-been rejected?). A further clash <em>candidate</em> seems to be
-<tt>std::protocol_error</tt>
-(a reasonable name for an exception related to a std network library,
-I guess).
+<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>
 
 <p>
-Another possible resolution would rely on the proposed strongly typed
-enums,
-as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2213.pdf">N2213</a>.
-But maybe the forbidden implicit conversion to integral types would
-make
-these enumerators less attractive in this special case?
+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 24.5.1 [istream.iterator]/1:
 </p>
 
+<blockquote>
+<tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
+input stream for which it was constructed. After it is constructed, and
+every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
+<del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins>
+(<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns
+<tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
+The constructor with no arguments <tt>istream_iterator()</tt> always constructs
+an end of stream input iterator object, which is the only legitimate
+iterator to be used for the end condition. The result of <tt>operator*</tt> on an
+end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
+returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
+For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
+store things into istream iterators. The main peculiarity of the istream
+iterators is the fact that <tt>++</tt> operators are not equality preserving,
+that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
+is used a new value is read.
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="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>
- <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>
+<h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3>
+<p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-In 19.4.5.1 [syserr.syserr.overview] we have the class definition of
-<tt>std::system_error</tt>. In contrast to all exception classes, which
-are constructible with a <tt>what_arg string</tt> (see 19.1 [std.exceptions],
-or <tt>ios_base::failure</tt> in 27.4.2.1.1 [ios::failure]), only overloads with with
-<tt>const string&amp;</tt> are possible. For consistency with the re-designed
-remaining exception classes this class should also provide
-c'tors which accept a const <tt>char* what_arg</tt> string.
-</p>
-<p>
-Please note that this proposed addition makes sense even
-considering the given implementation hint for <tt>what()</tt>, because
-<tt>what_arg</tt> is required to be set as <tt>what_arg</tt> of the base class
-<tt>runtime_error</tt>, which now has the additional c'tor overload
-accepting a <tt>const char*</tt>.
+<tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.)
 </p>
 
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Non-controversial. Bill is right, but Fermilab believes that this is
+easy to use badly and hard to use right, and so it should be removed
+entirely. Got into TR1 by well defined route, do we have permission to
+remove stuff? Should probably check with Jens, as it is believed he is
+the originator. Broad consensus that this is not a robust engine
+adapter.
+</blockquote>
+
 
 <p><b>Proposed resolution:</b></p>
 <p>
+Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
+</p>
+<p>
+Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>.
 </p>
 
 
@@ -11706,407 +15628,367 @@ accepting a <tt>const char*</tt>.
 
 
 <hr>
-<h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3>
-<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p>
+<h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3>
+<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
-defines struct <tt>identity</tt> in <tt>&lt;utility&gt;</tt> which clashes with
-the traditional definition of struct <tt>identity</tt> in <tt>&lt;functional&gt;</tt>
-(not standard, but a common extension from old STL). Be nice
-if we could avoid this name clash for backward compatibility.
+<tt>piecewise_constant_distribution</tt> is undefined for a range with just one
+endpoint. (Probably should be the same as an empty range.)
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 20.2.2 [forward]:
+Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
 </p>
 
 <blockquote>
-<pre>template &lt;class T&gt; struct identity
-{
-    typedef T type;
-    <ins>const T&amp; operator()(const T&amp; x) const;</ins>
-};
-</pre>
-<blockquote>
-<pre><ins>const T&amp; operator()(const T&amp; x) const;</ins>
-</pre>
-<blockquote>
-<p>
-<ins><i>Returns:</i> <tt>x</tt>.</ins>
-</p>
-</blockquote>
-</blockquote>
-
+b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>,
 </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>
-<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="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
+<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-I see that the definition the associated Laguerre
-polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>.
-However, the draft standard only specifies ranks of integer value <tt>m</tt>,
-while the associated Laguerre polynomials are actually valid for real
-values of <tt>m &gt; -1</tt>. &nbsp;In the case of non-integer values of <tt>m</tt>, the
-definition &nbsp;<tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt>
-must be used, which also holds for integer values of <tt>m</tt>. &nbsp;See
-Abramowitz &amp; Stegun, 22.11.6 for the general case, and 22.5.16-17 for
-the integer case.&nbsp;&nbsp;In fact fractional values are most commonly used in
-physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic
-oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3
-dimensions.
+<tt>discrete_distribution</tt> should have a constructor like:
 </p>
+
+<blockquote><pre>template&lt;class _Fn&gt;
+  discrete_distribution(result_type _Count, double _Low, double _High,
+                        _Fn&amp; _Func);
+</pre></blockquote>
+
 <p>
-If I am correct, the calculation of the more general case is no
-more difficult, and is in fact the function implemented in the GNU
-Scientific Library.&nbsp;&nbsp;I would urge you to consider upgrading the 
-standard, either adding extra functions for real <tt>m</tt> or switching the
-current ones to <tt>double</tt>.
+(Makes it easier to fill a histogram with function vaues over a range.)
 </p>
 
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+How do you specify the function so that it does not return negative
+values? If you do it is a bad construction. This requirement is already
+there. Where in each bin does one evaluate the function? In the middle.
+Need to revisit tomorrow.
+</blockquote>
+
 
 <p><b>Proposed resolution:</b></p>
-<p>
-</p>
 
 
 
 
 
 <hr>
-<h3><a name="702"></a>702. Restriction in associated Legendre functions</h3>
-<p><b>Section:</b> TR1 5.2.1.2 [tr.num.sf.Plm] <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>
+<h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
+<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should&nbsp;&nbsp;be
-<tt>|x| &lt;= 1</tt>, not <tt>x &gt;= 0</tt>.</p>
+<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>
+(Makes it easier to fill a histogram with function vaues over a range.
+The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>) make a sensible replacement for
+<tt>general_pdf_distribution</tt>.)
 </p>
 
 
+<p><b>Proposed resolution:</b></p>
+
+
 
 
 
 <hr>
-<h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3>
-<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
+<h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3>
+<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-14</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-<tt>map::at()</tt> need a complexity specification.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf">N2521</a>
+and its earlier predecessors have moved the old binders from
+[lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming
+of the template parameter names (<tt>Operation -&gt; Fn</tt>). During this
+renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to
+<tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if
+this user access point is probably rarely used.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]:
+Change D.8.1 [depr.lib.binder.1st]:
 </p>
+
+<blockquote>
+<pre>template &lt;class Fn&gt; 
+class binder1st 
+  : public unary_function&lt;typename Fn::second_argument_type, 
+                          typename Fn::result_type&gt; { 
+protected: 
+  Fn <del>fn</del> <ins>op</ins>; 
+  typename Fn::first_argument_type value; 
+public: 
+  binder1st(const Fn&amp; x, 
+            const typename Fn::first_argument_type&amp; y); 
+  typename Fn::result_type 
+    operator()(const typename Fn::second_argument_type&amp; x) const; 
+  typename Fn::result_type 
+    operator()(typename Fn::second_argument_type&amp; x) const; 
+};
+</pre>
+
 <blockquote>
 <p>
-<i>Complexity:</i> logarithmic.
+-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
 </p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</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-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from
-most of the member functions of node-based containers.  But the move-related changes
-unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
-require <tt>CopyAssignable</tt>.
+-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
 </p>
+</blockquote>
+</blockquote>
 
 <p>
-We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
-from some of the sequence requirements.  Additionally the <i>in-place</i> construction
-work may further reduce requirements.  For purposes of an easy reference, here are the
-minimum sequence requirements as I currently understand them.  Those items in requirements
-table in the working draft which do not appear below have been purposefully omitted for
-brevity as they do not have any requirements of this nature.  Some items which do not
-have any requirements of this nature are included below just to confirm that they were
-not omitted by mistake.
+Change D.8.3 [depr.lib.binder.2nd]:
 </p>
 
-<table border="1">
-<caption>Container Requirements</caption>
-<tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
-<tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> requires <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>
-</tbody></table>
+<blockquote>
+<pre>template &lt;class Fn&gt; 
+class binder2nd
+  : public unary_function&lt;typename Fn::first_argument_type, 
+                          typename Fn::result_type&gt; { 
+protected: 
+  Fn <del>fn</del> <ins>op</ins>; 
+  typename Fn::second_argument_type value; 
+public: 
+  binder2nd(const Fn&amp; x, 
+            const typename Fn::second_argument_type&amp; y); 
+  typename Fn::result_type 
+    operator()(const typename Fn::first_argument_type&amp; x) const; 
+  typename Fn::result_type 
+    operator()(typename Fn::first_argument_type&amp; x) const; 
+};
+</pre>
 
+<blockquote>
 <p>
+-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
 </p>
-
-<table border="1">
-<caption>Sequence Requirements</caption>
-<tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
-<tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
-<tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
-<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
-                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
-<tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
-                                        If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
-                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
-<tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.clear()</tt></td><td></td></tr>
-<tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
-                                        If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
-<tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
-                                     The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-</tbody></table>
-
 <p>
+-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
 </p>
+</blockquote>
+</blockquote>
 
-<table border="1">
-<caption>Optional Sequence Requirements</caption>
-<tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
-<tr><td><tt>a.back()</tt></td><td></td></tr>
-<tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.pop_front()</tt></td><td></td></tr>
-<tr><td><tt>a.pop_back()</tt></td><td></td></tr>
-<tr><td><tt>a[n]</tt></td><td></td></tr>
-<tr><td><tt>a.at[n]</tt></td><td></td></tr>
-</tbody></table>
 
-<p>
-</p>
 
-<table border="1">
-<caption>Associative Container Requirements</caption>
-<tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                        If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
-</tbody></table>
 
+
+
+<hr>
+<h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3>
+<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2008-02-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
+The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is
+defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities.
+Previous versions of this algorithm and the general logic behind it
+suggest that this is an oversight and that in the context of the
+for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded
+upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits
+in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt>
+to 0.
 </p>
 
-<table border="1">
-<caption>Unordered Associative Container Requirements</caption>
-<tbody><tr><td><tt>X(i, j, n, hf, eq)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
-                                        If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
-</tbody></table>
-
 <p>
+There are two more minor issues:
 </p>
 
-<table border="1">
-<caption>Miscellaneous Requirements</caption>
-<tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
-                                         The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
-                                         The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
-</tbody></table>
+<ul>
+<li>
+Strictly speaking <tt>end - begin</tt> is not defined since
+<tt>InputIterator</tt> is not required to be a random access iterator.
+</li>
+<li>
+Currently all integral types are allowed as input to the <tt>seed_seq</tt>
+constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily
+complicates the implementation without any real benefit to the user.
+I'd suggest to exclude <tt>bool</tt>s as input.
+</li>
+</ul>
 
 <p><i>[
-Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
+Bellevue:
 ]</i></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>
 
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3>
-<p><b>Section:</b> 20.4.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-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 current working draft has a type-trait <tt>decay</tt> in 20.4.7 [meta.trans.other].
-</p>
 
 <p>
-Its use is to turn C++03 pass-by-value parameters into efficient C++0x
-pass-by-rvalue-reference parameters. However, the current definition
-introduces an incompatible change where the cv-qualification of the
-parameter type is retained. The deduced type should loose such
-cv-qualification, as pass-by-value does.
+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 20.4.7 [meta.trans.other] change the last sentence:
-</p>
-
-<blockquote><p>
-Otherwise the  member typedef <tt>type</tt> equals <tt><ins>remove_cv&lt;</ins>U<ins>&gt;::type</ins></tt>.
-</p></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-In 20.3.1.2 [tuple.creation]/1 change:
+Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with:
 </p>
 
-<blockquote><p>
-<del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&amp;</tt> if, for the
-corresponding type <tt>Ti</tt> in <tt>Types</tt>,
-<tt>remove_cv&lt;remove_reference&lt;Ti&gt;::type&gt;::type</tt> equals
-<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
-<tt>decay&lt;Ti&gt;::type</tt>.</del>
-<ins>Let <tt>Ui</tt> be <tt>decay&lt;Ti&gt;::type</tt> for each
-<tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt>
-is <tt>X&amp;</tt> if <tt>Ui</tt> equals
-<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
-<tt>Ui</tt>.</ins>
-</p></blockquote>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the
+low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin,
+end)</tt>
+in ascending order of significance to make a (possibly very large) unsigned
+binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the
+following
+algorithm:
+</p>
 
+<blockquote><pre>for( v.clear(); n &gt; 0; n -= 32 )
+   v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
+</pre></blockquote>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
+<p><b>Section:</b> 20.3 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-02-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16
-and <tt>make_tuple()</tt> in 20.3.1.2 [tuple.creation].
-<tt>make_tuple()</tt> detects the presence of
-<tt>reference_wrapper&lt;X&gt;</tt> arguments and "unwraps" the reference in
-such cases. <tt>make_pair()</tt> would OTOH create a
-<tt>reference_wrapper&lt;X&gt;</tt> member. I suggest that the two
-functions are made to behave similar in this respect to minimize
-confusion.
+Classes with trivial special member functions are inherently more
+efficient than classes without such functions.  This efficiency is
+particularly pronounced on modern ABIs that can pass small classes
+in registers.  Examples include value classes such as complex numbers
+and floating-point intervals.  Perhaps more important, though, are
+classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>.  When the
+parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
+themselves can be trivial, leading to substantial performance wins.
+</p>
+<p>
+The current working draft make specification of trivial functions
+(where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
+As long as the semantics of defaulted and deleted functions match
+the intended semantics, specification of defaulted and deleted
+functions will yield more efficient programs.
 </p>
-
-
-<p><b>Proposed resolution:</b></p>
 <p>
-In 20.2 [utility] change the synopsis for make_pair() to read
+There are at least two cases where specification of an explicitly
+defaulted function may be desirable.
+</p>
+<p>
+First, the <tt>std::pair</tt> template has a non-trivial default constructor,
+which prevents static initialization of the pair even when the
+types are statically initializable.  Changing the definition to
 </p>
 
-<blockquote><pre>template &lt;class T1, class T2&gt;
-  pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>, <del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt; make_pair(T1&amp;&amp;, T2&amp;&amp;);
+<blockquote><pre>pair() = default;
 </pre></blockquote>
 
 <p>
-In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
-Then change the 20.2.3 [pairs]/17 to:
+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>
-<i>Returns:</i> <tt>pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>,<del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt;(forward&lt;T1&gt;(x),forward&lt;T2&gt;(y))</tt> <ins>where <tt>V1</tt> and
-<tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be
-<tt>decay&lt;Ti&gt;::type</tt> for each <tt>Ti</tt>. Then each
-<tt>Vi</tt> is <tt>X&amp;</tt> if <tt>Ui</tt> equals
-<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
-<tt>Ui</tt>.</ins>
+** Does the committee confirm that forced value initialization
+was the intent?  If not, does the committee wish to change the
+behavior of <tt>std::pair</tt> in C++0x?
+</p>
+<p>
+Second, the same default constructor issue applies to <tt>std::tuple</tt>.
+Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
+which effectively prevents passing it in registers.  To enable
+passing <tt>tuples</tt> in registers, the copy constructor should be
+make explicitly <tt>default</tt>ed.  The new declarations are:
 </p>
-</blockquote>
-
-
 
+<blockquote><pre>tuple() = default;
+tuple(const tuple&amp;) = default;
+</pre></blockquote>
 
+<p>
+This changes is not implementation neutral.  In particular, it
+prevents implementations based on pointers to the parameter
+types.  It does however, permit implementations using the
+parameter types as bases.
+</p>
+<p>
+** How does the committee wish to trade implementation
+efficiency versus implementation flexibility?
+</p>
 
+<p><i>[
+Bellevue:
+]</i></p>
 
-<hr>
-<h3><a name="707"></a>707. null pointer constant for <tt>exception_ptr</tt></h3>
-<p><b>Section:</b> 18.7.1 [exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-07-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
 
+<blockquote>
 <p>
-From the Toronto Core wiki:
+General agreement; the first half of the issue is NAD.
 </p>
-
 <p>
-What do you mean by "null pointer constant"? How do you guarantee that
-<tt>exception_ptr() == 1</tt> doesn't work? &nbsp;Do you even want to prevent that?
-What's the semantics? &nbsp;What about <tt>void *p = 0; exception_ptr() == p</tt>?
-Maybe disallow those in the interface, but how do you do that with
-portable C++? Could specify just "make it work".
+Before voting on the second half, it was agreed that a "Strongly Favor"
+vote meant support for trivial tuples (assuming usual requirements met),
+even at the expense of other desired qualities. A "Weakly Favor" vote
+meant support only if not at the expense of other desired qualities.
 </p>
-
 <p>
-Peter's response:
+Concensus: Go forward, but not at expense of other desired qualities.
 </p>
-
 <p>
-null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it
-work", can be implemented as assignment operator taking a unique pointer
-to member, as in the unspecified bool type idiom.
+It was agreed to Alisdair should fold this work in with his other
+pair/tuple action items, above, and that issue 801 should be "open", but
+tabled until Alisdair's proposals are disposed of.
 </p>
-
+</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
@@ -12118,304 +16000,534 @@ to member, as in the unspecified bool type idiom.
 
 
 <hr>
-<h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3>
-<p><b>Section:</b> 22 [localization] <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-07-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</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#Open">Open</a>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2008-02-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The POSIX "Extended API Set Part 4,"
+<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><p>
-<a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
-</p></blockquote>
 <p>
-introduces extensions to the C locale mechanism that
-allow multiple concurrent locales to be used in the same application
-by introducing a type <tt>locale_t</tt> that is very similar to
-<tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it.
+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>
-The global locale (set by setlocale) is now specified to be per-
-process. If a thread does not call <tt>uselocale</tt>, the global locale is
-in effect for that thread. It can install a per-thread locale by
-using <tt>uselocale</tt>.
+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>
-There is also a nice <tt>querylocale</tt> mechanism by which one can obtain
-the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined
-locales, with no <tt>std::locale</tt> equivalent.
+Here's how the description would read
 </p>
+<blockquote>
 <p>
-<tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt>
-mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>.
+26.4.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
+</p>
+
+<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>
+Discussion:
+</p>
+<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>
+The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely
+ repack it.
+</p>
+<p>
+ Response: So what?  Consider the seed string "ABC".  The
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
+ proposal results in
+</p>
+<blockquote><pre>v = { 0x3, 0x434241 };
+</pre></blockquote>
+<p>
+while the simplified proposal yields
+</p>
+<blockquote><pre>v = { 0x41, 0x42, 0x43 };
+</pre></blockquote>
+<p>
+The results produced by <tt>seed_seq::generate</tt> with the two inputs are
+different but nevertheless equivalently "mixed up" and this remains
+true even if the seed string is long.
+</p>
+</li>
+<li>
+<p>
+With long strings (e.g., with bit-length comparable to the number of
+ bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified
+ proposal and <tt>seed_seq::generate</tt> will be slower.
+</p>
+<p>
+Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will
+ be a big issue.  If it is, the user is free to repack the seed vector
+ before constructing <tt>seed_seq</tt>.
+</p>
+</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>
+Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>.
 </p>
 
 <p><i>[
-Kona (2007): Bill and Nick to provide wording.
+Bellevue:
 ]</i></p>
 
 
+<blockquote>
+Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
+</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
+Change 26.4.7.1 [rand.util.seedseq]:
+</p>
+
+<blockquote>
+<pre>template&lt;class InputIterator<del>, 
+  size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
+  seed_seq(InputIterator begin, InputIterator end);
+</pre>
+<blockquote>
+<p>
+-5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1)
+such that <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt> shall denote an integral type.
+</p>
+<p>
+-6- Constructs a <tt>seed_seq</tt> object by <del>rearranging some or all of the bits of the supplied sequence
+<tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
+</p>
+<p>
+<del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end
+- begin</tt> elements of the supplied sequence and concatenate all the
+extracted bits to initialize a single (possibly very large) unsigned
+binary number, <tt>b = &#8721;<sup>n-1</sup><sub>i=0</sub> (begin[i] 
+mod 2<sup>u</sup>) · 2<sup>w·i</sup></tt> (in which the bits of each <tt>begin[i]</tt>
+are treated as denoting an unsigned quantity). Then carry out 
+the following algorithm:</del>
 </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>
 
 
 
 
 
 <hr>
-<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3>
-<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</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#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-24</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
+<ol type="A">
+<li>
 <p>
-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>.
+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>
-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].
+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>
-Pete adds:
+The simple fix would be to replace the reference by a pointer member.
 </p>
+</li>
 
-<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>
+<li>
+I would like to give the editorial remark that in both classes the
+constrained <tt>operator=</tt>
+overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
+usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
+parameter the return type would be defined to be <tt>void&amp;</tt> even in otherwise
+valid circumstances - this return type must be explicitly provided (In
+<tt>error_condition</tt> the first declaration uses an explicit value, but of wrong
+type).
+</li>
 
+<li>
+The member function <tt>message</tt> throws clauses (
+19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and
+19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
+although
+they return a <tt>std::string</tt> by value, which might throw in out-of-memory
+conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>).
+</li>
+</ol>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change the signature in 21.1.3.1 [char.traits.specializations.char],
-21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t],
-and 21.1.3.4 [char.traits.specializations.wchar.t] to
+In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
 </p>
 
-<blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c);
-</pre></blockquote>
-
-
+<blockquote>
+<pre>virtual string message(int ev) const = 0;
+</pre>
 
+<blockquote>
+<p>
+<i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>.
+</p>
+<p>
+<del><i>Throws:</i> Nothing.</del>
+</p>
+</blockquote>
+</blockquote>
 
+<p>
+In 19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> synopsis, modifiers section,
+replace the current <tt>operator=</tt> overload by the following:
+</p>
 
+<blockquote>
+<pre>template &lt;class ErrorCodeEnum&gt; 
+  typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value<ins>, error_code</ins>&gt;::type&amp; 
+    operator=(ErrorCodeEnum e);
+</pre>
+</blockquote>
 
-<hr>
-<h3><a name="710"></a>710. Missing postconditions</h3>
-<p><b>Section:</b> 20.6.6.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> 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#New">New</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.
+In the private section of the same class replace the current
+data member <tt>cat_</tt> definition by:
 </p>
 
+<blockquote>
+const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Add to 20.6.6.2.1 [util.smartptr.shared.const]:
+In 19.4.2.2 [syserr.errcode.constructors], change p. 2 to read:
 </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>error_code();
 </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><p>...</p>
+
+<p>
+<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>system_category</tt>.
 </p>
 </blockquote>
 </blockquote>
 
 <p>
-Add to 20.6.6.2.10 [util.smartptr.shared.cast]:
+Change 19.4.2.2 [syserr.errcode.constructors] p. 5 to read:
 </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>error_code(int val, const error_category&amp; cat);
 </pre>
 <blockquote>
+<p>...</p>
 <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>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
 </p>
 </blockquote>
 </blockquote>
 
-<blockquote>
-<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; dynamic_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
-</pre>
-<blockquote>
 <p>
-<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast&lt;T*&gt;(r.get())</tt>.</ins>
+In 19.4.2.3 [syserr.errcode.modifiers], change p. 1 to read:
 </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>void assign(int val, const error_category&amp; cat);
 </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><p>...</p>
+
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
 </p>
 </blockquote>
 </blockquote>
 
 <p>
-Alberto Ganesh Barbati has written an
-<a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a>
-where he suggests (among other things) that the casts be respecified in terms of
-the aliasing constructor as follows:
+In 19.4.2.3 [syserr.errcode.modifiers], change the <tt>operator=</tt> signature to read:
 </p>
 
+<blockquote>
+<pre>template &lt;class ErrorCodeEnum&gt; 
+  typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value<ins>, error_code</ins>&gt;::type&amp; 
+    operator=(ErrorCodeEnum e);
+</pre>
+</blockquote>
+
 <p>
-Change 20.6.6.2.10 [util.smartptr.shared.cast]:
+In 19.4.2.4 [syserr.errcode.observers], change p. 3 to read:
 </p>
 
+<blockquote>
+<pre>const error_category&amp; category() const;
+</pre>
 <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><p>...</p>
+
+<p>
+<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
 </p>
 </blockquote>
+</blockquote>
 
-<blockquote>
 <p>
--6- <i>Returns:</i>
+In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
 </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>
+<blockquote>
+<pre>string message() const;
+</pre>
+<blockquote>
+<p>
+</p><p>...</p>
+
 <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>
+<del><i>Throws:</i> Nothing.</del>
 </p>
 </blockquote>
+</blockquote>
 
 <p>
-This takes care of the missing postconditions for the casts by bringing
-in the aliasing constructor postcondition "by reference".
+In 19.4.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt>
+synopsis, constructors section, replace the template constructor
+overload declaration by one with an added "::value"
 </p>
 
+<blockquote>
+<pre>template &lt;class ErrorConditionEnum&gt;
+  error_condition(ErrorConditionEnum e,
+    typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;<ins>::value</ins>&gt;::type* = 0);
+</pre>
+</blockquote>
 
+<p>
+In 19.4.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt> synopsis,
+modifiers section,
+replace the <tt>operator=</tt> overload declaration by:
+</p>
 
+<blockquote>
+<pre>template&lt;typename ErrorConditionEnum&gt; 
+  typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;<ins>::value</ins>, <del>error_code</del> <ins>error_condition</ins>&gt;::type &amp; 
+     operator=( ErrorConditionEnum e );
+</pre>
+</blockquote>
 
+<p>
+In the private section of the same class replace the current
+data member <tt>cat_</tt> definition by:
+</p>
 
+<blockquote><pre>const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
+</pre></blockquote>
 
-<hr>
-<h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.6.6.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-A discussion on
-<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
-has identified a contradiction in the <tt>shared_ptr</tt> specification.
-The note:
+In 19.4.3.2 [syserr.errcondition.constructors], change p. 2 to read:
 </p>
 
-<blockquote><p>
-[ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
--end note ]
-</p></blockquote>
+<blockquote>
+<pre>error_condition();
+</pre>
+<blockquote>
+<p>
+</p><p>...</p>
 
 <p>
-after the aliasing constructor
+<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>posix_category</tt>.
 </p>
+</blockquote>
+</blockquote>
 
-<blockquote><pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
-</pre></blockquote>
+<p>
+In the same section, change p. 5 to read:
+</p>
 
+<blockquote>
+<pre>error_condition(int val, const error_category&amp; cat);
+</pre>
+<blockquote>
 <p>
-reflects the intent of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
-to, well, allow the creation of an empty <tt>shared_ptr</tt>
-with a non-NULL stored pointer.
+</p><p>...</p>
+
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
 </p>
+</blockquote>
+</blockquote>
 
 <p>
-This is contradicted by the second sentence in the Returns clause of 20.6.6.2.5 [util.smartptr.shared.obs]:
+In 19.4.3.3 [syserr.errcondition.modifiers], change p. 1 to read:
 </p>
 
 <blockquote>
-<pre>T* get() const;
+<pre>void assign(int val, const error_category&amp; cat);
 </pre>
-<blockquote><p>
-<i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
-</p></blockquote>
+<blockquote>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
+</p>
+</blockquote>
 </blockquote>
 
+<p>
+In the same section replace the current <tt>operator=</tt> overload declaration by:
+</p>
 
+<blockquote>
+<pre>template &lt;class ErrorConditionEnum&gt; 
+  typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value<ins>, error_condition</ins>&gt;::type&amp;
+    operator=(ErrorConditionEnum e);
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-In keeping the N2351 spirit and obviously my preference, change 20.6.6.2.5 [util.smartptr.shared.obs]:
+In 19.4.3.4 [syserr.errcondition.observers], change p. 3 to read:
 </p>
 
 <blockquote>
-<pre>T* get() const;
+<pre>const error_category&amp; category() const;
 </pre>
-<blockquote><p>
-<i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
-</p></blockquote>
-</blockquote>
-
+<blockquote>
 <p>
-Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
+<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
 </p>
+</blockquote>
+</blockquote>
 
 <p>
-Change 20.6.6.2.1 [util.smartptr.shared.const]:
+In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
 </p>
 
 <blockquote>
-<pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
+<pre>string message() const;
 </pre>
 <blockquote>
 <p>
-<ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins>
-</p>
+</p><p>...</p>
+
 <p>
-<del>[ <i>Note:</i> this constructor allows creation of an empty <tt>shared_ptr</tt>
-instance with a non-NULL stored pointer. 
--- <i>end note</i> ]</del>
+<del><i>Throws:</i> Nothing.</del>
 </p>
 </blockquote>
 </blockquote>
@@ -12425,249 +16537,338 @@ 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>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
+<h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
+<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-02-24</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
 <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 complexity of <tt>sort()</tt> is specified as "Approximately <tt>N
-log(N)</tt> (where <tt>N == last - first</tt> ) comparisons on the
-average", with no worst case complicity specified. The intention was to
-allow a median-of-three quicksort implementation, which is usually <tt>O(N
-log N)</tt> but can be quadratic for pathological inputs. However, there is
-no longer any reason to allow implementers the freedom to have a
-worst-cast-quadratic sort algorithm. Implementers who want to use
-quicksort can use a variant like David Musser's "Introsort" (Software
-Practice and Experience 27:983-993, 1997), which is guaranteed to be <tt>O(N
-log N)</tt> in the worst case without incurring additional overhead in the
-average case. Most C++ library implementers already do this, and there
-is no reason not to guarantee it in the standard.
+19.4 [syserr]
 </p>
 
+<blockquote><pre>namespace posix_error {
+  enum posix_errno {
+    address_family_not_supported, // EAFNOSUPPORT
+    ...
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
+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>
+
+
 <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>
+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>
 <p>
-<del><sup>266)</sup>
-If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt>partial_sort()</tt>
-(25.3.1.3) should be used.</del>
+Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
+</p>
+<p>
+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 System error support 19.4 [syserr] as indicated:
+</p>
 
+<blockquote><pre><del>namespace posix_error {</del>
+  enum <del>posix_errno</del> <ins>class errc</ins> {
+    address_family_not_supported, // EAFNOSUPPORT
+    ...
+    wrong_protocol_type, // EPROTOTYPE
+  };
+<del>} // namespace posix_error</del>
 
+template &lt;&gt; struct is_error_condition_enum&lt;<del>posix_error::posix_errno</del> <ins>errc</ins>&gt;
+  : public true_type {}
 
+<del>namespace posix_error {</del>
+  error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
+  error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
+<del>} // namespace posix_error</del>
+</pre></blockquote>
 
-<hr>
-<h3><a name="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>
- <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>Discussion:</b></p>
 <p>
-The complexity for <tt>search_n</tt> (25.1.9 [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
-element in the range more than once.
+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>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change the complexity to "At most (last - first) applications of the corresponding predicate".
+Change System error support 19.4 [syserr] and its subsections:
 </p>
 
 <blockquote>
-<pre>template&lt;class ForwardIterator, class Size, class T&gt; 
-  ForwardIterator 
-    search_n(ForwardIterator first , ForwardIterator last , Size count , 
-             const T&amp; value ); 
+<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>
 
-template&lt;class ForwardIterator, class Size, class T, 
-         class BinaryPredicate&gt; 
-  ForwardIterator 
-    search_n(ForwardIterator first , ForwardIterator last , Size count , 
-             const T&amp; value , BinaryPredicate pred );
-</pre>
-<blockquote>
 <p>
-<i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate
-<del>if <tt>count</tt> is positive, or 0 otherwise</del>.
+Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2:
 </p>
-</blockquote>
-</blockquote>
-
-
-
-
 
+<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>
 
-<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#New">New</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</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).
+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 25.3.7 [alg.min.max] to:
+Change 19.4.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
 </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>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
 </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 <tt>i</tt> in <tt>[first,
-last)</tt> such that no other element in the range is smaller,</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
-<tt>i</tt> in <tt>[first, last)</tt> such that no other element in the
-range is larger</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>
+<i>Returns:</i> <tt>error_condition(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
 </blockquote>
 </blockquote>
 
 
 
+<p><b>Rationale:</b></p>
+<table border="1">
+<tbody><tr>
+<th colspan="2">Names Considered</th>
+</tr>
+
+<tr>
+<td><tt>portable</tt></td>
+<td>
+Too non-specific. Did not wish to reserve such a common word in
+namespace std. Not quite the right meaning, either.
+</td>
+</tr>
+
+<tr>
+<td><tt>portable_error</tt></td>
+<td>
+Too long. Explicit qualification is always required for scoped enums, so
+a short name is desirable. Not quite the right meaning, either. May be
+misleading because <tt>*_error</tt> in the std lib is usually an exception class
+name.
+</td>
+</tr>
+
+<tr>
+<td><tt>std_error</tt></td>
+<td>
+Fairly short, yet explicit. But in fully qualified names like
+<tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not
+quite the right meaning, either. May be misleading because <tt>*_error</tt> in
+the std lib is usually an exception class name.
+</td>
+</tr>
+
+<tr>
+<td><tt>generic</tt></td>
+<td>
+Short enough. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in
+namespace std seems dicey.
+</td>
+</tr>
+
+<tr>
+<td><tt>generic_error</tt></td>
+<td>
+Longish. The category could be <tt>generic_category</tt>. Fully qualified names
+like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because
+<tt>*_error</tt> in the std lib is usually an exception class name.
+</td>
+</tr>
+
+<tr>
+<td><tt>generic_err</tt></td>
+<td>
+A bit less longish. The category could be <tt>generic_category</tt>. Fully
+qualified names like <tt>std::generic_err::not_enough_memory</tt> read well.
+</td>
+</tr>
+
+<tr>
+<td><tt>gen_err</tt></td>
+<td>
+Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::gen_err::not_enough_memory</tt> read well.
+</td>
+</tr>
+
+<tr>
+<td><tt>generr</tt></td>
+<td>
+Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::generr::not_enough_memory</tt> read well.
+</td>
+</tr>
+
+<tr>
+<td><tt>error</tt></td>
+<td>
+Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use
+this general a name?
+</td>
+</tr>
+
+<tr>
+<td><tt>err</tt></td>
+<td>
+Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::err::not_enough_memory</tt> read well. Although alone it
+looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names,
+it seems fairly intuitive.
+Problem: <tt>err</tt> is used throughout the standard library as an argument name
+and in examples as a variable name; it seems too confusing to add yet
+another use of the name.
+</td>
+</tr>
+
+<tr>
+<td><tt>errc</tt></td>
+<td>
+Short enough. The "c" stands for "constant". The category could be
+<tt>generic_category</tt>. Fully qualified names like
+<tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a
+name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly
+intuitive. There are no uses of <tt>errc</tt> in the current C++ standard.
+</td>
+</tr>
+</tbody></table>
+
+
 
 
 
 <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>
+<h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
+<p><b>Section:</b> 20.6.11.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-03-13</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
+<tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
 </p>
 
 <blockquote>
-<p>
-The following productions within the ECMAScript grammar are modified as follows:
-</p>
-
-<blockquote><pre>CharacterClass ::
-[ [lookahead &#8713; {^}] ClassRanges ]
-[ ^ ClassRanges ]
-</pre></blockquote>
-
+<i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
 </blockquote>
 
 <p>
-This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
+There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the
+deleter is called with a NULL pointer, and this is probably not what's
+intended (the destructor avoids calling the deleter with 0.)
 </p>
 
 <p>
-Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
+Two, the special check for <tt>get() == p</tt> is generally not needed and such a
+situation usually indicates an error in the client code, which is being
+masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
+self-resets in 2001 and there were no complaints.
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Remove this mention of the CharacterClass production.
+One might think that self-resets are necessary for operator= to work; it's specified to perform
 </p>
 
-<blockquote><pre><del>CharacterClass ::
-[ [lookahead &#8713; {^}] ClassRanges ]
-[ ^ ClassRanges ]</del>
+<blockquote><pre>reset( u.release() );
 </pre></blockquote>
 
+<p>
+and the self-assignment
+</p>
 
+<blockquote><pre>p = move(p);
+</pre></blockquote>
 
-
-
-
-<hr>
-<h3><a name="717"></a>717. Incomplete <tt>valarray::operator[]</tt> specification in [valarray.access]</h3>
-<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been
-changed to <tt>const T&amp;</tt> as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> several paragraphs of
-the section 26.5.2.3 [valarray.access] are now
-incompletely
-specified, because many requirements and guarantees should now also
-apply to the const overload. Most notably, the address and reference
-guarantees should be extended to the const overload case.
+might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
+performed first, zeroing the stored pointer. In other words, <tt>p.reset(
+q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
+is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
+scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
 </p>
 
 
+
 <p><b>Proposed resolution:</b></p>
-<p>
-Change 26.5.2.3 [valarray.access]:
-</p>
 
-<blockquote>
 <p>
--1- <del>When applied to a constant array, the subscript operator returns a
-reference to the corresponding element of the array. When applied to a
-non-constant array, t</del><ins>T</ins>he subscript operator returns a
-reference to the corresponding element of the array.
+Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
 </p>
 
-<p>
--3- The expression <tt>&amp;a[i+j] == &amp;a[i] + j</tt> evaluates as <tt>true</tt> for all <tt>size_t i</tt>
-and <tt>size_t j</tt> such that <tt>i+j</tt> is less 
-than the length of the <del>non-constant</del> array <tt>a</tt>.
-</p>
+<blockquote>
+<pre>void reset(T* p = 0);
+</pre>
+<blockquote>
+-4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+</blockquote>
+</blockquote>
 
 <p>
--4- Likewise, the expression <tt>&amp;a[i] != &amp;b[j]</tt> evaluates
-as <tt>true</tt> for any two <del>non-constant</del> arrays <tt>a</tt> and
-<tt>b</tt> and for any <tt>size_t i</tt> and <tt>size_t j</tt> such that
-<tt>i</tt> is less than the length of <tt>a</tt> and <tt>j</tt> is less
-than the length of <tt>b</tt>. This property indicates an absence of
-aliasing and may be used to advantage by optimizing
-compilers.<sup>281)</sup>
+Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
 </p>
 
+<blockquote>
+<pre>void reset(T* p = 0);
+</pre>
+<blockquote>
+<p>...</p>
 <p>
--5- The reference returned by the subscript operator for a<ins>n</ins> <del>non-constant</del> array is guaranteed to be valid until
-the member function <tt>resize(size_t, T)</tt> (26.5.2.7) is called for that array or until the lifetime 
-of that array ends, whichever happens first.
+-2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
 </p>
-
+</blockquote>
 </blockquote>
 
 
@@ -12676,161 +16877,108 @@ of that array ends, whichever happens first.
 
 
 <hr>
-<h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3>
-<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-18</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>
+<h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
+<p><b>Section:</b> 20.3.1.2 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-13</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Paragraph 21.3 [basic.string]/3 states:
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors.  I believe the same throws clause
+should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
 </p>
 
-<blockquote>
-<p>
-The class template <tt>basic_string</tt> conforms to the requirements for a 
-Sequence (23.1.1) and for a Reversible Container (23.1).
-</p>
-</blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-First of all, 23.1.1 [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.
+Add to 20.3.1.2 [tuple.cnstr]:
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
 <p>
-Remove this sentence, in recognition of the fact that <tt>basic_string</tt> is 
-not just a <tt>vector</tt>-light for literal types, but something quite 
-different, a string abstraction in its own right.
+For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
+or assignment of one of the types in <tt>Types</tt> throws an exception.
 </p>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="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#New">New</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>
+<h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
+<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-13</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
-a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
+p4 (forward) says:
 </p>
-
 <blockquote>
-<p>
--11- A type is a <i>literal</i> type if it is:
-</p>
-<ul>
-<li>a scalar type; or</li>
-<li><p>a class type (clause 9) with</p>
-<ul>
-<li>a trivial copy constructor,</li>
-<li>a trivial destructor,</li>
-<li>at least one constexpr constructor other than the copy constructor,</li>
-<li>no virtual base classes, and</li>
-<li>all non-static data members and base classes of literal types; or</li>
-</ul>
-</li>
-<li>an array of literal type.</li>
-</ul>
+<i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
 </blockquote>
 
 <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:
+First of all, lvalue-ness and rvalue-ness are properties of an expression,
+not of a type (see 3.10 [basic.lval]).  Thus, the phrasing "Return type" is wrong.
+Second, the phrase says exactly what the core language wording says for
+folding references in 14.3.1 [temp.arg.type]/p4  and for function return values
+in 5.2.2 [expr.call]/p10.  (If we feel the wording should be retained, it should
+at most be a note with cross-references to those sections.)
 </p>
-
-<ol type="a">
-<li>To keep the traits in sync with existing types.</li>
-<li>I see many reasons for programmers to use this trait in template
-   code to provide optimized template definitions for these types,
-   see below.</li>
-<li>A user-provided definition of this trait is practically impossible
-to write portably.</li>
-</ol>
-
 <p>
-The special problem of reason (c) is that I don't see currently a
-way to portably test the condition for literal class types:
+The prose after the example talks about "forwarding as an <tt>int&amp;</tt> (an lvalue)" etc.
+In my opinion, this is a category error:  "<tt>int&amp;</tt>" is a type, "lvalue" is a
+property of an expression, orthogonal to its type.  (Btw, expressions cannot
+have reference type, ever.)
+</p>
+<p>
+Similar with move:
 </p>
-
 <blockquote>
-<ul>
-<li>at least one constexpr constructor other than the copy constructor,</li>
-</ul>
+Return type: an rvalue.
 </blockquote>
-
 <p>
-Here follows a simply example to demonstrate it's usefulness:
+is just wrong and also redundant.
 </p>
 
-<blockquote><pre>template &lt;typename T&gt;
-constexpr typename std::enable_if&lt;std::is_literal&lt;T&gt;::value, T&gt;::type
-abs(T x) {
-  return x &lt; T() ? -x : x;
-}
-
-template &lt;typename T&gt;
-typename std::enable_if&lt;!std::is_literal&lt;T&gt;::value, T&gt;::type
-abs(const T&amp; x) {
-  return x &lt; T() ? -x : x;
-}
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-Here we have the possibility to provide a general <tt>abs</tt> function
-template that can be used in ICE's if it's argument is a literal
-type which's value is a constant expression, otherwise we
-have an optimized version for arguments which are expensive
-to copy and therefore need the usage of arguments of
-reference type (instead of <tt>const T&amp;</tt> we could decide to
-use <tt>T&amp;&amp;</tt>, but that is another issue).
+Change 20.2.2 [forward] as indicated:
 </p>
 
+<blockquote>
+<pre>template &lt;class T&gt; T&amp;&amp; forward(typename identity&lt;T&gt;::type&amp;&amp; t);
+</pre>
 
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+<p>...</p>
 <p>
-In 20.4.2 [meta.type.synop] in the group "type properties",
-just below the line
+<del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
 </p>
-
-<blockquote><pre>template &lt;class T&gt; struct is_pod;
-</pre></blockquote>
-
+<p>...</p>
 <p>
-add a new one:
+-7- In the first call to <tt>factory</tt>, <tt>A1</tt> is deduced as <tt>int</tt>, so 2 is forwarded to <tt>A</tt>'s constructor
+as <del>an <tt>int&amp;&amp;</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
+as <tt>int&amp;</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&amp;</tt> (</del>an lvalue<del>)</del>.
+In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as
+<del><tt>double&amp;&amp;</tt> (</del>an rvalue<del>)</del>.
 </p>
+</blockquote>
 
-<blockquote><pre>template &lt;class T&gt; struct is_literal;
-</pre></blockquote>
+<pre>template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp; t);
+</pre>
 
+<blockquote>
+<p>...</p>
 <p>
-In 20.4.4.3 [meta.unary.prop], table Type Property Predicates, just
-below the line for the <tt>is_pod</tt> property add a new line:
+<del><i>Return type:</i>  an rvalue.</del>
 </p>
+</blockquote>
 
-<table border="1">
-<tbody><tr>
-<th>Template</th><th>Condition</th><th>Preconditions</th>
-</tr>
-<tr>
-<td><tt>template &lt;class T&gt; struct is_literal;</tt></td>
-<td><tt>T</tt> is a literal type (3.9)</td>
-<td><tt>T</tt> shall be a complete type, an
-array of unknown bound, or
-(possibly cv-qualified) <tt>void</tt>.</td>
-</tr>
-</tbody></table>
+</blockquote>
 
 
 
@@ -12838,512 +16986,476 @@ 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#New">New</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>
+<h3><a name="809"></a>809. std::swap should be overloaded for array types</h3>
+<p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-02-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-<ol>
-<li>
-The member function <tt>bool array&lt;T,N&gt;::empty() const</tt> should be a
-<tt>constexpr</tt> because this is easily to proof and to implement following it's operational
-semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>.
-</li>
-<li>
-The member function <tt>bool bitset&lt;N&gt;::test() const</tt> must be a
-<tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
-bitset&lt;N&gt;::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
-</li>
-<li>
-I wonder how the constructor <tt>bitset&lt;N&gt;::bitset(unsigned long)</tt> can
-be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
-c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
-non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
-initialisation. What have I overlooked here?
-</li>
-</ol>
-
-
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>In the class template definition of 23.2.1 [array]/p. 3 change</p>
-<blockquote><pre><ins>constexpr</ins> bool empty() const;
-</pre></blockquote>
-</li>
-
-<li>
-<p>In the class template definition of 23.3.5 [template.bitset]/p. 1 change</p>
-<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
-</pre></blockquote>
-
 <p>
-and in 23.3.5.2 [bitset.members] change
-</p>
-
-<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
-</pre></blockquote>
-
-</li>
-</ol>
+For the sake of generic programming, the header <code>&lt;algorithm&gt;</code> should provide an
+overload of <code>std::swap</code> for array types:
+</p><pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
+</pre>
 
 
+<p>
+It became apparent to me that this overload is missing, when I considered how to write a swap
+function for a generic wrapper class template.
+(Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.)
+Please look at the following template, <code>W</code>, and suppose that is intended to be a very
+<em>generic</em> wrapper:
+</p><pre>template&lt;class T&gt; class W {
+public:
+   T data;
+};
+</pre>
+Clearly <code>W&lt;T&gt;</code> is <em>CopyConstructible and CopyAssignable</em>, and therefore
+<em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>.
+Moreover, <code>W&lt;T&gt;</code> is <em>also</em> Swappable when <code>T</code> is an array type
+whose element type is CopyConstructible and CopyAssignable.
+Still it is recommended to add a <em>custom</em> swap function template to such a class template,
+for the sake of efficiency and exception safety.
+(E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
+swap</em>.)
+This function template is typically written as follows:
+<pre>template&lt;class T&gt; void swap(W&lt;T&gt;&amp; x, W&lt;T&gt;&amp; y) {
+  using std::swap;
+  swap(x.data, y.data);
+}
+</pre>
+Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array.
+For instance, <code>W&lt;std::string[8]&gt;</code> is Swappable, but the current Standard does not
+allow calling the custom swap function that was especially written for <code>W</code>!
+<pre>W&lt;std::string[8]&gt; w1, w2;  // Two objects of a Swappable type.
+std::swap(w1, w2);  // Well-defined, but inefficient.
+using std::swap;
+swap(w1, w2);  // Ill-formed, just because ADL finds W's swap function!!!
+</pre>
 
+<code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array,
+<code>std::string[8]</code>, which is not supported by the Standard Library.
+This issue is easily solved by providing an overload of <code>std::swap</code> for array types.
+This swap function should be implemented in terms of swapping the elements of the arrays, so that
+it would be non-throwing for arrays whose element types have a non-throwing swap.
 
 
-<hr>
-<h3><a name="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3>
-<p><b>Section:</b> 22.1.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-27</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-Paragraph 3 says that the <tt>Codecvt</tt> template parameter shall meet the 
-requirements of <tt>std::codecvt</tt>, even though <tt>std::codecvt</tt> itself cannot 
-be used (because of a protected destructor).
+Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
+arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
+means of recursion.
 </p>
 
 <p>
-How are we going to explain this code to beginning programmers?
+For your information, there was a discussion on this issue at comp.lang.c++.moderated: <a href="http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9341ebd3635c9c74">[Standard
+Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
 </p>
 
-<blockquote><pre>template&lt;class I, class E, class S&gt;
-struct codecvt : std::codecvt&lt;I, E, S&gt;
-{
-    ~codecvt()
-    { }
-};
-
-void main()
-{
-    std::wstring_convert&lt;codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt; compiles_ok;
-    
-    std::wstring_convert&lt;std::codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt;   not_ok;
-}
-</pre></blockquote>
-
-
 
 <p><b>Proposed resolution:</b></p>
 <p>
+Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]:
 </p>
+<blockquote>
+- <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>.
+</blockquote>
+<p>
+Add the following to 25.2.3 [alg.swap]:
+</p>
+<blockquote>
+<pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
+</pre>
+<blockquote>
+<i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>.
+</blockquote>
+<blockquote>
+<i>Effects:</i> <code>swap_ranges(a, a + N, b);</code>
+</blockquote>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>
+<h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
+<p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-03-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-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):
+The recent draft (as well as the original proposal n2072) uses an
+operational semantic
+for <tt>get_money</tt> ([ext.manip]/3) and <tt>put_money</tt> ([ext.manip]/5), which uses
 </p>
 
-<blockquote><pre>float nanf(const char *tagp);
-long double nanl(const char *tagp);
+<blockquote><pre>istreambuf_iterator&lt;charT&gt;
 </pre></blockquote>
 
 <p>
-(Note: These functions cannot be overloaded and they are also not
-listed anywhere else)
+and
 </p>
 
+<blockquote><pre>ostreambuf_iterator&lt;charT&gt;
+</pre></blockquote>
 
-<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>.
+resp, instead of the iterator instances, with explicitly provided
+traits argument (The operational semantic defined by <tt>f</tt> is also traits
+dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
+c'tors expect a <tt>basic_streambuf&lt;charT,traits&gt;</tt> as argument.
 </p>
-
-
-
-
-
-<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>
- <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>Discussion:</b></p>
 <p>
-According to the current state of the standard draft, the class
-template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
-neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
-IMO it should be, because typical regex state machines tend
-to have a rather large data quantum and I have seen several
-use cases, where a factory function returns regex values,
-which would take advantage of moveabilities.
+The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic (p.
+7 and p. 9)
+of n2071 incorporated in N2521, where additional to the problem we
+have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
+<tt>istreambuf_iterator</tt>).
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
-<ol type="a">
-<li>
 <p>
-In the header <tt>&lt;regex&gt;</tt> synopsis 28.4 [re.syn], just below the function
-template <tt>swap</tt> add two further overloads:
+In 27.6.4 [ext.manip]/3 within function <tt>f</tt> replace the first line
 </p>
-<blockquote><pre>template &lt;class charT, class traits&gt; 
-  void swap(basic_regex&lt;charT, traits&gt;&amp; e1,  basic_regex&lt;charT, traits&gt;&amp; e2);
-<ins>template &lt;class charT, class traits&gt;
-  void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
-template &lt;class charT, class traits&gt;
-  void swap(basic_regex&lt;charT, traits&gt;&amp; e1,  basic_regex&lt;charT, traits&gt;&amp;&amp; e2);</ins>
+
+<blockquote><pre>template &lt;class charT, class traits, class moneyT&gt; 
+void f(basic_ios&lt;charT, traits&gt;&amp; str, moneyT&amp; mon, bool intl) { 
+   typedef istreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
+   ...
 </pre></blockquote>
+
 <p>
-In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
-perform the following changes:
+In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter:
 </p>
-</li>
 
-<li>
-<p>Just after the copy c'tor:</p>
-<blockquote><pre>basic_regex(basic_regex&amp;&amp;);
+<blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false<ins>)</ins>;
 </pre></blockquote>
-</li>
 
-<li>
-<p>Just after the copy-assignment op.:</p>
-<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
-</pre></blockquote>
-</li>
+<p>
+In 27.6.4 [ext.manip]/5 within function <tt>f</tt> replace the first line
+</p>
 
-<li>
-<p>Just after the first <tt>assign</tt> overload insert:</p>
-<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
+<blockquote><pre>template &lt;class charT, class traits, class moneyT&gt; 
+void f(basic_ios&lt;charT, traits&gt;&amp; str, const moneyT&amp; mon, bool intl) { 
+  typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
+  ...
 </pre></blockquote>
-</li>
 
-<li>
-<p>Change the current <tt>swap</tt> function to read:</p>
-<blockquote><pre>void swap(basic_regex&amp;&amp;);
-</pre></blockquote>
-</li>
+<p>
+In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line
+</p>
 
-<li>
-<p>In 28.8.2 [re.regex.construct], just below the copy c'tor add a
-corresponding member definition of:</p>
-<blockquote><pre>basic_regex(basic_regex&amp;&amp;);
+<blockquote><pre>template &lt;class charT, class traits&gt; 
+void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm *tmb, const charT *fmt) { 
+  typedef <ins>i</ins>streambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
+  ...
 </pre></blockquote>
-</li>
 
-<li>
-<p>Also in 28.8.2 [re.regex.construct], just below the copy assignment
-c'tor add a corresponding member definition of:</p>
-<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
-</pre></blockquote>
-</li>
+<p>
+In 27.6.4 [ext.manip]/8 add const:
+</p>
 
-<li>
-<p>In 28.8.3 [re.regex.assign], just below the first <tt>assign</tt> overload add
-a corresponding member definition of:</p>
-<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
+<blockquote><pre>template &lt;class charT&gt; unspecified put_time(<ins>const</ins> struct tm *tmb, const charT *fmt);
 </pre></blockquote>
-</li>
 
-<li>
-<p>In 28.8.6 [re.regex.swap], change the signature of <tt>swap</tt> to
-say:</p>
-<blockquote><pre>void swap(basic_regex&amp;&amp; e);
-</pre></blockquote>
-</li>
+<p>
+In 27.6.4 [ext.manip]/9 within function <tt>f</tt> replace the first line
+</p>
 
-<li>
-<p>In 28.8.7.1 [re.regex.nmswap], just below the single binary <tt>swap</tt>
-function, add the two missing overloads:</p>
-<blockquote><pre>template &lt;class charT, class traits&gt;
-  void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
-template &lt;class charT, class traits&gt;
-  void swap(basic_regex&lt;charT, traits&gt;&amp; e1, basic_regex&lt;charT, traits&gt;&amp;&amp; e2);
+<blockquote><pre>template &lt;class charT, class traits&gt; 
+void f(basic_ios&lt;charT, traits&gt;&amp; str, const struct tm *tmb, const charT *fmt) { 
+  typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
+  ...
 </pre></blockquote>
-</li>
-</ol>
 
 <p>
-Of course there would be need of corresponding proper standardese
-to describe these additions.
+Add to the <tt>&lt;iomanip&gt;</tt> synopsis in 27.6 [iostream.format]
 </p>
 
+<blockquote><pre>template &lt;class moneyT&gt; unspecified get_money(moneyT&amp; mon, bool intl = false);
+template &lt;class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false);
+template &lt;class charT&gt; unspecified get_time(struct tm *tmb, const charT *fmt);
+template &lt;class charT&gt; unspecified put_time(const struct tm *tmb, const charT *fmt);
+</pre></blockquote>
+
 
 
 
 
 
 <hr>
-<h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
-<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2007-09-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
+<h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
+<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-03-14</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
+<blockquote><pre>#include &lt;utility&gt;
+
+int main()
+{
+   std::pair&lt;char *, char *&gt; p (0,0);
+}
+</pre></blockquote>
+
 <p>
-The <tt>DefaultConstructible</tt> requirement is referenced in
-several places in the August 2007 working draft
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
-but is not defined anywhere.
+I just got a bug report about that, because it's valid C++03, but not
+C++0x. The important realization, for me, is that the emplace
+proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
+issue---didn't cause this break in backward compatibility. The break
+actually happened when we added this pair constructor as part of adding
+rvalue references into the language, long before variadic templates or
+emplace came along:
 </p>
 
+<blockquote><pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-In section 20.1.1 [utility.arg.requirements], before table 33, add the
-following table:
+Now, concepts will address this issue by constraining that <tt>pair</tt>
+constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
+"second", e.g. (from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
 </p>
 
-<p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
-
-<div align="center">
+<blockquote><pre>template&lt;class U , class V &gt;
+requires Constructible&lt;T1, U&amp;&amp;&gt; &amp;&amp; Constructible&lt;T2, V&amp;&amp;&gt;
+pair(U&amp;&amp; x , V&amp;&amp; y );
+</pre></blockquote>
 
-<table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0">
- <tbody><tr>
-  <td style="border-style: solid none double solid; border-color: navy -moz-use-text-color navy navy; border-width: 1pt medium 1.5pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
-  <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p>
-  </td>
-  <td style="border-style: solid solid double none; border-color: navy navy navy -moz-use-text-color; border-width: 1pt 1pt 1.5pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
-  <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p>
-  </td>
- </tr>
- <tr>
-  <td style="border-style: none none solid solid; border-color: -moz-use-text-color -moz-use-text-color navy navy; border-width: medium medium 1pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
-  <p style="margin: 0in 0in 0.0001pt;"><tt>T
-  t;</tt><br>
-  <tt>T()</tt></p>
-  </td>
-  <td style="border-style: none solid solid none; border-color: -moz-use-text-color navy navy -moz-use-text-color; border-width: medium 1pt 1pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
-  <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt>
-  is <i>default constructed.</i></p>
-  </td>
- </tr>
-</tbody></table>
 
-</div>
 
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
 
 
 
 
 
 <hr>
-<h3><a name="725"></a>725. Optional sequence container requirements column label</h3>
-<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> David Abrahams <b>Date:</b> 2007-09-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
+<h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3>
+<p><b>Section:</b> 25.3.1 [alg.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Paul McKenney <b>Date:</b> 2008-02-27</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Table 90: (Optional sequence container operations) states the
-"assertion note pre/post-condition" of <tt>operator[]</tt> to be
+Multi-threading is a good thing, but unsolicited multi-threading can
+potentially be harmful.  For example, <tt>sort()</tt> performance might be
+greatly increased via a multithreaded implementation.  However, such
+a multithreaded implementation could result in concurrent invocations
+of the user-supplied comparator.  This would in turn result in problems
+given a caching comparator that might be written for complex sort keys.
+Please note that this is not a theoretical issue, as multithreaded
+implementations of <tt>sort()</tt> already exist.
 </p>
-
-<blockquote><pre>*(a.begin() + n)
-</pre></blockquote>
-
 <p>
-Surely that's meant to be "operational semantics?"
+Having a multithreaded <tt>sort()</tt> available is good, but it should not
+be the default for programs that are not explicitly multithreaded.
+Users should not be forced to deal with concurrency unless they have
+asked for it.
 </p>
 
+<p><i>[
+This may be covered by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a>
+Thread-Safety in the Standard Library (Rev 1).
+]</i></p>
 
 
-<p><b>Proposed resolution:</b></p>
-<blockquote>
-<table border="1">
-<caption>Table 90: Optional sequence container operations</caption>
-<tbody><tr>
-<th>expression</th> <th>return type</th> <th><del>assertion/note<br>pre/post-condition</del><br> <ins>operational semantics</ins></th> <th>container</th>
-</tr>
-</tbody></table>
-</blockquote>
 
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
 
 
 
 
 
 <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>
- <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>
+<h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
+<p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Matt Austern <b>Date:</b> 2008-02-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Two overloads of <tt>regex_replace()</tt> are currently provided:
+Several places in 20.6.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
+However, that term is nowhere defined. The closest thing we have to a
+definition is that the default constructor creates an empty <tt>shared_ptr</tt>
+and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
+other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
+are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
+term or stop using it.
+</p><p>
 </p>
+One reason it's not good enough to leave this term up to the reader's
+intuition is that, in light of
+<a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
+and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, most readers'
+intuitive understanding is likely to be wrong. Intuitively one might
+expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
+but, whatever the definition is, that isn't it.
 
-<blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator, 
-    class traits, class charT&gt; 
-  OutputIterator 
-  regex_replace(OutputIterator out, 
-                BidirectionalIterator first, BidirectionalIterator last, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const basic_string&lt;charT&gt;&amp; fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
-&nbsp;
-template &lt;class traits, class charT&gt; 
-  basic_string&lt;charT&gt; 
-  regex_replace(const basic_string&lt;charT&gt;&amp; s, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const basic_string&lt;charT&gt;&amp; fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
-</pre></blockquote>
 
-<ol>
-<li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
-<tt>regex_search()</tt>, but not <tt>regex_replace()</tt>.&nbsp; This is inconsistent.</li>
+<p><i>[
+Peter adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Or, what is an "empty" <tt>shared_ptr</tt>?
+</p>
+
+<ul>
+<li>
+<p>
+Are any other <tt>shared_ptrs</tt> empty?
+</p>
+<p>
+Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*)
+completely specified by the last mutating operation on that instance.
+Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or
+not.
+</p>
+<blockquote>
+(*) If it isn't, this is a legitimate defect.
+</blockquote>
+</li>
+
+<li>
+<p>
+For example, is <tt>shared_ptr((T*) 0)</tt> empty?
+</p>
+<p>
+No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is
+specified to have an <tt>use_count()</tt> of 1.
+</p>
+</li>
+
+<li>
+<p>
+What are the properties of an empty <tt>shared_ptr</tt>?
+</p>
+<p>
+The properties of an empty <tt>shared_ptr</tt> can be derived from the
+specification. One example is that its destructor is a no-op. Another is
+that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you
+really like.
+</p>
+</li>
+
+<li>
+<p>
+We should either clarify this term or stop using it.
+</p>
+<p>
+I don't agree with the imperative tone
+</p>
+<p>
+A clarification would be either a no-op - if it doesn't contradict the
+existing wording - or a big mistake if it does.
+</p>
+<p>
+I agree that a clarification that is formally a no-op may add value.
+</p>
+</li>
+
 <li>
-<p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
-
-<blockquote><pre>const string s("kitten");
-const regex r("en");
-cout &lt;&lt; regex_replace(s, r, "y") &lt;&lt; endl;
+<p>
+However, that term is nowhere defined.
+</p>
+<p>
+Terms can be useful without a definition. Consider the following
+simplistic example. We have a type <tt>X</tt> with the following operations
+defined:
+</p>
+<blockquote><pre>X x;
+X x2(x);
+X f(X x);
+X g(X x1, X x2);
 </pre></blockquote>
-
 <p>
-The compiler error message will be something like "could not deduce
-template argument for 'const std::basic_string&lt;_Elem&gt; &amp;' from 'const
-char[1]'".
+A default-constructed value is green.<br>
+A copy has the same color as the original.<br>
+<tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br>
+<tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise.
 </p>
 
 <p>
-Users expect that anything taking a <tt>basic_string&lt;charT&gt;</tt> can also take a
-<tt>const charT *</tt>.&nbsp; In their own code, when they write a function taking
-<tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
-wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor.&nbsp; Because the
-regex algorithms are templated on <tt>charT</tt>, they can't rely on
-<tt>basic_string</tt>'s implicit constructor (as the compiler error message
-indicates, template argument deduction fails first).
+Given these definitions, you can determine the color of every instance
+of type <tt>X</tt>, even if you have absolutely no idea what green and red mean.
 </p>
 
 <p>
-If a user figures out what the compiler error message means, workarounds
-are available - but they are all verbose.&nbsp; Explicit template arguments
-could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
-constructor to be invoked - but <tt>charT</tt> is the last template argument, not
-the first, so this would be extremely verbose.&nbsp; Therefore, constructing
-a <tt>basic_string</tt> from each C string is the simplest workaround.
+Green and red are "nowhere defined" and completely defined at the same time.
 </p>
 </li>
+</ul>
 
-<li>
-There is an efficiency consideration: constructing <tt>basic_string</tt>s can
-impose performance costs that could be avoided by a library
-implementation taking C strings and dealing with them directly.&nbsp;
-(Currently, for replacement sources, C strings can be converted into
-iterator pairs at the cost of verbosity, but for format strings, there
-is no way to avoid constructing a <tt>basic_string</tt>.)
-</li>
-</ol>
-
+<p>
+Alisdair's wording is fine.
+</p>
+</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Provide additional overloads for <tt>regex_replace()</tt>: one additional
-overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
-additional overloads of the convenience form (one taking <tt>const charT*
-str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
-charT* str</tt> and <tt>const charT* fmt</tt>).  28.11.4 [re.alg.replace]:
+Append the following sentance to 20.6.12.2 [util.smartptr.shared]
 </p>
-
 <blockquote>
-<pre>template &lt;class OutputIterator, class BidirectionalIterator, 
-    class traits, class charT&gt; 
-  OutputIterator 
-  regex_replace(OutputIterator out, 
-                BidirectionalIterator first, BidirectionalIterator last, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const basic_string&lt;charT&gt;&amp; fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
+The <code>shared_ptr</code> class template stores a pointer, usually obtained
+via <code>new</code>. <code>shared_ptr</code> implements semantics of
+shared ownership; the last remaining owner of the pointer is responsible for
+destroying the object, or otherwise releasing  the resources associated with
+the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
+a pointer is said to be <i>empty</i>.</ins>
+</blockquote>
 
-<ins>template &lt;class OutputIterator, class BidirectionalIterator, 
-    class traits, class charT&gt; 
-  OutputIterator 
-  regex_replace(OutputIterator out, 
-                BidirectionalIterator first, BidirectionalIterator last, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const charT* fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);</ins>
-</pre>
-<p>...</p>
-<pre>template &lt;class traits, class charT&gt; 
-  basic_string&lt;charT&gt; 
-  regex_replace(const basic_string&lt;charT&gt;&amp; s, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const basic_string&lt;charT&gt;&amp; fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
 
-<ins>template &lt;class traits, class charT&gt; 
-  basic_string&lt;charT&gt; 
-  regex_replace(const basic_string&lt;charT&gt;&amp; s, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const charT* fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);</ins>
 
-<ins>template &lt;class traits, class charT&gt; 
-  basic_string&lt;charT&gt; 
-  regex_replace(const charT* s, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const basic_string&lt;charT&gt;&amp; fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);</ins>
 
-<ins>template &lt;class traits, class charT&gt; 
-  basic_string&lt;charT&gt; 
-  regex_replace(const charT* s, 
-                const basic_regex&lt;charT, traits&gt;&amp; e, 
-                const charT* fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);</ins>
-</pre>
-</blockquote>
 
+<hr>
+<h3><a name="814"></a>814. <tt>vector&lt;bool&gt;::swap(reference, reference)</tt> not defined</h3>
+<p><b>Section:</b> 23.2.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-17</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>vector&lt;bool&gt;::swap(reference, reference)</tt> has no definition.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
 
 
 
 
 
 <hr>
-<h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
-<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>
+<h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
+<p><b>Section:</b> 20.5.15.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-16</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-<tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string&lt;charT, ST,
-SA&gt;&amp;</tt>.&nbsp; <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</tt>.&nbsp; This prevents
-<tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
-allocators.
+<tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
+described in the rvalue core proposal.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
-templated on <tt>class ST, class SA</tt> and take <tt>const basic_string&lt;charT, ST,
-SA&gt;&amp;</tt>.&nbsp; Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
-<tt>class ST, class SA</tt> as the first template arguments; compatibility with
-existing code using TR1 and giving explicit template arguments to
-<tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
-arguments.
 </p>
 
 
@@ -13351,482 +17463,566 @@ 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#New">New</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3>
+<p><b>Section:</b> 20.5.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-02-08</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given 
-as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization 
-of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate 
-for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in 
-which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M. 
-Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
-[<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-64.c">reference</a>].
+Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt>
+should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
 </p>
-
 <p>
-I see two possible resolutions: 
+However, no guarantees are provided for the copy ctor of the functor
+returned by <tt>bind()</tt>.  (It's guaranteed to have a copy ctor, which can
+throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
+call wrapper, TR1 3.6.3/2.  A forwarding call wrapper is a call wrapper,
+TR1 3.3/4.  Every call wrapper shall be CopyConstructible, TR1 3.3/4. 
+Everything without an exception-specification may throw
+implementation-defined exceptions unless otherwise specified, C++03
+17.4.4.8/3.)
+</p>
+<p>
+Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended
+to cover both calling <tt>bind()</tt> and copying the returned functor?
 </p>
 
-<ol type="a">
-<li>Restrict the parameter <tt>W</tt> of the <tt>mersenne_twister_template</tt> to values of 32 or 64 and use the 
-multiplier from [the above reference] for the 64-bit case (my preference)</li>
-<li>Interpret the state array for any <tt>W</tt> as a 32-bit array of appropriate length (and a specified byte 
-order) and always employ the 32-bit algorithm for seeding
-</li>
-</ol>
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+<tt>tuple</tt> construction should probably have a similar guarantee.
+</blockquote>
+
+
 
+<p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for further discussion.
 </p>
 
 
 
-<p><b>Proposed resolution:</b></p>
 
+
+<hr>
+<h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
+<p><b>Section:</b> 20.5.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-17</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
+<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>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for the proposed resolution.
+The functor retureed by <tt>bind()</tt> should have a move constructor that
+requires only move construction of its contained functor and bound arguments.
+That way move-only functors can be passed to objects such as <tt>thread</tt>.
+</p>
+<p>
+This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>.
 </p>
 
 
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
 
 
 
 
 <hr>
-<h3><a name="729"></a>729. Problem in [rand.req.eng]/3</h3>
-<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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.req.eng">issues</a> in [rand.req.eng].</p>
+<h3><a name="818"></a>818. wording for memory ordering</h3>
+<p><b>Section:</b> 29.1 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-22</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The 3rd table row in 26.4.1.3 [rand.req.eng]/3 requires random number engines to accept any 
-arithmetic type as a seed, which is then casted to the engine's <tt>result_type</tt> and subsequently 
-used for seeding the state of the engine. The requirement stated as "Creates an engine with 
-initial state determined by <tt>static_cast&lt;X::result_type&gt;(s)</tt>" forces random number engines 
-to either use a seeding method that completely depends on the <tt>result_type</tt> (see the discussion 
-of seeding for the <tt>mersenne_twister_engine</tt> in point T2 above) or at least to throw away "bits 
-of randomness" in the seed value if the <tt>result_type</tt> is smaller than the seed type. This seems 
-to be inappropriate for many modern random number generators, in particular F2-linear or 
-cryptographic ones, which operate on an internal bit array that in principle is independent of the 
-type of numbers returned.
+29.1 [atomics.order] p1 says in the table that
 </p>
 
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>Element</th><th>Meaning</th>
+</tr>
+<tr>
+<td><tt>memory_order_acq_rel</tt></td>
+<td>the operation has both acquire and release semantics</td>
+</tr>
+</tbody></table>
+</blockquote>
+
 <p>
-<b>Posible resolution:</b> I propose to change the wording to a version similar to "Creates an 
-engine with initial state determined by <tt>static_cast&lt;UintType&gt;(s)</tt>, where <tt>UintType</tt> is an 
-implementation specific unsigned integer type."
+To my naked eye, that seems to imply that even an atomic read has both
+acquire and release semantics.
 </p>
 
 <p>
-Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
+Then, p1 says in the table:
 </p>
 
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>Element</th><th>Meaning</th>
+</tr>
+<tr>
+<td><tt>memory_order_seq_cst</tt></td>
+<td>the operation has both acquire and release semantics,
+    and, in addition, has sequentially-consistent operation ordering</td>
+</tr>
+</tbody></table>
+</blockquote>
+
 <p>
-Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified.
+So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
+constraints.
 </p>
 
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for further discussion.
+I'm then reading p2, where it says:
 </p>
 
+<blockquote>
+The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
+on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
+are release operations on the affected locations.
+</blockquote>
 
+<p>
+That seems to imply that atomic reads only have acquire semantics.  If that
+is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual
+load/store operations as well?
+</p>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for further discussion.
+Also, the table in p1 contains phrases with "thus" that seem to indicate
+consequences of normative wording in 1.10 [intro.multithread].  That shouldn't be in
+normative text, for the fear of redundant or inconsistent specification with
+the other normative text.
 </p>
 
+<p>
+Double-check 29.4.4 [atomics.types.operations] that each
+operation clearly says whether it's a load or a store operation, or
+both.  (It could be clearer, IMO.  Solution not in current proposed resolution.)
+</p>
 
+<p>
+29.1 [atomics.order] p2:  What's a "consistent execution"?  It's not defined in
+1.10 [intro.multithread], it's just used in notes there.
+</p>
 
+<p>
+And why does 29.4.4 [atomics.types.operations] p9 for "load" say:
+</p>
 
 
+<blockquote>
+<i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt>
+nor <tt>memory_order_acq_rel</tt>.
+</blockquote>
 
-<hr>
-<h3><a name="730"></a>730. Comment on [rand.req.adapt]/3 e)</h3>
-<p><b>Section:</b> 26.4.1.4 [rand.req.adapt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-If an engine adaptor is invoked with an argument of type <tt>seed_seq</tt>, then all base 
-engines are specified to be seeded with this <tt>seed_seq</tt>. As <tt>seed_seq</tt>'s randomization method is 
-qualified as constant, this procedure will ef fectively initialize all base engines with the same seed 
-(though the resulting state might still dif fer to a certain degree if the engines are of different types). 
-It is not clear whether this mode of operation is in general appropriate, hence -- as far as the 
-stated requirements are of general nature and not just specific to the engine adaptors provided by 
-the library -- it might be better to leave the behaviour unspecified, since the current definition of 
-<tt>seed_seq</tt> does not allow for a generally satisfying specification.
+(Since this is exactly the same restriction as for "store", it seems to be a typo.)
 </p>
 
 <p>
-<b>Posssible resolution:</b> [As above]
+And then: 29.4.4 [atomics.types.operations] p12:
 </p>
 
+<blockquote>
+These operations are read-modify-write operations in the sense of the
+"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
+evaluation that produced the input value synchronize with any evaluation
+that reads the updated value.
+</blockquote>
+
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for further discussion.
+This is redundant with 1.10 [intro.multithread], see above for the reasoning.
 </p>
 
 
-
 <p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for the proposed resolution.
+Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of
+1.7 [intro.memory].
+Rephrase the table in as follows (maybe don't use a table):
 </p>
 
+<blockquote>
+<p>
+For <tt>memory_order_relaxed</tt>, no operation orders memory.
+</p>
 
-
-
-
-<hr>
-<h3><a name="731"></a>731. proposal for a customizable <tt>seed_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#New">New</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.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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-The proper way to seed random number engines seems to be the most frequently 
-discussed issue of the 26.4 [rand] proposal. While the new <tt>seed_seq</tt> approach is already rather 
-general and probably sufficient for most situations, it is unlikely to be optimal in every case (one 
-problem was pointed out in point T5 above). In some situations it might, for instance, be better to 
-seed the state with a cryptographic generator. 
+For <tt>memory_order_release</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
+a store operation performs a release operation on the affected memory location.
 </p>
+
 <p>
-In my opinion this is a pretty strong argument for extending the standard with a simple facility to 
-customize the seeding procedure. This could, for example, be done with the following minimal 
-changes:
+For <tt>memory_order_acquire</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
+a load operation performs an acquire operation on the affected memory location.
 </p>
+</blockquote>
 
 <p>
-<b>Possible resolution:</b>
+Rephrase 29.1 [atomics.order] p2:
 </p>
 
-<ol type="a">
-<li>
-Turn the interface specification of 26.4.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the 
-exact behaviour of the constructors and the randomize method are left unspecified and where the
-const qualification for randomize is removed. Classes implementing this interface are additionally 
-required to specialize the traits class in c).
-</li>
-<li>
-Provide the class <tt>seed_seq</tt> as a default implementation of the SeedSeq interface.
-</li>
-<li>
+<blockquote>
+<del>The <tt>memory_order_seq_cst</tt> operations that load a value are
+acquire operations on the affected locations. The
+<tt>memory_order_seq_cst</tt> operations that store a value are release
+operations on the affected locations.</del>
+<del>In addition, in a consistent
+execution, t</del><ins>T</ins>here <del>must be</del> <ins>is</ins> a single
+total order <tt>S</tt> on all
+<tt>memory_order_seq_cst</tt> operations, consistent with the happens before
+order and modification orders for all affected locations, such that each
+<tt>memory_order_seq_cst</tt> operation observes either the last preceding
+modification according to this order <tt>S</tt>, or the result of an operation
+that is not <tt>memory_order_seq_cst</tt>. [<i>Note:</i> Although it is not explicitly
+required that <tt>S</tt> include locks, it can always be extended to an order
+that does include lock and unlock operations, since the ordering between
+those is already included in the happens before ordering. <i>-- end note</i>]
+</blockquote>
+
 <p>
-Supplement the <tt>seed_seq</tt> with a traits class
+Rephrase 29.4.4 [atomics.types.operations] p12 as:
 </p>
-<blockquote><pre>template &lt;typename T&gt; 
-struct is_seed_seq { static const bool value = false; }
-</pre></blockquote>
-<p>and the specialization</p>
-<blockquote><pre>template &lt;&gt; 
-struct is_seed_seq&lt;seed_seq&gt; { static const bool value = true; }
-</pre></blockquote>
-<p>which users can supplement with further specializations.</p>
-</li>
-<li>
-Change 26.4.1.3 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and 
-modify the constructors and seed methods in 26.4.3 [rand.eng] appropriately (the actual implementation 
-could be done using the SFINAE technique).
-</li>
-</ol>
 
+<blockquote>
+<i>Effects:</i> Atomically replaces the value pointed to by object or by
+this with desired. Memory is affected according to the value of order.
+These operations are read-modify-write operations <del>in the sense of the
+"synchronizes with" definition</del> (1.10 [intro.multithread])<del>, so both such an operation and the
+evaluation that produced the input value synchronize with any evaluation
+that reads the updated value</del>.
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for the proposed resolution.
+Same in p15, p20, p22.
 </p>
 
 
 
 
 
+
 <hr>
-<h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3>
-<p><b>Section:</b> 26.4.8.5.3 [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<h3><a name="819"></a>819. rethrow_if_nested</h3>
+<p><b>Section:</b> 18.7.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-25</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is 
-meant to simulate random numbers from any general distribution given only the density and the 
-support of the distribution. I'm not aware of any general purpose algorithm that would be capable 
-of correctly and efficiently implementing the described functionality. From what I know, this is 
-essentially an unsolved research problem. Existing algorithms either require more knowledge 
-about the distribution and the problem domain or work only under very limited circumstances. 
-Even the state of the art special purpose library UNU.RAN does not solve the problem in full 
-generality, and in any case, testing and customer support for such a library feature would be a 
-nightmare.
+Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
+got it quite right.
+</p>
+
+<p>
+The current wording says:
+</p>
+
+<blockquote>
+<pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt>
+is publicly derived from <tt>nested_exception</tt>.
 </p>
+</blockquote>
+</blockquote>
 
 <p>
-<b>Possible resolution:</b> For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
+This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
+derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
+required to be sure.  Unfortunately, if <tt>e</tt> is dynamically but not statically
+derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for the proposed resolution.
-</p>
 
 
 
 
 
 <hr>
-<h3><a name="733"></a>733. Comment on [rand.req.dist]/9</h3>
-<p><b>Section:</b> 26.4.1.5 [rand.req.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
+<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-03-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The requirement "P shall have a declaration of the form <tt>typedef X distribution_- 
-type</tt>" effectively makes the use of inheritance for implementing distributions very inconvenient, 
-because the child of a distribution class in general will not satisfy this requirement. In my opinion 
-the benefits of having a typedef in the parameter class pointing back to the distribution class are 
-not worth the hassle this requirement causes. [In my code base I never made use of the nested 
-typedef but on several occasions could have profited from being able to use simple inheritance for 
-the implementation of a distribution class.]
+As of N2521, the Working Paper appears to be silent about what
+<tt>current_exception()</tt> should do if it tries to copy the currently handled
+exception and its copy constructor throws.  18.7.5 [propagation]/7 says "If the
+function needs to allocate memory and the attempt fails, it returns an
+<tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
+doesn't say anything about what should happen if memory allocation
+succeeds but the actual copying fails.
 </p>
 
 <p>
-<b>Proposed resolution:</b> I propose to drop this requirement.
+I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers
+to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt>
+object that refers to an instance of the copy ctor's thrown exception
+(but if that has a throwing copy ctor, an infinite loop can occur), or
+(3) call <tt>terminate()</tt>.
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for the proposed resolution.
+I believe that <tt>terminate()</tt> is the most reasonable course of action, but
+before we go implement that, I wanted to raise this issue.
 </p>
 
+<p><i>[
+Peter's summary:
+]</i></p>
 
 
+<blockquote>
+<p>
+The current practice is to not have throwing copy constructors in
+exception classes, because this can lead to <tt>terminate()</tt> as described in
+15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems
+consistent and does not introduce any new problems.
+</p>
 
-
-<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#New">New</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#New">New</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>
-have parameters for the "degrees of freedom" <tt>n</tt> and <tt>m</tt> that are specified as integers. For the 
-following two reasons this is an unnecessary restriction: First, in many applications such as 
-Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param- 
-eters as continuous variables. Second, the standard non-naive algorithms (i.e. 
-O(1) algorithms) 
-for simulating from these distributions work with floating-point parameters anyway (all three 
-distributions could be easily implemented using the Gamma distribution, for instance).
+However, the resolution of core issue 475 may relax this requirement:
 </p>
 
+<blockquote>
+The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should
+return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt>
+should not be called if that constructor exits with an exception.
+</blockquote>
+
 <p>
-Similar arguments could in principle be made for the parameters <tt>t</tt> and <tt>k</tt> of the discrete 
-<tt>binomial_distribution</tt> and <tt>negative_binomial_distribution</tt>, though in both cases continuous
-parameters are less frequently used in practice and in case of the <tt>binomial_distribution</tt>
-the implementation would be significantly complicated by a non-discrete parameter (in most 
-implementations one would need an approximation of the log-gamma function instead of just the 
-log-factorial function).
+Since throwing copy constructors will no longer call <tt>terminate()</tt>, option
+(3) doesn't seem reasonable as it is deemed too drastic a response in a
+recoverable situation.
 </p>
 
 <p>
-<b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters 
-to double.
+Option (2) cannot be adopted by itself, because a potential infinite
+recursion will need to be terminated by one of the other options.
 </p>
 
+</blockquote>
+
 
 <p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for the proposed resolution.
+Add the following paragraph after 18.7.5 [propagation]/7:
+</p>
+
+<blockquote>
+<p>
+<i>Returns (continued):</i> If the attempt to copy the current exception
+object throws an exception, the function returns an <tt>exception_ptr</tt> that
+refers to the thrown exception or, if this is not possible, to an
+instance of <tt>bad_exception</tt>.
+</p>
+<p>
+[<i>Note:</i> The copy constructor of the thrown exception may also fail, so
+the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid
+infinite recursion. <i>-- end note.</i>]
 </p>
+</blockquote>
+
 
 
 
 
 
 <hr>
-<h3><a name="735"></a>735. Unfortunate naming</h3>
-<p><b>Section:</b> 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
+<p><b>Section:</b> 20.6.11.3.3 [unique.ptr.runtime.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-30</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-In my opinion the choice of name for the <tt>t</tt> parameter of the <tt>binomial_distribution</tt>
-is very unfortunate. In virtually every internet reference, book and software implementation 
-this parameter is called <tt>n</tt> instead, see for example Wikipedia, Mathworld, Evans et al. (1993) 
-Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926, 
-Mathematica and Matlab.
+Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> I noticed the following:
 </p>
 
-<p>
-Similarly, the choice of <tt>k</tt> for the parameter of the negative binomial distributions is rather unusual. 
-The most common choice for the negative binomial distribution seems to be <tt>r</tt> instead.
-</p>
+<blockquote>
+<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+</pre>
 
 <p>
-Choosing unusual names for the parameters causes confusion among users and makes the 
-interface unnecessarily inconvenient to use.
+-1- <i>Requires:</i> Does not accept pointer types which are convertible
+to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
+required). [<i>Note:</i> One implementation technique is to create a private
+templated overload. <i>-- end note</i>]
 </p>
+</blockquote>
 
 <p>
-<b>Possible resolution:</b> For these reasons, I propose to change the name of the respective parameters
-to <tt>n</tt> and <tt>r</tt>.
+This could be cleaned up by mandating the overload as a public deleted
+function.  In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt>
+to be a stronger match than the deleted overload. Words...
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for the proposed resolution.
+Add to class template definition in 20.6.11.3 [unique.ptr.runtime]
 </p>
 
-
-
-
-
-<hr>
-<h3><a name="736"></a>736. Comment on [rand.dist.samp.discrete]</h3>
-<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<ol type="a">
-<li>
-The specification for <tt>discrete_distribution</tt> requires the member <tt>probabilities()</tt>
-to return a vector of <i>standardized</i> probabilities, which forces the implementation every time to 
-divide each probability by the sum of all probabilities, as the sum will in practice almost never be 
-exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to 
-compute the standardized probabilities at all and could instead work with the non-standardized 
-probabilities and the sum. If there was no standardization the user would just get back the 
-probabilities that were previously supplied to the distribution object, which to me seems to be the 
-more obvious solution.
-</li>
-<li>
-The behaviour of <tt>discrete_distribution</tt> is not specified in case the number of given
-probabilities is larger than the maximum number representable by the IntType.
-</li>
-</ol>
+<blockquote>
+<pre>// modifiers 
+T* release(); 
+void reset(T* p = 0); 
+<ins>void reset( nullptr_t );</ins>
+<ins>template&lt; typename T &gt; void reset( T ) = delete;</ins>
+void swap(unique_ptr&amp;&amp; u);
+</pre>
+</blockquote>
 
 <p>
-<b>Possible resolution:</b> I propose to change the specification such that the non-standardized 
-probabilities need to be returned and that an additional requirement is included for the number 
-of probabilities to be smaller than the maximum of IntType.
+Update 20.6.11.3.3 [unique.ptr.runtime.modifiers]
 </p>
 
+<blockquote>
+<pre>void reset(pointer p = pointer());
+<ins>void reset(nullptr_t);</ins>
+</pre>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for the proposed resolution.
+<del>-1- <i>Requires:</i> Does not accept pointer types which are convertible
+to <tt>pointer</tt> (diagnostic
+required). [<i>Note:</i> One implementation technique is to create a private
+templated overload. <i>-- end note</i>]</del>
+</p>
+<p>
+<i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. 
 </p>
+<p>...</p>
+</blockquote>
+
+<p><i>[
+Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> (Ready).
+]</i></p>
+
 
 
 
 
 
 <hr>
-<h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</h3>
-<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
+<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> James Kanze <b>Date:</b> 2008-04-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-<ol type="a">
-<li>
-The discussion in point T11 above regarding <tt>probabilities()</tt> similarly applies 
-to the method <tt>densities()</tt> of <tt>piecewise_constant_distribution</tt>.
-</li>
-<li>
 <p>
-The design of the constructor
+I just noticed that the following program is legal in C++03, but
+is forbidden in the current draft:
 </p>
-<blockquote><pre>template &lt;class InputIteratorB, class InputIteratorW&gt; 
-piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, 
-                                 InputIteratorW firstW);
-</pre></blockquote>
-<p>
-is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see 
-any performance or convenience reasons that would justify the risks inherent in such a function 
-interface, in particular the risk that input error might go unnoticed.
-</p>
-</li>
-</ol>
 
-<p>
-<b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface.
-</p>
+<blockquote><pre>#include &lt;vector&gt;
+#include &lt;iostream&gt;
 
+class Toto
+{
+public:
+    Toto() {}
+    explicit Toto( Toto const&amp; ) {}
+} ;
+
+int
+main()
+{
+    std::vector&lt; Toto &gt; v( 10 ) ;
+    return 0 ;
+}
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for the proposed resolution.
+Is this change intentional?  (And if so, what is the
+justification?  I wouldn't call such code good, but I don't see
+any reason to break it unless we get something else in return.)
 </p>
 
 
 
-
-
-<hr>
-<h3><a name="738"></a>738. Editorial issue in [rand.adapt.disc]/3</h3>
-<p><b>Section:</b> 26.4.4.1 [rand.adapt.disc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
 <p>
-Since the template parameter <tt>p</tt> and <tt>r</tt> are of type <tt>size_t</tt>, the member <tt>n</tt> in the class 
-exposition should have type <tt>size_t</tt>, too.
+In 20.1.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
 </p>
 
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>expression</th><th>post-condition</th>
+</tr>
+<tr>
+<td><tt>T t<ins>(rv)</ins><del> = rv</del></tt></td><td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
+</tr>
+<tr>
+<td colspan="2" align="center">...</td>
+</tr>
+</tbody></table>
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for the proposed resolution.
+In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
 </p>
 
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>expression</th><th>post-condition</th>
+</tr>
+<tr>
+<td><tt>T t<ins>(u)</ins><del> = u</del></tt></td><td>the value of <tt>u</tt> is unchanged and is equivalent to <tt>t</tt></td>
+</tr>
+<tr>
+<td colspan="2" align="center">...</td>
+</tr>
+</tbody></table>
+</blockquote>
+
 
 
 
 
 <hr>
-<h3><a name="739"></a>739. Defect in [rand.util.canonical]/3</h3>
-<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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.util.canonical">issues</a> in [rand.util.canonical].</p>
+<h3><a name="823"></a>823. <tt>identity&lt;void&gt;</tt> seems broken</h3>
+<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Walter Brown <b>Date:</b> 2008-04-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
 <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 complexity of <tt>generate_canonical</tt> is specified to be "exactly k=max(1, ceil(b/log2 
-R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in 
-general) be computed at compile time. As this function template is performance critical, I propose 
-to replace ceil(b/log2 R) with ceil(b/floor(log2 R)).
+N2588 seems to have added an <tt>operator()</tt> member function to the
+<tt>identity&lt;&gt;</tt> helper in 20.2.2 [forward].  I believe this change makes it no
+longer possible to instantiate <tt>identity&lt;void&gt;</tt>, as it would require
+forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
 </p>
 
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for further discussion.
+Suggested resolution:  Specialize <tt>identity&lt;void&gt;</tt> so as not to require
+the member function's presence.
 </p>
 
 
-
 <p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for the proposed resolution.
 </p>
 
 
@@ -13834,164 +18030,151 @@ for the proposed resolution.
 
 
 <hr>
-<h3><a name="740"></a>740. Please remove <tt>*_ptr&lt;T[N]&gt;</tt></h3>
-<p><b>Section:</b> 20.6.5.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Herb Sutter <b>Date:</b> 2007-10-04</p>
+<h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
+<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <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.
+In the current working paper, the <tt>&lt;string&gt;</tt> header synopsis at the end of
+21.2 [string.classes] lists a single <tt>operator&lt;&lt;</tt> overload
+for <tt>basic_string</tt>.
 </p>
 
-<p>
-To enable any bounds-checking would require run-time information, with
-the usual triplet: base (lower bound), current offset, and max offset
-(upper  bound). And I can sympathize with the point of view that you
-wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
-follow the <tt>&lt;T[N]&gt;</tt> path, especially not with additional functions to
-query the bounds etc., because this sets wrong user expectations by
-embarking on a path that doesn't go all the way to bounds checking as it
-seems to imply.
-</p>
+<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
+ basic_ostream&lt;charT, traits&gt;&amp;
+   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
+              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
+</pre></blockquote>
 
 <p>
-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).
+The definition in 21.3.8.9 [string.io] lists two:
 </p>
 
+<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
+ basic_ostream&lt;charT, traits&gt;&amp;
+   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
+              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
+
+template&lt;class charT, class traits, class Allocator&gt;
+ basic_ostream&lt;charT, traits&gt;&amp;
+   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
+              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
+</pre></blockquote>
+
 <p>
-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> :-)
+I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two
+signatures in 21.3.8.9 [string.io] should be deleted.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change the synopsis under 20.6.5 [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>
 
+
+
+<hr>
+<h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3>
+<p><b>Section:</b> 19.4.2.1 [syserr.errcode.overview], 20.6.12.2.8
+[util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3
+[bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9
+[re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
+<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>
-Remove the entire section 20.6.5.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete&lt;T[N]&gt;</tt></b>.
+Should the following use rvalues references to stream in insert/extract
+operators?
 </p>
 
+<ul>
+<li>19.4.2.1 [syserr.errcode.overview]</li>
+<li>20.6.12.2.8 [util.smartptr.shared.io]</li>
+<li>22.2.8 [facets.examples]</li>
+<li>23.3.5.3 [bitset.operators]</li>
+<li>26.3.6 [complex.ops]</li>
+<li>Doubled signatures in 27.5 [stream.buffers] for character inserters
+(ref 27.6.2.6.4 [ostream.inserters.character])
++ definition 27.6.2.6.4 [ostream.inserters.character]</li>
+<li>28.9 [re.submatch]</li>
+</ul>
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Remove the entire section 20.6.5.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
-and its subsections: 20.6.5.4.1 [unique.ptr.compiletime.dtor], 20.6.5.4.2 [unique.ptr.compiletime.observers],
-20.6.5.4.3 [unique.ptr.compiletime.modifiers].
 </p>
 
 
 
 
 
-
 <hr>
-<h3><a name="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.6.6.2.11 [util.smartptr.getdeleter] <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-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
+<h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3>
+<p><b>Section:</b> 22.2.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-07</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
+In the spirit of <tt>printf vs iostream</tt>...
 </p>
 
 <p>
-According to the recent draft N2369, both the header memory synopsis
-of 20.6 [memory] and 20.6.6.2.11 [util.smartptr.getdeleter] declare:
+POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the
+implication is that in the absence of <tt>'</tt> no grouping characters are
+inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert
+grouping characters. Can this be considered a defect worth fixing for
+C++0x? Maybe <tt>ios_base</tt> needs an additional flag?
 </p>
 
-<blockquote><pre>template&lt;class D, class T&gt; D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
-</pre></blockquote>
+<p><i>[
+Pablo Halpern:
+]</i></p>
 
-<p>
-This allows to retrieve the pointer to a mutable deleter of a <tt>const
-shared_ptr</tt> (if that owns one) and therefore contradicts the usual
-philosophy that associated functors are either read-only (e.g.
-<tt>key_comp</tt> or <tt>value_comp</tt> of <tt>std::map</tt>) or do at least reflect
-the mutability of the owner (as seen for the both overloads of
-<tt>unique_ptr::get_deleter</tt>).
-Even the next similar counter-part of <tt>get_deleter</tt> - the two
-overloads of <tt>function::target</tt> in the class template function
-synopsis 20.5.15.2 [func.wrap.func] or in 20.5.15.2.5 [func.wrap.func.targ] - do
-properly mirror the const-state of the owner.
-</p>
 
-<b>Possible proposed resolutions:</b>
+<blockquote>
+I'm not sure it constitutes a defect, but I would be in favor of adding
+another flag (and corresponding manipulator).
+</blockquote>
 
-<p>
-Replace the declarations of <tt>get_deleter</tt> in the header <tt>&lt;memory&gt;</tt>
-synopsis of 20.6 [memory] and in 20.6.6.2.11 [util.smartptr.getdeleter] by one of the
-following alternatives (A) or (B):
-</p>
+<p><i>[
+Martin Sebor:
+]</i></p>
 
-<ol type="A">
-<li>
-Provide <b>only</b> the immutable variant. This would reflect the
-current praxis of <tt>container::get_allocator()</tt>, <tt>map::key_comp()</tt>, or
-<tt>map::value_comp</tt>.
 
-<blockquote><pre>template&lt;class D, class T&gt; const D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
-</pre></blockquote>
-</li>
-<li>
-Just remove the function.
-</li>
-</ol>
+<blockquote>
+I don't know if it qualifies as a defect but I agree that there
+should be an easy way to control whether the thousands separator
+should or shouldn't be inserted. A new flag would be in line with
+the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or
+<tt>showbase</tt>).
+</blockquote>
 
-<p>
-Alberto Ganesh Barbati adds:
-</p>
 
-<ol start="3" type="A">
-<li>
+<p><b>Proposed resolution:</b></p>
 <p>
-Replace it with two functions:
 </p>
-<blockquote><pre>template &lt;class D, class T&gt; D get_deleter(shared_ptr&lt;T&gt; const&amp;);
-template &lt;class D, class T&gt; bool has_deleter(shared_ptr&lt;T&gt; const&amp;);
-</pre></blockquote>
 
-<p>
-The first one would throw if <tt>D</tt> is the wrong type, while the latter would
-never throw. This approach would reflect the current praxis of
-<tt>use_facet/has_facet</tt>, with the twist of returning the deleter by value as
-<tt>container::get_allocator()</tt> do.
-</p>
-</li>
-</ol>
 
-<p>
-Peter Dimov adds:
-</p>
 
-<blockquote>
+
+
+<hr>
+<h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
+<p><b>Section:</b> 20.6.12.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-11</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
+<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>
-My favorite option is "not a defect". A, B and C break useful code.
+Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and
+<tt>weak_ptr</tt> and <tt>enable_shared_from_this) constexpr</tt>? This would enable
+static initialization for <tt>shared_ptr</tt> variables, eliminating another
+unfair advantage of raw pointers.
 </p>
-</blockquote>
-
 
 
 <p><b>Proposed resolution:</b></p>
@@ -14003,126 +18186,127 @@ My favorite option is "not a defect". A, B and C break useful code.
 
 
 <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#New">New</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>
+<h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
+<p><b>Section:</b> 30.3.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-18</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-This 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>.
+[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
+</p>
+<p>
+Currently <tt>std::mutex</tt> doesn't support static initialization. This is a
+regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that
+we should strive to eliminate such regressions in expressive power where
+possible, both to ease migration and to not provide incentives to (or
+force) people to forego the C++ primitives in favor of pthreads.
 </p>
 
+
+<p><b>Proposed resolution:</b></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 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;);
+<hr>
+<h3><a name="829"></a>829. current_exception wording unclear about exception type</h3>
+<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-04-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>Consider this code:</p>
 
-}  // Mine
+<blockquote>
+<pre>exception_ptr xp;</pre>
+<pre>try {do_something(); }
+
+catch (const runtime_error&amp; ) {xp = current_exception();}
 
 ...
 
-Mine::proxied_iterator&lt;Mine::A&gt; i(...)
-Mine::A a;
-<b>swap(*i1, a);</b>
-</pre></blockquote>
+rethrow_exception(xp);</pre>
+</blockquote>
 
 <p>
-The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
-and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
-same type).  A secondary point is that to support proxies, one must be able to pass rvalues
-to <tt>swap</tt>.  But note that I am not stating that the general purpose <tt>std::swap</tt>
-should accept rvalues!  Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
-to take rvalues.
+Say <code>do_something()</code> throws an exception object of type <code>
+range_error</code>. What is the type of the exception object thrown by <code>
+rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>; 
+if it were of type <code>runtime_error</code> it still isn't possible to 
+propagate an exception and the exception_ptr/current_exception/rethrow_exception 
+machinery serves no useful purpose.
 </p>
 
 <p>
-That is, no standard library code needs to change.  We simply need to have a more flexible
-definition of <tt>Swappable</tt>.
+Unfortunately, the current wording does not explicitly say that. Different 
+people read the current wording and come to different conclusions. While it may 
+be possible to deduce the correct type from the current wording, it would be 
+much clearer to come right out and explicitly say what the type of the referred 
+to exception is.
+</p>
+
+<p><i>[
+Peter adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I don't like the proposed resolution of 829. The normative text is
+unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled
+exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
+exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7.
+</p>
+<p>
+A better way to address this is to simply add the non-normative example
+in question as a clarification. The term <i>currently handled exception</i>
+should be italicized and cross-referenced. A [<i>Note:</i> the currently
+handled exception is the exception that a throw expression without an
+operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option.
 </p>
+</blockquote>
 
 
 
 <p><b>Proposed resolution:</b></p>
+
 <p>
-Change 20.1.1 [utility.arg.requirements]:
+After 18.7.5 [propagation] , paragraph 7, add the indicated text:
 </p>
 
 <blockquote>
+<pre>exception_ptr current_exception();</pre>
 
+<blockquote>
 <p>
--1- The template definitions in the C++ Standard Library refer to various
-named requirements whose details are set out in tables 31-38. In these
-tables, <tt>T</tt> <ins>and <tt>V</tt> are</ins> <del>is a</del> type<ins>s</ins> to be supplied by a C++ program
-instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
-values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
-lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
-<tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
-rvalue of type <tt>T</tt><ins>; <tt>w</tt> is a value of type <tt>T</tt>; and <tt>v</tt> is a value of type <tt>V</tt></ins>.
+<i>Returns:</i> <code>exception_ptr</code> object that refers 
+to the currently handled exception or a copy of the currently handled 
+exception, or a null <code>exception_ptr</code> object if no exception is being handled. If 
+the function needs to allocate memory and the attempt fails, it returns an
+<code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>. 
+It is unspecified whether the return values of two successive calls to
+<code>current_exception</code> refer to the same exception object. 
+[<i>Note:</i> that is, it 
+is unspecified whether <code>current_exception</code>
+creates a new copy each time it is called.
+<i>-- end note</i>]
 </p>
 
-<table border="1">
-<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
-<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
-<tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
-<td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
-held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
-<del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
-by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
-<tr><td colspan="3">
 <p>
-The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
+<ins><i>Remarks:</i> The type of the exception object 
+referred to by the returned <code>exception_ptr</code> is the most-derived 
+type of the currently handled exception.</ins>
 </p>
-<ul>
-<li>
-<tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
-the same type and </ins> <tt>T</tt> satisfies the
-<del><tt>CopyConstructible</tt></del>
-<ins><tt>MoveConstructible</tt></ins> requirements (Table <del>34</del>
-<ins>33</ins>) and the <del><tt>CopyAssignable</tt></del>
-<ins><tt>MoveAssignable</tt></ins> requirements (Table <del>36</del>
-<ins>35</ins>);
-</li>
-<li>
-<tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
-<tt>swap</tt> exists in the same namespace as the definition of
-<tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
-<tt>swap(<del>t</del><ins>w</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the
-semantics described in this table.
-</li>
-</ul>
-</td></tr>
-</tbody></table>
+
+<p>
+<i>Throws:</i> nothing.
+</p>
+
+</blockquote>
 </blockquote>
 
 
@@ -14131,217 +18315,349 @@ 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.6.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
+<h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3>
+<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#char.traits">active issues</a> in [char.traits].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
 <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>
-When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a> in Kona the following note was made:
+  Paragraph 4 of 21.1 [char.traits] mentions that this
+  section specifies two specializations (<code>char_traits&lt;char&gt;</code>
+  and (<code>char_traits&lt;wchar_t&gt;</code>). However, there are actually
+  four specializations provided, i.e. in addition to the two above also
+  <code>char_traits&lt;char16_t&gt;</code> and <code>char_traits&lt;char32_t&gt;</code>).
+  I guess this was just an oversight and there is nothing wrong with just
+  fixing this.
 </p>
 
-<blockquote><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><i>[
+Alisdair adds:
+]</i></p>
+
+<blockquote>
+<tt>char_traits&lt; char16/32_t &gt;</tt>
+should also be added to <tt>&lt;ios_fwd&gt;</tt> in 27.2 [iostream.forward], and all the specializations
+taking a <tt>char_traits</tt> parameter in that header.
+</blockquote>
+
 
+<p><b>Proposed resolution:</b></p>
 <p>
-This issue was opened in response to that note.
+  Replace paragraph 4 of 21.1 [char.traits] by:
 </p>
-
+<blockquote>
 <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.
+  This subclause specifies a struct template, <code>char_traits&lt;charT&gt;</code>,
+  and four explicit specializations of it, <code>char_traits&lt;char&gt;</code>,
+  <code>char_traits&lt;char16_t&gt;</code>, <code>char_traits&lt;char32_t&gt;</code>, and
+  <code>char_traits&lt;wchar_t&gt;</code>, all of which appear in the header
+  &lt;string&gt; and satisfy the requirements below.
 </p>
+</blockquote>
 
 
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 20.6.6.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>
 
+<hr>
+<h3><a name="831"></a>831. wrong type for not_eof()</h3>
+<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-Change 20.6.6.2.4 [util.smartptr.shared.mod]:
+  In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function
+  is using an argument of type <i>e</i> which denotes an object of
+  type <code>X::int_type</code>. However, the specializations in
+  21.1.3 [char.traits.specializations] all use <code>char_type</code>.
+  This would effectively mean that the argument type actually can't
+  represent EOF in the first place. I'm pretty sure that the type used
+  to be <code>int_type</code> which is quite obviously the only sensible
+  argument.
+</p>
+<p>
+  This issue is close to being editorial. I suspect that the proposal
+  changing this section to include the specializations for <code>char16_t</code>
+  and <code>char32_t</code> accidentally used the wrong type.
 </p>
 
-<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-Change 20.6.6.2.9 [util.smartptr.shared.spec]:
+  In 21.1.3.1 [char.traits.specializations.char],
+  21.1.3.2 [char.traits.specializations.char16_t],
+  21.1.3.3 [char.traits.specializations.char32_t], and
+   [char.traits.specializations.wchar_t] correct the
+  argument type from <code>char_type</code> to <code>int_type</code>.
 </p>
 
-<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#New">New</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>
+<h3><a name="832"></a>832. Applying constexpr to System error support</h3>
+<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
 <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>
-Without some lifetime guarantee, it is hard to know how this type can be
-used. &nbsp;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.
+Initialization of objects of class <tt>error_code</tt>
+(19.4.2 [syserr.errcode]) and class
+<tt>error_condition</tt> (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of
+the new <tt>constexpr</tt> feature 
+[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>]
+of C++0x. Less code will need to be
+generated for both library implementations and user programs when
+manipulating constant objects of these types. 
 </p>
+
 <p>
-(Peter Dimov agreed it should be clearer, maybe a non-normative note to
-explain?)
+This was not proposed originally because the constant expressions
+proposal was moving into the standard at about the same time as the
+Diagnostics Enhancements proposal 
+[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>],
+and it wasn't desirable to
+make the later depend on the former. There were also technical concerns
+as to how <tt>constexpr</tt> would apply to references. Those concerns are now
+resolved; <tt>constexpr</tt> can't be used for references, and that fact is
+reflected in the proposed resolution.
+</p>
+
+<p>
+Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements.
+</p>
+
+<p>
+LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> is related in that it raises the question of whether the
+exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.4.2 [syserr.errcode]) and class
+<tt>error_condition</tt> (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer.
+While in the context of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> that is arguably an editorial question,
+presenting it as a pointer becomes more or less required with this
+proposal, given <tt>constexpr</tt> does not play well with references. The
+proposed resolution thus changes the private member to a pointer, which
+also brings it in sync with real implementations.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
+The proposed wording assumes the LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> proposed wording has been
+applied to the WP, resulting in the former <tt>posix_category</tt> being renamed
+<tt>generic_category</tt>. If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has not been applied, the names in this
+proposal must be adjusted accordingly.
 </p>
 
+<p>
+Change 19.4.1.1 [syserr.errcat.overview] Class
+<tt>error_category</tt> overview <tt>error_category</tt> synopsis  as
+indicated:
+</p>
 
+<blockquote><pre><del>const error_category&amp; get_generic_category();</del>
+<del>const error_category&amp; get_system_category();</del>
 
+<del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
+<del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
+</pre></blockquote>
 
+<p>
+Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated:
+</p>
 
-<hr>
-<h3><a name="745"></a>745. copy_exception API slices.</h3>
-<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> 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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
+<pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
+</pre>
 <p>
-It could be I did not understand the design rationale, but I thought
-copy_exception would produce an exception_ptr to the most-derived (dynamic)
-type of the passed exception. &nbsp;Instead it slices, which appears to be less
-useful, and a likely source of FAQ questions in the future.
+<del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
+to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
+class <tt>error_category</tt>.
 </p>
+
 <p>
-(Peter Dimov suggests NAD)
+<del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
+functions shall behave as specified for the class <tt>error_category</tt>. The
+object's <tt>name</tt> virtual function shall return a pointer to the string
+<tt>"GENERIC"</tt>.
 </p>
 
+<pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
+</pre>
 
-<p><b>Proposed resolution:</b></p>
 <p>
+<del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
+to <del>an</del> <ins>a statically
+initialized</ins> object of a type derived from class <tt>error_category</tt>.
 </p>
 
+<p>
+<del><i>Remarks:</i></del>  The object's <tt>equivalent</tt> virtual functions shall behave as
+specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
+shall return a pointer to the string <tt>"system"</tt>. The object's
+<tt>default_error_condition</tt> virtual function shall behave as follows:
+</p>
 
+<p>
+If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
+shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the
+function shall return <tt>error_condition(ev, system_category)</tt>. What
+constitutes correspondence for any given operating system is
+unspecified. [<i>Note:</i> The number of potential system error codes is large
+and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
+Thus implementations are given latitude in determining correspondence.
+<i>-- end note</i>]
+</p>
+</blockquote>
 
+<p>
+Change 19.4.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated:
+</p>
 
+<blockquote><pre>class error_code {
+public:
+  ...;
+  <ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+  ...
+  void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+  ...
+  const error_category<del>&amp;</del><ins>*</ins> category() const;
+  ...
+private:
+  int val_;                    // exposition only
+  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
+</pre></blockquote>
 
-<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#New">New</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#New">New</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>. &nbsp;For instance, the Core
-language for a failed new expression is:
+Change 19.4.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
 </p>
+
 <blockquote>
+<pre><ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+</pre>
 <p>
-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).
+<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
 </p>
-</blockquote>
 <p>
-I think we should allow similar freedom here (or add a blanket
-compatible-exception freedom paragraph in 17)
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
 </p>
 <p>
-I prefer the clause 17 approach myself, and maybe clean up any outstanding
-wording that could also rely on it.
+<i>Throws:</i> Nothing.
 </p>
+</blockquote>
 
+<p>
+Change 19.4.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers  as indicated:
+</p>
 
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+<pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+</pre>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
+</p>
 <p>
+<i>Throws:</i> Nothing.
 </p>
+</blockquote>
 
+<p>
+Change 19.4.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers  as indicated:
+</p>
 
+<blockquote>
+<pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
+</pre>
 
+<p>
+<i>Returns:</i> <tt>cat_</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
 
+<p>
+Change 19.4.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview   as indicated:
+</p>
+
+<blockquote>
+<pre>class error_condition {
+public:
+  ...;
+  <ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+  ...
+  void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+  ...
+  const error_category<del>&amp;</del><ins>*</ins> category() const;
+  ...
+private:
+  int val_;                    // exposition only
+  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
+</pre>
+</blockquote>
 
-<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#New">New</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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-We have 3 separate type traits to identify classes supporting no-throw
-operations, which are very useful when trying to provide exception safety
-guarantees. &nbsp;However, I'm not entirely clear on what the current wording
-requires of a conforming implementation. &nbsp;To quote from
-<tt>has_nothrow_default_constructor</tt>:
+Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
+</p>
+
+<blockquote>
+<pre>constexpr error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+</pre>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
 </p>
-<blockquote><p>
-or <tt>T</tt> is a class type with a default constructor that is known not to throw
-any exceptions
-</p></blockquote>
 <p>
-What level of magic do we expect to deduce if this is known?
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
 </p>
 <p>
-E.g.
+<i>Throws:</i> Nothing.
 </p>
+</blockquote>
 
-<blockquote><pre>struct test{
-&nbsp;int x;
-&nbsp;test() : x() {}
-};
-</pre></blockquote>
 <p>
-Should I expect a conforming compiler to 
-&nbsp;<tt>assert( has_nothrow_constructor&lt;test&gt;::value )</tt>
+Change 19.4.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
 </p>
+
+<blockquote>
+<pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
+</pre>
 <p>
-Is this a QoI issue?
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
 </p>
 <p>
-Should I expect to 'know' only if-and-only-if there is an inline definition
-available?
+<i>Throws:</i> Nothing.
 </p>
+</blockquote>
+
 <p>
-Should I never expect that to be true, and insist that the user supplies an
-empty throw spec if they want to assert the no-throw guarantee?
+Change 19.4.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
 </p>
+
+<blockquote>
+<pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
+</pre>
 <p>
-It would be helpful to maybe have a footnote explaining what is required,
-but right now I don't know what to suggest putting in the footnote.
+<i>Returns:</i> <tt>cat_</tt>.
 </p>
 <p>
-(agreement since is that trivial ops and explicit no-throws are required.
-Open if QoI should be allowed to detect further)
+<i>Throws:</i> Nothing.
 </p>
+</blockquote>
 
+<p>
+Throughout 19.4 [syserr] System error support, change "<tt>category().</tt>"  to "<tt>category()-&gt;</tt>".
+Appears approximately six times.
+</p>
 
-<p><b>Proposed resolution:</b></p>
 <p>
+<i>[Partially Editorial]</i> In 19.4.4 [syserr.compare] Comparison operators,
+paragraphs 2 and 4, change "<tt>category.equivalent(</tt>"  to
+"<tt>category()-&gt;equivalent(</tt>".
 </p>
 
 
@@ -14349,346 +18665,550 @@ Open if QoI should be allowed to detect further)
 
 
 <hr>
-<h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3>
-<p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>
+<h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
+<p><b>Section:</b> 17.4.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-I am trying to decide is a pure virtual function is a <i>necessary</i> as well as
-sufficient requirement to be classified as abstract?
-</p>
-<p>
-For instance, is the following (non-polymorphic) type considered abstract?
-</p>
-<blockquote><pre>struct abstract {
-protected:
-&nbsp;abstract(){}
-&nbsp;abstract( abstract const &amp; ) {}
-&nbsp;~abstract() {}
-};
-</pre></blockquote>
-<p>
-(Suggested that this may be NAD, with an editorial fix-up from Pete on the
-core wording to make clear that abstract requires a pure virtual function)
+Once the C++0x standard library is feature complete, the LWG needs to
+review 17.4.1.3 [compliance] Freestanding implementations header list to
+ensure it reflects LWG consensus.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>
-</p>
 
 
 
 
 
 <hr>
-<h3><a name="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#New">New</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>
+<h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
+<p><b>Section:</b> 20.6.11.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-05-14</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
 <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.
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>) proposes a useful
+extension point for <tt>unique_ptr</tt> by granting support for an optional
+<tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
+(In the following: <tt>pointer</tt>).
 </p>
 <p>
-For instance:
+Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
+impact on at least two key features of <tt>unique_ptr</tt>:
+</p>
+
+<ol>
+<li>Operational fail-safety.</li>
+<li>(Well-)Definedness of expressions.</li>
+</ol>
+
+<p>
+<tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all*
+operations cannot throw and therefore adds proper wording to the affected
+operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types
+("smart pointers") will be allowed, either *all* throw-nothing clauses have to
+be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws
+an exception"-clauses or it has to be said explicitly that all used
+operations of
+<tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt>
+to be as near as possible to the advantages of native pointers which cannot
+fail and thus strongly favor the second choice. Also, the alternative position
+would make it much harder to write safe and simple template code for
+<tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given
+that all of the expressions of <tt>pointer</tt> used to define semantics are required to
+be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>).
 </p>
-<blockquote>
-<pre>struct awkward {
-&nbsp;awkward( const awkward &amp; ) throw() {}
-&nbsp;awkward( awkward &amp; ) { throw "oops"; } };
-</pre>
-</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
+Add the following sentence just at the end of the newly proposed
+20.6.11.2 [unique.ptr.single]/p. 3:
 </p>
 
+<blockquote>
+<tt>unique_ptr&lt;T, D&gt;::pointer</tt>'s operations shall be well-formed, shall have well
+defined behavior, and shall not throw exceptions.
+</blockquote>
+
 
 
 
 
 <hr>
-<h3><a name="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#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
+<h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
+<p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-With the pending arrival of explicit conversion functions though, I'm
-wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
-</p>
+       <p>
+
+The fix for
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
+now integrated into the working paper, overlooks a couple of minor
+problems.
+
+       </p>
+       <p>
+
+First, being an unformatted function once again, <code>flush()</code>
+is required to create a sentry object whose constructor must, among
+other things, flush the tied stream. When two streams are tied
+together, either directly or through another intermediate stream
+object, flushing one will also cause a call to <code>flush()</code> on
+the other tied stream(s) and vice versa, ad infinitum. The program
+below demonstrates the problem.
+
+       </p>
+       <p>
+
+Second, as Bo Persson notes in his
+comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>,
+for streams with the <code>unitbuf</code> flag set such
+as <code>std::stderr</code>, the destructor of the sentry object will
+again call <code>flush()</code>. This seems to create an infinite
+recursion for <code>std::cerr &lt;&lt; std::flush;</code>
+
+       </p>
+       <blockquote>
+           <pre>#include &lt;iostream&gt;
+
+int main ()
+{
+   std::cout.tie (&amp;std::cerr);
+   std::cerr.tie (&amp;std::cout);
+   std::cout &lt;&lt; "cout\n";
+   std::cerr &lt;&lt; "cerr\n";
+} 
+           </pre>
+       </blockquote>
+   
+   <p><b>Proposed resolution:</b></p>
+       <p>
+
+I think an easy way to plug the first hole is to add a requires clause
+to <code>ostream::tie(ostream *tiestr)</code> requiring the this
+pointer not be equal to any pointer on the list starting
+with <code>tiestr-&gt;tie()</code>
+through <code>tiestr()-&gt;tie()-&gt;tie()</code> and so on. I am not
+proposing that we require implementations to traverse this list,
+although I think we could since the list is unlikely to be very long.
+
+       </p>
+       <p>
+
+Add a <i>Requires</i> clause to 27.4.4.2 [basic.ios.members] withethe following
+text:
 
+       </p>
+       <blockquote>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
+<i>Requires:</i> If <code>(tiestr != 0)</code> is
+true, <code>tiestr</code> must not be reachable by traversing the
+linked list of tied stream objects starting
+from <code>tiestr-&gt;tie()</code>.
+
+       </blockquote>
+       <p>
+
+In addition, to prevent the infinite recursion that Bo writes about in
+his comp.lang.c++.moderated post, I propose to change
+27.6.2.4 [ostream::sentry], p2 like so:
+
+       </p>
+       <blockquote>
 
+If <code>((os.flags() &amp; ios_base::unitbuf) &amp;&amp;
+!uncaught_exception())</code> is true,
+calls <del>os.flush()</del> <ins><code>os.rdbuf()-&gt;pubsync()</code></ins>.
 
+       </blockquote>
+   
 
 
 
 <hr>
-<h3><a name="751"></a>751. change pass-by-reference members of <tt>vector&lt;bool&gt;</tt> to pass-by-value?</h3>
-<p><b>Section:</b> 23.2.6 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
+<h3><a name="836"></a>836. 
+       effects of <code>money_base::space</code> and
+       <code>money_base::none</code> on <code>money_get</code>
+   </h3>
+<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-A number of vector&lt;bool&gt; members take const bool&amp; as arguments.
-Is there any chance we could change them to pass-by-value or would I 
-be wasting everyone's time if wrote up an issue?
-</p>
+       <p>
 
+In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following:
 
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
+       </p>
+       <blockquote>
 
+Where <code>space</code> or <code>none</code> appears in the format
+pattern, except at the end, optional white space (as recognized
+by <code>ct.is</code>) is consumed after any required space.
 
+       </blockquote>
+       <p>
 
+This requirement can be (and has been) interpreted two mutually
+exclusive ways by different readers. One possible interpretation
+is that:
 
+       </p>
+       <blockquote>
+           <ol>
+               <li>
 
-<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>
- <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>Discussion:</b></p>
-<p>
-Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
-on the allocators are expected to be amortized constant time."?
-</p>
-<p>
-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
-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
-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
-the constants, not the asymptotic complexity.
-</p>
+where <code>money_base::space</code> appears in the format, at least
+one space is required, and
 
+               </li>
+               <li>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.1.2 [allocator.requirements]/2:
-</p>
+where <code>money_base::none</code> appears in the format, space is
+allowed but not required.
 
-<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
-requirements on allocator types.
-</p>
-</blockquote>
+               </li>
+           </ol>
+       </blockquote>
+       <p>
 
+The other is that:
 
+       </p>
+       <blockquote>
 
+where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
 
+       </blockquote>
+   
 
-<hr>
-<h3><a name="753"></a>753. Move constructor in draft</h3>
-<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Yechezkel Mett <b>Date:</b> 2007-10-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The draft standard n2369 uses the term <i>move constructor</i> in a few
-places, but doesn't seem to define it.
-</p>
+   <p><b>Proposed resolution:</b></p>
+       <p>
 
-<p>
-<tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as
-follows:
-</p>
+I propose to change the text to make it clear that the first
+interpretation is intended, that is, to make following change to
+22.2.6.1.2 [locale.money.get.virtuals], p2:
 
-<blockquote>
-<table border="1">
-<caption><tt>MoveConstructible</tt> requirements</caption>
-<tbody><tr>
-<th>expression</th> <th>post-condition</th>
-</tr>
-<tr>
-<td><tt>T t = rv</tt></td> <td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
-</tr>
-<tr>
-<td colspan="2">[<i>Note:</i> There is no requirement on the value of <tt>rv</tt> after the 
-construction. <i>-- end note</i>]</td>
-</tr>
-</tbody></table>
-</blockquote>
+       </p>
 
-<p>
-(where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
-</p>
+       <blockquote>
 
-<p>
-So I assume the move constructor is the constructor that would be used
-in filling the above requirement.
-</p>
+When <code><ins>money_base::</ins>space</code>
+or <code><ins>money_base::</ins>none</code> appears <ins>as the last
+element </ins>in the format pattern, <del>except at the end, optional
+white space (as recognized by <code>ct.is</code>) is consumed after
+any required space.</del> <ins>no white space is consumed. Otherwise,
+where <code>money_base::space</code> appears in any of the initial
+elements of the format pattern, at least one white space character is
+required. Where <code>money_base::none</code> appears in any of the
+initial elements of the format pattern, white space is allowed but not
+required. In either case, any required followed by all optional white
+space (as recognized by <code>ct.is()</code>) is consumed.</ins>
+If <code>(str.flags() &amp; str.showbase)</code> is <code>false</code>, ...
 
-<p>
-For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in
-23.2.5.4 [vector.modifiers] we have
-</p>
+       </blockquote>
+   
 
-<blockquote>
-<i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall
-not throw any exceptions.
-</blockquote>
 
-<p>
-Firstly "If <tt>value_type</tt> has a move constructor" is superfluous; every
-type which can be put into a <tt>vector</tt> has a move constructor (a copy
-constructor is also a move constructor). Secondly it means that for
-any <tt>value_type</tt> which has a throwing copy constructor and no other move
-constructor these functions cannot be used -- which I think will come
-as a shock to people who have been using such types in <tt>vector</tt> until
-now!
-</p>
 
-<p>
-I can see two ways to correct this. The simpler, which is presumably
-what was intended, is to say "If <tt>value_type</tt> has a move constructor and
-no copy constructor, the move constructor shall not throw any
-exceptions" or "If <tt>value_type</tt> has a move constructor which changes the
-value of its parameter,".
-</p>
+<hr>
+<h3><a name="837"></a>837. 
+   <code>basic_ios::copyfmt()</code> overly loosely specified
+ </h3>
+<p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+   <p>
 
-<p>
-The other alternative is add to <tt>MoveConstructible</tt> the requirement that
-the expression does not throw. This would mean that not every type
-that satisfies the <tt>CopyConstructible</tt> requirements also satisfies the
-<tt>MoveConstructible</tt> requirements. It would mean changing requirements in
-various places in the draft to allow either <tt>MoveConstructible</tt> or
-<tt>CopyConstructible</tt>, but I think the result would be clearer and
-possibly more concise too.
-</p>
+The <code>basic_ios::copyfmt()</code> member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects:
 
+   </p>
+   <blockquote>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
+<i>Effects</i>: If <code>(this == &amp;rhs)</code> does
+nothing. Otherwise assigns to the member objects of <code>*this</code>
+the corresponding member objects of <code>rhs</code>, except that
+
+     <ul>
+       <li>
+
+<code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
+
+       </li>
+       <li>
+
+<code>exceptions()</code> is altered last by
+calling <code>exceptions(rhs.except)</code>
+
+       </li>
+       <li>
 
+the contents of arrays pointed at by <code>pword</code>
+and <code>iword</code> are copied not the pointers themselves
 
+       </li>
+     </ul>
+   </blockquote>
+   <p>
+
+Since the rest of the text doesn't specify what the member objects
+of <code>basic_ios</code> are this seems a little too loose.
+
+   </p>
+ 
+
+ <p><b>Proposed resolution:</b></p>
+   <p>
+
+I propose to tighten things up by adding a <i>Postcondition</i> clause
+to the function like so:
+
+   </p>
+   <blockquote>
+     <i>Postconditions:</i>
+
+     <table border="1">
+       <thead>
+         <tr>
+           <th colspan="2"><code>copyfmt()</code> postconditions</th>
+         </tr>
+         <tr>
+           <th>Element</th>
+           <th>Value</th>
+         </tr>
+       </thead>
+       <tbody>
+         <tr>
+           <td><code>rdbuf()</code></td>
+           <td><i>unchanged</i></td>
+         </tr>
+         <tr> 
+           <td><code>tie()</code></td>
+           <td><code>rhs.tie()</code></td>
+         </tr>
+         <tr> 
+           <td><code>rdstate()</code></td>
+           <td><i>unchanged</i></td>
+         </tr>
+         <tr> 
+           <td><code>exceptions()</code></td>
+           <td><code>rhs.exceptions()</code></td>
+         </tr>
+         <tr> 
+           <td><code>flags()</code></td>
+           <td><code>rhs.flags()</code></td>
+         </tr>
+         <tr> 
+           <td><code>width()</code></td>
+           <td><code>rhs.width()</code></td>
+         </tr>
+         <tr> 
+           <td><code>precision()</code></td>
+           <td><code>rhs.precision()</code></td>
+         </tr>
+         <tr> 
+           <td><code>fill()</code></td>
+           <td><code>rhs.fill()</code></td>
+         </tr>
+         <tr> 
+           <td><code>getloc()</code></td>
+           <td><code>rhs.getloc()</code></td>
+         </tr>
+       </tbody>
+     </table>
+   </blockquote>
+   <p>
+
+The format of the table follows Table 117 (as
+of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code>
+effects.
+
+   </p>
+   <p>
+
+The intent of the new table is not to impose any new requirements or
+change existing ones, just to be more explicit about what I believe is
+already there.
+
+   </p>
+ 
 
 
 
 <hr>
-<h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3>
-<p><b>Section:</b> 20.6.4.1 [uninitialized.copy] <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-10-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#uninitialized.copy">active issues</a> in [uninitialized.copy].</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>
+<h3><a name="838"></a>838. 
+   can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
+ </h3>
+<p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-14882-2003, [lib.uninitialized.copy] is currently written as follows:
-</p>
+   <p>
+
+From message c++std-lib-20003...
+
+   </p>
+   <p>
+
+The description of <code>istream_iterator</code> in
+24.5.1 [istream.iterator], p1 specifies that objects of the
+class become the <i>end-of-stream</i> (EOS) iterators under the
+following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a> another problem
+with this paragraph):
+
+   </p>
+   <blockquote>
+
+If the end of stream is reached (<code>operator void*()</code> on the
+stream returns <code>false</code>), the iterator becomes equal to
+the <i>end-of-stream</i> iterator value.
+
+   </blockquote>
+   <p>
+
+One possible implementation approach that has been used in practice is
+for the iterator to set its <code>in_stream</code> pointer to 0 when
+it reaches the end of the stream, just like the default ctor does on
+initialization. The problem with this approach is that
+the <i>Effects</i> clause for <code>operator++()</code> says the
+iterator unconditionally extracts the next value from the stream by
+evaluating <code>*in_stream &gt;&gt; value</code>, without checking
+for <code>(in_stream == 0)</code>.
+
+   </p>
+   <p>
+
+Conformance to the requirement outlined in the <i>Effects</i> clause
+can easily be verified in programs by setting <code>eofbit</code>
+or <code>failbit</code> in <code>exceptions()</code> of the associated
+stream and attempting to iterate past the end of the stream: each
+past-the-end access should trigger an exception. This suggests that
+some other, more elaborate technique might be intended.
+
+   </p>
+   <p>
+
+Another approach, one that allows <code>operator++()</code> to attempt
+to extract the value even for EOS iterators (just as long
+as <code>in_stream</code> is non-0) is for the iterator to maintain a
+flag indicating whether it has reached the end of the stream. This
+technique would satisfy the presumed requirement implied by
+the <i>Effects</i> clause mentioned above, but it isn't supported by
+the exposition-only members of the class (no such flag is shown). This
+approach is also found in existing practice.
+
+   </p>
+   <p>
+
+The inconsistency between existing implementations raises the question
+of whether the intent of the specification is that a non-EOS iterator
+that has reached the EOS become a non-EOS one again after the
+stream's <code>eofbit</code> flag has been cleared? That is, are the
+assertions in the program below expected to pass?
+
+   </p>
+   <blockquote>
+     <pre>   sstream strm ("1 ");
+   istream_iterator eos;
+   istream_iterator it (strm);
+   int i;
+   i = *it++
+   assert (it == eos);
+   strm.clear ();
+   strm &lt;&lt; "2 3 ";
+   assert (it != eos);
+   i = *++it;
+   assert (3 == i);
+     </pre>
+   </blockquote>
+   <p>
+
+Or is it intended that once an iterator becomes EOS it stays EOS until
+the end of its lifetime?
+
+   </p>
+ 
+
+ <p><b>Proposed resolution:</b></p>
+   <p>
+
+The discussion of this issue on the reflector suggests that the intent
+of the standard is for an <code>istreambuf_iterator</code> that has
+reached the EOS to remain in the EOS state until the end of its
+lifetime. Implementations that permit EOS iterators to return to a
+non-EOS state may only do so as an extension, and only as a result of
+calling <code>istream_iterator</code> member functions on EOS
+iterators whose behavior is in this case undefined.
+
+   </p>
+   <p>
+
+To this end we propose to change 24.5.1 [istream.iterator], p1,
+as follows:
 
-<blockquote>
-<pre>template &lt;class InputIterator, class ForwardIterator&gt;
-  ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>,
-                                     ForwardIterator <i>result</i>);
-</pre>
-<blockquote>
-<p>
--1- <i>Effects:</i>
-</p>
-<blockquote><pre>for (; first != last; ++result, ++first)
-  new (static_cast&lt;void*&gt;(&amp;*result))
-    typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
-</pre></blockquote>
-<p>
--2- <i>Returns:</i> <tt><i>result</i></tt>
-</p>
-</blockquote>
-</blockquote>
+   </p>
+   <blockquote>
 
-<p>
-similarily for N2369, and its corresponding section
-20.6.4.1 [uninitialized.copy].
-</p>
+The result of operator-&gt; on an end<ins>-</ins>of<ins>-</ins>stream
+is not defined. For any other iterator value a <code>const T*</code>
+is returned.<ins> Invoking <code>operator++()</code> on
+an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
+to store things into istream iterators...
 
-<p>
-It's not clear to me what the return clause is supposed to mean, I see
-two
-possible interpretations:
-</p>
+   </blockquote>
+   <p>
 
-<ol type="a">
-<li>
-The notion of <tt><i>result</i></tt> is supposed to mean the value given by the
-function parameter <tt><i>result</i></tt> [Note to the issue editor: Please use italics for
-<tt><i>result</i></tt>].
-This seems somewhat implied by recognizing that both the function
-parameter
-and the name used in the clause do have the same italic font.
-</li>
-<li>
-The notion of "result" is supposed to mean the value of <tt><i>result</i></tt>
-after the
-preceding effects clause. This is in fact what all implementations I
-checked
-do (and which is probably it's intend, because it matches the
-specification of <tt>std::copy</tt>).
-</li>
-</ol>
+Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
 
-<p>
-The problem is: I see nothing in the standard which grants that this
-interpretation
-is correct, specifically [lib.structure.specifications] or
-17.3.1.3 [structure.specifications]
-resp. do not clarify which "look-up" rules apply for names found in
-the elements
-of the detailed specifications - Do they relate to the corresponding
-synopsis or
-to the effects clause (or possibly other elements)? Fortunately most
-detailed
-descriptions are unambigious in this regard, e.g. this problem does
-not apply
-for <tt>std::copy</tt>.
-</p>
+   </p>
+   <blockquote>
 
+<pre>istream_iterator();</pre>
 
+<i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
+<ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the wording of the return clause to say (20.6.4.1 [uninitialized.copy]):
-</p>
+<pre>istream_iterator(istream_type &amp;s);</pre>
 
-<blockquote>
-<p>
--2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins>
-</p>
-</blockquote>
+<i>Effects</i>: Initializes <code>in_stream</code> with &amp;s. value
+may be initialized during construction or the first time it is
+referenced.<br>
+<ins><i>Postcondition</i>: <code>in_stream == &amp;s</code>.</ins>
+
+<pre>istream_iterator(const istream_iterator &amp;x);</pre>
+
+<i>Effects</i>: Constructs a copy of <code>x</code>.<br>
+<ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
 
+<pre>istream_iterator&amp; operator++();</pre>
 
+<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
+<i>Effects</i>: <code>*in_stream &gt;&gt; value</code>.
+
+<pre>istream_iterator&amp; operator++(int);</pre>
+
+<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
+<i>Effects</i>:
+   <blockquote><pre>istream_iterator tmp (*this);
+*in_stream &gt;&gt; value;
+return tmp;
+     </pre>
+     </blockquote>
+   </blockquote>
+ 
 
 
 
diff --git a/libstdc++-v3/doc/html/ext/lwg-closed.html b/libstdc++-v3/doc/html/ext/lwg-closed.html
index 52184fb805e00b70a4121a90cc8482c5438931bf..68bca503aa2b1112f5750847ed7801af5e0db79d 100644
--- a/libstdc++-v3/doc/html/ext/lwg-closed.html
+++ b/libstdc++-v3/doc/html/ext/lwg-closed.html
@@ -12,11 +12,11 @@ del {background-color:#FFA0A0}
 <table>
 <tbody><tr>
 <td align="left">Doc. no.</td>
-<td align="left">N2458=07-0328</td>
+<td align="left">N2614=08-0124</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">2007-10-20</td>
+<td align="left">2008-05-18</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -27,7 +27,7 @@ del {background-color:#FFA0A0}
 <td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
 </tr>
 </tbody></table>
-<h1>C++ Standard Library Closed Issues List (Revision R52)</h1>
+<h1>C++ Standard Library Closed Issues List (Revision R56)</h1>
 
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
@@ -49,6 +49,89 @@ del {background-color:#FFA0A0}
 
 <h2>Revision History</h2>
 <ul>
+<li>R56: 
+2008-05-16 pre-Sophia Antipolis mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>191 open issues, up by 24.</li>
+<li>647 closed issues, up by 1.</li>
+<li>838 issues total, up by 25.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="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>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>
+</li>
+<li>R55: 
+2008-03-14 post-Bellevue mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>167 open issues, down by 39.</li>
+<li>646 closed issues, up by 65.</li>
+<li>813 issues total, up by 26.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
+<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>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>
+<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</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-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</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#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
+<li>Changed the following issues from 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 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 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 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>
+<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R54: 
+2008-02-01 pre-Bellevue mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>206 open issues, up by 23.</li>
+<li>581 closed issues, up by 0.</li>
+<li>787 issues total, up by 23.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="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>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>
+<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</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#527">527</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R53: 
+2007-12-09 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>183 open issues, up by 11.</li>
+<li>581 closed issues, down by 1.</li>
+<li>764 issues total, up by 10.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="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>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>
+</ul>
+</li>
 <li>R52: 
 2007-10-19 post-Kona mailing.
 <ul>
@@ -58,16 +141,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-active.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-active.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.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-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>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-active.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-active.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-active.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-active.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-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 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-active.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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 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 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 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>
@@ -83,7 +166,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-active.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-active.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-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>
 </ul></li>
 </ul>
 </li>
@@ -96,13 +179,13 @@ del {background-color:#FFA0A0}
 <li>708 issues total, up by 12.</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#697">697</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-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</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-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</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-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</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#528">528</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#637">637</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#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</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#525">525</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#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-active.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-active.html#680">680</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 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>
@@ -123,7 +206,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-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-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 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>
@@ -140,12 +223,12 @@ 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-active.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-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-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>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-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Changed the following issues from 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>
 <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li>
-<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
+<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</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-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
 <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
 <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>
@@ -167,11 +250,11 @@ del {background-color:#FFA0A0}
 <li>656 issues total, up by 37.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#626">626</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-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 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 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-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
+<li>Changed the following issues from 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>
 </ul></li>
 </ul>
@@ -201,7 +284,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-active.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-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#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>
@@ -245,9 +328,9 @@ del {background-color:#FFA0A0}
 <li>574 issues total, up by 8.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
@@ -278,7 +361,7 @@ del {background-color:#FFA0A0}
 <li>535 issues total.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
 </ul></li>
 </ul>
 </li>
@@ -323,12 +406,12 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#
 <li>R31: 
 2004-07 mid-term mailing: reflects new proposed resolutions and
 new issues received after the post-Sydney mailing.  Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
+new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
 </li>
 <li>R30: 
 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 Voted all "Ready" issues from R29 into the working paper.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>.
 </li>
 <li>R29: 
 Pre-Sydney mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
@@ -473,7 +556,7 @@ of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3
 <li>R10: 
 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a> to
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 </li>
 <li>R9: 
@@ -492,7 +575,7 @@ pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
 </li>
 <li>R6: 
-pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
+pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>,
 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 </li>
 <li>R5: 
@@ -1214,6 +1297,7 @@ illegal.&nbsp; See 17.4.4.4 [member.functions] paragraph 2.</p>
 <h3><a name="97"></a>97. Insert inconsistent definition</h3>
 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -1275,7 +1359,7 @@ incorrect code to work, rather than the other way around.</p>
 
 <hr>
 <h3><a name="101"></a>101. No way to free storage for vector and deque</h3>
-<p><b>Section:</b> 23.2.5 [vector], 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 23.2.6 [vector], 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
@@ -1348,10 +1432,13 @@ the Standard.</p>
 
 <hr>
 <h3><a name="105"></a>105. fstream ctors argument types desired</h3>
-<p><b>Section:</b> 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+<p><b>Section:</b> 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a></p>
 <p><b>Discussion:</b></p>
+
+
 <p>fstream ctors take a const char* instead of string.<br>
 fstream ctors can't take wchar_t</p>
 
@@ -1488,12 +1575,15 @@ desired functionality.</p>
 
 <hr>
 <h3><a name="116"></a>116. bitset cannot be constructed with a const char*</h3>
-<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-11-06</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a></p>
 <p><b>Discussion:</b></p>
+
+
+
 <p>The following code does not compile with the EDG compiler:</p>
 
 <blockquote>
@@ -1590,61 +1680,9 @@ ctype&lt;wchar_t&gt; specialization. </p>
 
 
 
-<hr>
-<h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string&nbsp; buffers</h3>
-<p><b>Section:</b> 27.7 [string.streams], 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The following question came from Thorsten Herlemann:</p>
-
-<blockquote>
-  <p>You can set a mode when constructing or opening a file-stream or
-  filebuf, e.g.  ios::in, ios::out, ios::binary, ... But how can I get
-  that mode later on, e.g. in my own operator &lt;&lt; or operator
-  &gt;&gt; or when I want to check whether a file-stream or
-  file-buffer object passed as parameter is opened for input or output
-  or binary? Is there no possibility? Is this a design-error in the
-  standard C++ library? </p>
-</blockquote>
-
-<p>It is indeed impossible to find out what a stream's or stream
-buffer's open mode is, and without that knowledge you don't know
-how certain operations behave. Just think of the append mode. </p>
-
-<p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
-current open mode setting. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>For stream buffers, add a function to the base class as a non-virtual function
-qualified as const to 27.5.2 [streambuf]:</p>
-
-<p>&nbsp;&nbsp;&nbsp;&nbsp;<tt>openmode mode() const</tt>;</p>
-
-<p><b>&nbsp;&nbsp;&nbsp; Returns</b> the current open mode.</p>
-
-<p>With streams, I'm not sure what to suggest. In principle, the mode
-could already be returned by <tt>ios_base</tt>, but the mode is only
-initialized for file and string stream objects, unless I'm overlooking
-anything. For this reason it should be added to the most derived
-stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
-and would be default initialized in <tt>basic_ios&lt;&gt;::init()</tt>.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This might be an interesting extension for some future, but it is
-not a defect in the current standard. The Proposed Resolution is
-retained for future reference.</p>
-
-
-
-
-
 <hr>
 <h3><a name="131"></a>131. list::splice throws nothing</h3>
-<p><b>Section:</b> 23.2.3.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
@@ -1731,10 +1769,10 @@ not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/
 
 <hr>
 <h3><a name="140"></a>140. map&lt;Key, T&gt;::value_type does not satisfy the assignable requirement</h3>
-<p><b>Section:</b> 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+<p><b>Section:</b> 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Mark Mitchell <b>Date:</b> 1999-04-14</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <blockquote>
   <p>23.1 [container.requirements]<br>
@@ -2191,65 +2229,11 @@ ios_base::init to basic_ios::init().)</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#NAD%20Future">NAD Future</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1999-07-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</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
-constness of the iterators. The iterators only serve to give
-positioning information.</p>
-
-<p>Here's a simple and typical example problem which is currently very
-difficult or impossible to solve without the change proposed
-below.</p>
-
-<p>Wrap a standard container C in a class W which allows clients to
-find and read (but not modify) a subrange of (C.begin(), C.end()]. The
-only modification clients are allowed to make to elements in this
-subrange is to erase them from C through the use of a member function
-of W.</p>
-
-
-<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>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>
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The issue was discussed at length. It was generally agreed that 1)
-There is no major technical argument against the change (although
-there is a minor argument that some obscure programs may break), and
-2) Such a change would not break const correctness. The concerns about
-making the change were 1) it is user detectable (although only in
-boundary cases), 2) it changes a large number of signatures, and 3) it
-seems more of a design issue that an out-and-out defect.</p>
-
-<p>The LWG believes that this issue should be considered as part of a
-general review of const issues for the next revision of the
-standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>
-
-
-
-
 <hr>
 <h3><a name="188"></a>188. valarray helpers missing augmented assignment operators</h3>
-<p><b>Section:</b> 26.5.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+<p><b>Section:</b> 26.5.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 1999-08-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>26.5.2.6 defines augmented assignment operators
 valarray&lt;T&gt;::op=(const T&amp;), but fails to provide
@@ -2282,30 +2266,6 @@ operators.</p>
 
 
 
-<hr>
-<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#NAD%20Future">NAD Future</a>
- <b>Submitter:</b> Mark Rintoul <b>Date:</b> 1999-08-26</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#NAD%20Future">NAD Future</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Both std::min and std::max are defined as template functions.  This
-is very different than the definition of std::plus (and similar
-structs) which are defined as function objects which inherit
-std::binary_function.<br>
-<br>
-        This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
-a function object that inherits std::binary_function.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Although perhaps an unfortunate design decision, the omission is not a defect
-in the current standard.&nbsp; A future standard may wish to consider additional
-function objects.</p>
-
-
-
-
 <hr>
 <h3><a name="191"></a>191. Unclear complexity for algorithms such as binary search</h3>
 <p><b>Section:</b> 25.3.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
@@ -3011,6 +2971,8 @@ might reasonably pass an argument that is not Copy Constructible.</p>
 <h3><a name="245"></a>245. Which operations on <tt>istream_iterator</tt> trigger input operations?</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#NAD">NAD</a>
  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</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#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>I do not think the standard specifies what operation(s) on istream
@@ -3977,11 +3939,11 @@ about when terminate() is called; it merely specifies which
 
 <hr>
 <h3><a name="323"></a>323. abs() overloads in different headers</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-04</p>
 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>Currently the standard mandates the following overloads of
 abs():</p>
@@ -4019,6 +3981,16 @@ and int_max_abs.</p>
 
 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#343">343</a>.</p>
 
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+The situation is not sufficiently severe to warrant a change.
+</blockquote>
+
+
 
 
 <p><b>Rationale:</b></p>
@@ -4208,11 +4180,14 @@ consensus in the LWG for action.
 
 <hr>
 <h3><a name="348"></a>348. Minor issue with std::pair operator&lt;</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-10-23</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a></p>
 <p><b>Discussion:</b></p>
+
+
 <p>
 The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
 operator&lt; on any pair type which contains a pointer.
@@ -4253,7 +4228,7 @@ operator&lt; on any pair type which contains a pointer.
 
 <hr>
 <h3><a name="350"></a>350. allocator&lt;&gt;::address</h3>
-<p><b>Section:</b> 20.6.1.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+<p><b>Section:</b> 20.6.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
  <b>Submitter:</b> Nathan Myers <b>Date:</b> 2001-10-25</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
@@ -4371,10 +4346,10 @@ might wish to make the change as editorial.]</i></p>
 
 <hr>
 <h3><a name="353"></a>353. <tt>std::pair</tt> missing template assignment</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-12-02</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 The class template <tt>std::pair</tt> defines a template ctor (20.2.2, p4) but
@@ -4413,6 +4388,13 @@ a design decision, and thus NAD.&nbsp; May be appropriate for a future
 standard.]</i></p>
 
 
+<p><i>[
+Pre Bellevue:  It was recognized that this was taken care of by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>,
+and thus moved from NAD Future to NAD Editorial.
+]</i></p>
+
+
 
 
 
@@ -5109,10 +5091,10 @@ then precisely describe and enforce the precise requirements.
 
 <hr>
 <h3><a name="388"></a>388. Use of complex as a key in associative containers</h3>
-<p><b>Section:</b> 26.3 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+<p><b>Section:</b> 26.3 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 Practice with std::complex&lt;&gt; and the associative containers
@@ -5138,6 +5120,27 @@ containers as an ordering useful to meet complexity requirements.
 
 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</p>
 
+<p><i>[
+Pre Bellevue: Reopened at the request of Alisdair.
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+This is a request for a design change, and not a defect in the standard.
+It is in scope to consider, but the group feels that it is not a change
+that we need to do. Is there a total ordering for floating point values,
+including NaN? There is not a clear enough solution or big enough
+problem for us to solve. Solving this problem would require solving the
+problem for floating point, which is equally unclear. The LWG noted that
+users who want to put objects into an associative container for which
+operator&lt; isn't defined can simply provide their own comparison function
+object. NAD
+</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
@@ -5160,11 +5163,11 @@ provide their own comparison function object.</p>
 
 <hr>
 <h3><a name="390"></a>390. CopyConstructible requirements too strict</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#NAD%20Future">NAD Future</a>
+<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#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Doug Gregor <b>Date:</b> 2002-10-24</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#NAD%20Future">NAD Future</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 The CopyConstructible requirements in Table 30 state that for an
@@ -5295,7 +5298,6 @@ of input iterators.</p>
 <h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3>
 <p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
  <b>Submitter:</b> Alberto Barbati <b>Date:</b> 2002-12-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt.virtuals">active issues</a> in [locale.codecvt.virtuals].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -5401,6 +5403,95 @@ can use alternative signatures that don't call widen.
 
 
 
+<hr>
+<h3><a name="424"></a>424. normative notes</h3>
+<p><b>Section:</b> 17.3.1.1 [structure.summary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+The text in 17.3.1.1, p1 says:
+<br>
+
+"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
+paragraphs are normative."
+<br>
+
+The library section makes heavy use of paragraphs labeled "Notes(s),"
+some of which are clearly intended to be normative (see list 1), while
+some others are not (see list 2). There are also those where the intent
+is not so clear (see list 3).
+<br><br>
+
+List 1 -- Examples of (presumably) normative Notes:
+<br>
+
+20.6.5.1 [allocator.members], p3,<br>
+20.6.5.1 [allocator.members], p10,<br>
+21.3.2 [string.cons], p11,<br>
+22.1.1.2 [locale.cons], p11,<br>
+23.2.2.3 [deque.modifiers], p2,<br>
+25.3.7 [alg.min.max], p3,<br>
+26.3.6 [complex.ops], p15,<br>
+27.5.2.4.3 [streambuf.virt.get], p7.<br>
+<br>
+
+List 2 -- Examples of (presumably) informative Notes:
+<br>
+
+18.5.1.3 [new.delete.placement], p3,<br>
+21.3.6.6 [string::replace], p14,<br>
+22.2.1.4.2 [locale.codecvt.virtuals], p3,<br>
+25.1.1 [alg.foreach], p4,<br>
+26.3.5 [complex.member.ops], p1,<br>
+27.4.2.5 [ios.base.storage], p6.<br>
+<br>
+
+List 3 -- Examples of Notes that are not clearly either normative
+or informative:
+<br>
+
+22.1.1.2 [locale.cons], p8,<br>
+22.1.1.5 [locale.statics], p6,<br>
+27.5.2.4.5 [streambuf.virt.put], p4.<br>
+<br>
+
+None of these lists is meant to be exhaustive.
+</p>
+
+<p><i>[Definitely a real problem.  The big problem is there's material
+  that doesn't quite fit any of the named paragraph categories
+  (e.g. <b>Effects</b>).  Either we need a new kind of named
+  paragraph, or we need to put more material in unnamed paragraphs
+  jsut after the signature.  We need to talk to the Project Editor
+  about how to do this.
+]</i></p>
+
+
+<p><i>[
+Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2,
+22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete
+will handle editorially.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p><i>[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks".
+Fixed as editorial.  This change has been in the WD since the post-Redmond mailing, in 2004.
+Recommend NAD.]</i></p>
+
+<p><i>[
+Batavia:  We feel that the references in List 2 above should be changed from <i>Remarks</i>
+to <i>Notes</i>.  We also feel that those items in List 3 need to be double checked for
+the same change.  Alan and Pete to review.
+]</i></p>
+
+
+
+
+
 <hr>
 <h3><a name="429"></a>429. typo in basic_ios::clear(iostate)</h3>
 <p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
@@ -5770,287 +5861,166 @@ standard facets.
 
 
 <hr>
-<h3><a name="463"></a>463. auto_ptr usability issues</h3>
-<p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
+<h3><a name="462"></a>462. Destroying objects with static storage duration</h3>
+<p><b>Section:</b> 3.6.3 [basic.start.term], 18.3 [cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-03-23</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
-
 <p>
-TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
-member of auto_ptr (20.4.5.3/4) obsolete.
+3.6.3 Termination spells out in detail the interleaving of static
+destructor calls and calls to functions registered with atexit. To
+match this behavior requires intimate cooperation between the code
+that calls destructors and the exit/atexit machinery. The former
+is tied tightly to the compiler; the latter is a primitive mechanism
+inherited from C that traditionally has nothing to do with static
+construction and destruction. The benefits of intermixing destructor
+calls with atexit handler calls is questionable at best, and <i>very</i>
+difficult to get right, particularly when mixing third-party C++
+libraries with different third-party C++ compilers and C libraries
+supplied by still other parties.
 </p>
 
 <p>
-The sole purpose of this obsolete conversion member is to enable copy
-initialization base from r-value derived (or any convertible types like
-cv-types) case:
+I believe the right thing to do is defer all static destruction
+until after all atexit handlers are called. This is a change in
+behavior, but one that is likely visible only to perverse test
+suites. At the very least, we should <i>permit</i> deferred destruction
+even if we don't require it.
 </p>
-<pre>#include &lt;memory&gt;
-using std::auto_ptr;
 
-struct B {};
-struct D : B {};
+<p><i>[If this is to be changed, it should probably be changed by CWG.
+  At this point, however, the LWG is leaning toward NAD.  Implementing
+  what the standard says is hard work, but it's not impossible and
+  most vendors went through that pain years ago.  Changing this
+  behavior would be a user-visible change, and would break at least
+  one real application.]</i></p>
 
-auto_ptr&lt;D&gt; source();
-int sink(auto_ptr&lt;B&gt;);
-int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
-</pre>
 
-<p>
-The excellent analysis of conversion operations that was given in the final
-auto_ptr proposal
-(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
-explicitly specifies this case analysis (case 4). DR #84 makes the analysis
-wrong and actually comes to forbid the loophole that was exploited by the
-auto_ptr designers.
-</p>
+<p><i>[
+Batavia:  Send to core with our recommendation that we should permit deferred
+destruction but not require it.
+]</i></p>
 
-<p>
-I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
-ever allowed this case. This is probably because it requires 3 user defined
-conversions and in fact current compilers conform to DR #84.
-</p>
 
-<p>
-I was surprised to discover that the obsolete conversion member actually has
-negative impact of the copy initialization base from l-value derived
-case:</p>
-<pre>auto_ptr&lt;D&gt; dp;
-int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
-</pre>
+<p><i>[
+Howard:  The course of action recommended in Batavia would undo LWG
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a> and break current code implementing the "phoenix
+singleton". Search the net for "phoenix singleton atexit" to get a feel
+for the size of the adverse impact this change would have.  Below is
+sample code which implements the phoenix singleton and would break if
+<tt>atexit</tt> is changed in this way:
+]</i></p>
 
-<p>
-I'm sure that the original intention was allowing this initialization using
-the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; a) constructor (20.4.5.1/4) but
-since in this copy initialization it's merely user defined conversion (UDC)
-and the obsolete conversion member is UDC with the same rank (for the early
-overloading stage) there is an ambiguity between them.
-</p>
 
-<p>
-Removing the obsolete member will have impact on code that explicitly
-invokes it:
-</p>
-<pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
-</pre>
+<blockquote><pre>#include &lt;cstdlib&gt;
+#include &lt;iostream&gt;
+#include &lt;type_traits&gt;
+#include &lt;new&gt;
 
-<p>
-IMHO no one ever wrote such awkward code and the reasonable workaround for
-#1 is:
-</p>
-<pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
-</pre>
+class A
+{
+    bool alive_;
+    A(const A&amp;);
+    A&amp; operator=(const A&amp;);
+public:
+    A() : alive_(true) {std::cout &lt;&lt; "A()\n";}
+    ~A() {alive_ = false; std::cout &lt;&lt; "~A()\n";}
+    void use()
+    {
+        if (alive_)
+            std::cout &lt;&lt; "A is alive\n";
+        else
+            std::cout &lt;&lt; "A is dead\n";
+    }
+};
 
-<p>
-I was even more surprised to find out that after removing the obsolete
-conversion member the initialization was still ill-formed:
-int x3 = sink(dp); // #3 EDG - no suitable copy constructor
-</p>
+void deallocate_resource();
 
-<p>
-This copy initialization semantically requires copy constructor which means
-that both template conversion constructor and the auto_ptr_ref conversion
-member (20.4.5.3/3) are required which is what was explicitly forbidden in
-DR #84. This is a bit amusing case in which removing ambiguity results with
-no candidates.
-</p>
+// This is the phoenix singleton pattern
+A&amp; get_resource(bool create = true)
+{
+    static std::aligned_storage&lt;sizeof(A), std::alignment_of&lt;A&gt;::value&gt;::type buf;
+    static A* a;
+    if (create)
+    {
+        if (a != (A*)&amp;buf)
+        {
+            a = ::new (&amp;buf) A;
+            std::atexit(deallocate_resource);
+        }
+    }
+    else
+    {
+        a-&gt;~A();
+        a = (A*)&amp;buf + 1;
+    }
+    return *a;
+}
 
-<p>
-I also found exception safety issue with auto_ptr related to auto_ptr_ref:
-</p>
-<pre>int f(auto_ptr&lt;B&gt;, std::string);
-auto_ptr&lt;B&gt; source2();
+void deallocate_resource()
+{
+    get_resource(false);
+}
 
-// string constructor throws while auto_ptr_ref
-// "holds" the pointer
-int x4 = f(source2(), "xyz"); // #4
-</pre>
+void use_A(const char* message)
+{
+    A&amp; a = get_resource();
+    std::cout &lt;&lt; "Using A " &lt;&lt; message &lt;&lt; "\n";
+    a.use();
+}
 
-<p>
-The theoretic execution sequence that will cause a leak:
-</p>
-<ol>
-<li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
-<li>call string::string(char const*) and throw</li>
-</ol>
+struct B
+{
+    ~B() {use_A("from ~B()");}
+};
 
-<p>
-According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
-returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
-the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
-library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; with Y* as member which
-is much more reasonable. Other vendor implemented auto_ptr_ref as
-defectively required and it results with awkward and catastrophic code:
-int oops = sink(auto_ptr&lt;B&gt;(source())); // warning recursive on all control
-paths
-</p>
+B b;
 
-<p>
-Dave Abrahams noticed that there is no specification saying that
-auto_ptr_ref copy constructor can't throw.
-</p>
+int main()
+{
+    use_A("from main()");
+}
+</pre></blockquote>
 
 <p>
-My proposal comes to solve all the above issues and significantly simplify
-auto_ptr implementation. One of the fundamental requirements from auto_ptr
-is that it can be constructed in an intuitive manner (i.e. like ordinary
-pointers) but with strict ownership semantics which yield that source
-auto_ptr in initialization must be non-const. My idea is to add additional
-constructor template with sole propose to generate ill-formed, diagnostic
-required, instance for const auto_ptr arguments during instantiation of
-declaration. This special constructor will not be instantiated for other
-types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
-in hand makes the constructor template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
-legitimate since the actual argument can't be const yet non const r-value
-are acceptable.
+The correct output is:
 </p>
 
-<p>
-This implementation technique makes the "private auxiliary class"
-auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
-GCC and VC) consume the new implementation as expected and allow all
-intuitive initialization and assignment cases while rejecting illegal cases
-that involve const auto_ptr arguments.
-</p>
+<blockquote><pre>A()
+Using A from main()
+A is alive
+~A()
+A()
+Using A from ~B()
+A is alive
+~A()
+</pre></blockquote>
 
-<p>The proposed auto_ptr interface:</p>
+<p><i>[
+Bellevue: Confirmed no interaction with <tt>quick_exit</tt>.
+Strong feeling against mandating the change. Leaning towards NAD rather than permitting the change,
+as this would make common implementations of pheonix-singleton pattern implementation defined, as noted by Howard.
+Bill agrees issue is no longer serious, and accepts NAD.
+]</i></p>
 
-<pre>namespace std {
-    template&lt;class X&gt; class auto_ptr {
-    public:
-        typedef X element_type;
-
-        // 20.4.5.1 construct/copy/destroy:
-        explicit auto_ptr(X* p=0) throw();
-        auto_ptr(auto_ptr&amp;) throw();
-        template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
-        auto_ptr&amp; operator=(auto_ptr&amp;) throw();
-        template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
-        ~auto_ptr() throw();
-
-        // 20.4.5.2 members:
-        X&amp; operator*() const throw();
-        X* operator-&gt;() const throw();
-        X* get() const throw();
-        X* release() throw();
-        void reset(X* p=0) throw();
-
-    private:
-        template&lt;class U&gt;
-        auto_ptr(U&amp; rhs, typename
-unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
-    };
-}
-</pre>
 
-<p>
-One compliant technique to implement the unspecified_error_on_const_auto_ptr
-helper class is using additional private auto_ptr member class template like
-the following:
-</p>
-<pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
 
-template&lt;typename T&gt;
-struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
-{ typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
-</pre>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-There are other techniques to implement this helper class that might work
-better for different compliers (i.e. better diagnostics) and therefore I
-suggest defining its semantic behavior without mandating any specific
-implementation. IMO, and I didn't found any compiler that thinks otherwise,
-14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
-verifying this with core language experts.
 </p>
 
-<p><b>Further changes in standard text:</b></p>
-<p>Remove section 20.4.5.3</p>
 
-<p>Change 20.4.5/2 to read something like:
-Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
-ill-formed declaration that will require unspecified diagnostic.</p>
 
-<p>Change 20.4.5.1/4,5,6 to read:</p>
 
-<pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
-<p> 4 Requires: Y* can be implicitly converted to X*.</p>
-<p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
-<p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
 
-<p>Change 20.4.5.1/10</p>
-<pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
-</pre>
-<p>
-10 Requires: Y* can be implicitly converted to X*. The expression delete
-get() is well formed.
-</p>
-
-<p>LWG TC DR #127 is obsolete.</p>
-
-<p>
-Notice that the copy constructor and copy assignment operator should remain
-as before and accept non-const auto_ptr&amp; since they have effect on the form
-of the implicitly declared copy constructor and copy assignment operator of
-class that contains auto_ptr as member per 12.8/5,10:
-</p>
-<pre>struct X {
-    // implicit X(X&amp;)
-    // implicit X&amp; operator=(X&amp;)
-    auto_ptr&lt;D&gt; aptr_;
-};
-</pre>
-
-<p>
-In most cases this indicates about sloppy programming but preserves the
-current auto_ptr behavior.
-</p>
-
-<p>
-Dave Abrahams encouraged me to suggest fallback implementation in case that
-my suggestion that involves removing of auto_ptr_ref will not be accepted.
-In this case removing the obsolete conversion member to auto_ptr&lt;Y&gt; and
-20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
-cases. The two constructors that I suggested will co exist with the current
-members but will make auto_ptr_ref obsolete in initialization contexts.
-auto_ptr_ref will be effective in assignment contexts as suggested in DR
-#127 and I can't see any serious exception safety issues in those cases
-(although it's possible to synthesize such). auto_ptr_ref&lt;X&gt; semantics will
-have to be revised to say that it strictly holds pointer of type X and not
-reference to an auto_ptr for the favor of cases in which auto_ptr_ref&lt;Y&gt; is
-constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
-from r-value derived to base).
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p><i>[Redmond: punt for the moment. We haven't decided yet whether we
-  want to fix auto_ptr for C++-0x, or remove it and replace it with
-  move_ptr and unique_ptr.]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD.  We're just going to deprecate it.  It still works for simple use cases
-and people know how to deal with it.  Going forward <tt>unique_ptr</tt> is the recommended
-tool.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="466"></a>466. basic_string ctor should prevent null pointer error</h3>
-<p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-06-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
+<hr>
+<h3><a name="466"></a>466. basic_string ctor should prevent null pointer error</h3>
+<p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-06-10</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
 Today, my colleagues and me wasted a lot of time. After some time, I
 found the problem. It could be reduced to the following short example:
@@ -6096,6 +6066,7 @@ Recommend NAD.  Relegate this functionality to debugging implementations.
 <h3><a name="470"></a>470. accessing containers from their elements' special functions</h3>
 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -6564,6 +6535,7 @@ operator that takes a T, or a T may be convertible to the type of *i.
 <h3><a name="486"></a>486. min/max CopyConstructible requirement is too strict</h3>
 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-10-13</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a></p>
@@ -7080,12 +7052,12 @@ change, so there is no real-world harm here.</p>
 
 <hr>
 <h3><a name="491"></a>491. std::list&lt;&gt;::unique incorrectly specified</h3>
-<p><b>Section:</b> 23.2.3.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>In Section 23.2.3.4 [list.ops], paragraphs 19 to 21 describe the
+<p>In Section 23.2.4.4 [list.ops], paragraphs 19 to 21 describe the
 behavior of the std::list&lt;T, Allocator&gt;::unique operation. However, the
 current wording is defective for various reasons.</p>
 
@@ -7095,7 +7067,7 @@ current wording is defective for various reasons.</p>
 1) Analysis of current wording:
 </p>
 
-<p>23.2.3.4 [list.ops], paragraph 19:</p>
+<p>23.2.4.4 [list.ops], paragraph 19:</p>
 
 <p>
 Current wording says:
@@ -7109,7 +7081,7 @@ predicate argument) holds."</p>
 This sentences makes use of the undefined term "Eliminates". Although it
 is, to a certain degree, reasonable to consider the term "eliminate"
 synonymous with "erase", using "Erase" in the first place, as the
-wording of 23.2.3.4 [list.ops], paragraph 15 does, would be clearer.</p>
+wording of 23.2.4.4 [list.ops], paragraph 15 does, would be clearer.</p>
 
 <p>
 The range of the elements referred to by iterator i is "[first + 1,
@@ -7126,7 +7098,7 @@ The same problems as pointed out in DR 202 (equivalence relation / order
 of arguments for pred()) apply to this paragraph.</p>
 
 <p>
-23.2.3.4 [list.ops], paragraph 20:
+23.2.4.4 [list.ops], paragraph 20:
 </p>
 
 <p>
@@ -7143,7 +7115,7 @@ expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
 </p>
 
 <p>
-23.2.3.4 [list.ops], paragraph 21:</p>
+23.2.4.4 [list.ops], paragraph 21:</p>
 
 <p>
 Current wording says:
@@ -7182,7 +7154,7 @@ of DR 202, no impact on current code is expected.</p>
 3) Proposed fixes:</p>
 
 <p>
-Change 23.2.3.4 [list.ops], paragraph 19 to:</p>
+Change 23.2.4.4 [list.ops], paragraph 19 to:</p>
 
 <p>
 "Effect: Erases all but the first element from every consecutive group
@@ -7201,7 +7173,7 @@ wording need also additional review.
 b) "Erases" refers in the author's opinion unambiguously to the member
 function "erase". In case there is doubt this might not be unamgibuous,
 a direct reference to the member function "erase" is suggested [Note:
-This would also imply a change of 23.2.3.4 [list.ops], paragraph
+This would also imply a change of 23.2.4.4 [list.ops], paragraph
 15.].
 c) The expression "(i - 1)" was left, but is expected that DR submitted
 by Thomas Mang regarding invalid iterator arithmetic expressions will
@@ -7221,7 +7193,7 @@ elements consists of only a single element, this element is also
 considered the first element."</p>
 
 <p>
-Change 23.2.3.4 [list.ops], paragraph 20 to:</p>
+Change 23.2.4.4 [list.ops], paragraph 20 to:</p>
 
 <p>
 "Throws: Nothing unless an exception is thrown by *(i-1) == *i or
@@ -7232,7 +7204,7 @@ Comments to the new wording:</p>
 
 <p>
 a) The wording regarding the conditions is identical to proposed
-23.2.3.4 [list.ops], paragraph 19. If 23.2.3.4 [list.ops],
+23.2.4.4 [list.ops], paragraph 19. If 23.2.4.4 [list.ops],
 paragraph 19 is resolved in another way, the proposed wording need also
 additional review.
 b) The expression "(i - 1)" was left, but is expected that DR submitted
@@ -7241,7 +7213,7 @@ take this into account.
 c) Typos fixed.</p>
 
 <p>
-Change 23.2.3.4 [list.ops], paragraph 21 to:</p>
+Change 23.2.4.4 [list.ops], paragraph 21 to:</p>
 
 <p>
 "Complexity: If empty() == false, exactly size() - 1 applications of the
@@ -7659,6 +7631,7 @@ Marc supports having min and max to satisfy generic programming interface.
 <h3><a name="509"></a>509. Uniform_int template parameters</h3>
 <p><b>Section:</b> 26.4.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
  <b>Submitter:</b> Walter Brown <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#rand.dist.uni">issues</a> in [rand.dist.uni].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
@@ -8416,11 +8389,106 @@ chapter 17 wording.
 
 
 
+<hr>
+<h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3>
+<p><b>Section:</b> 17.4.3.9 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-10-25</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+17.4.3.8/1 says:
+</p>
+
+<blockquote><p>
+Violation of the preconditions specified in a function's 
+Required behavior: paragraph results in undefined behavior unless the 
+function's Throws: paragraph specifies throwing an exception when the 
+precondition is violated.
+</p></blockquote>
+
+<p>
+This implies that a precondition violation can lead to defined
+behavior.  That conflicts with the only reasonable definition of
+precondition: that a violation leads to undefined behavior.  Any other
+definition muddies the waters when it comes to analyzing program
+correctness, because precondition violations may be routinely done in
+correct code (e.g. you can use std::vector::at with the full
+expectation that you'll get an exception when your index is out of
+range, catch the exception, and continue).  Not only is it a bad
+example to set, but it encourages needless complication and redundancy
+in the standard.  For example:
+</p>
+
+<blockquote><pre>  21 Strings library 
+  21.3.3 basic_string capacity
+
+  void resize(size_type n, charT c);
+
+  5 Requires: n &lt;= max_size()
+  6 Throws: length_error if n &gt; max_size().
+  7 Effects: Alters the length of the string designated by *this as follows:
+</pre></blockquote>
+
+<p>
+The Requires clause is entirely redundant and can be dropped.  We
+could make that simplifying change (and many others like it) even
+without changing 17.4.3.8/1; the wording there just seems to encourage
+the redundant and error-prone Requires: clause.
+</p>
+
+<p><i>[
+Batavia:  Alan and Pete to work.
+]</i></p>
+
+
+<p><i>[
+Bellevue:  NAD Editorial, this group likes 
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>,
+Pete agrees, accepting it is Pete's business.
+General agreement that precondition violations are synonymous with UB.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+1. Change 17.4.3.8/1 to read:
+</p>
+
+<blockquote><p>
+Violation of the preconditions specified in a function's
+<i>Required behavior:</i> paragraph results in undefined behavior
+<del>unless the function's <i>Throws:</i> paragraph specifies throwing
+an exception when the precondition is violated</del>.
+</p></blockquote>
+
+<p>
+2. Go through and remove redundant Requires: clauses.  Specifics to be
+   provided by Dave A.
+</p>
+
+<p><i>[
+Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution.
+]</i></p>
+
+
+<p><i>[
+Alan provided the survey
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>.
+]</i></p>
+
+
+
+
+
+
+
 <hr>
 <h3><a name="532"></a>532. Tuple comparison</h3>
-<p><b>Section:</b> 20.3.1.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 20.3.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
  <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-11-29</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a></p>
 <p><b>Discussion:</b></p>
 <p>
 Where possible, tuple comparison operators &lt;,&lt;=,=&gt;, and &gt; ought to be
@@ -8844,6 +8912,97 @@ Redmond:  Editorial.
 
 
 
+<hr>
+<h3><a name="557"></a>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3>
+<p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+ <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-06</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
+long long we end up, essentially, with the same arguments and different
+return types (lldiv_t and imaxdiv_t, respectively). Similar issue with
+abs(_Longlong) and abs(intmax_t), of course.
+</p>
+<p>
+Comparing sections 8.25 and 8.11, I see an important difference,
+however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong
+types (rightfully, because not moved over directly from C99), whereas
+there is no equivalent in 8.11: the abs and div overloads for intmax_t
+types appear only in the synopsis and are not described anywhere, in
+particular no mention in 8.11.2 (at variance with 8.25.2).
+</p>
+<p>
+I'm wondering whether we really, really, want div and abs for intmax_t...
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+<p><i>[
+Portland: no consensus.
+]</i></p>
+
+
+<p><b>Rationale:</b></p>
+<p><i>[
+Batavia, Bill: The <tt>&lt;cstdint&gt;</tt> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains:
+]</i></p>
+
+<blockquote><pre>intmax_t imaxabs(intmax_t i);
+intmax_t abs(intmax_t i);
+
+imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
+imaxdiv_t div(intmax_t numer, intmax_t denom);
+</pre></blockquote>
+
+<p><i>[
+and in TR1 8.11.2 [tr.c99.cinttypes.def]:
+]</i></p>
+
+
+<blockquote><p>
+The header defines all functions, types, and macros the same as C99
+subclause 7.8.
+</p></blockquote>
+
+<p><i>[
+This is as much definition as we give for most other C99 functions,
+so nothing need change. We might, however, choose to add the footnote:
+]</i></p>
+
+
+<blockquote><p>
+[<i>Note:</i> These overloads for <tt>abs</tt> and <tt>div</tt> may well be equivalent to
+those that take <tt>long long</tt> arguments. If so, the implementation is
+responsible for avoiding conflicting declarations. -- <i>end note</i>]
+</p></blockquote>
+
+<p><i>[
+Bellevue: NAD Editorial. Pete must add a footnote, as described below.
+]</i></p>
+
+
+<blockquote>
+<p><i>[
+Looks like a real problem. Dietmar suggests div() return a template
+type. Matt: looks like imaxdiv_t is loosly defined. Can it be a typedef
+for lldiv_t when _Longlong == intmax_t? PJP seems to agree. We would
+need a non-normative note declaring that the types lldiv_t and imaxdiv_t
+may not be unique if intmax_t==_longlong.
+]</i></p>
+
+</blockquote>
+
+
+
+
+
+
 <hr>
 <h3><a name="558"></a>558. lib.input.iterators Defect</h3>
 <p><b>Section:</b> 24.1.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
@@ -9142,6 +9301,93 @@ is adopted.
 
 
 
+<hr>
+<h3><a name="579"></a>579. erase(iterator) for unordered containers should not return an iterator</h3>
+<p><b>Section:</b> 23.1.3 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2006-06-13</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+See
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
+for full discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Option 1:
+</p>
+
+<p>
+The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an 
+iterator. This is, however, in contrast with the equivalent requirements for other 
+standard containers.
+</p>
+
+<p>
+Option 2:
+</p>
+
+<p>
+<tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested: 
+the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so 
+that
+</p>
+
+<blockquote><pre>iterator q1=a.erase(q);
+</pre></blockquote>
+
+<p>
+works as expected, while
+</p>
+
+<blockquote><pre>a.erase(q);
+</pre></blockquote>
+
+<p>
+does not ever invoke the conversion-to-iterator operator, thus avoiding the associated 
+computation. To allow this technique, some sections of TR1 along the line "return value 
+is an iterator..." should be changed to "return value is an unspecified object implicitly 
+convertible to an iterator..." Although this trick is expected to work transparently, it can 
+have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic 
+code.
+</p>
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
+was discussed in Portland and the consensus was that there appears to be
+no need for either change proposed in the paper.  The consensus opinion
+was that since the iterator could serve as its own proxy, there appears
+to be no need for the change. In general, "converts to" is undesirable
+because it interferes with template matching.
+</p>
+
+<p>
+Post Toronto:  There does not at this time appear to be consensus with the Portland consensus. 
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+The Bellevue review of this issue reached consensus with the Portland
+consensus, in contravention of the Toronto non-consensus. Common
+implementations have the iterator readily available, and most common
+uses depend on the iterator being returned.
+</blockquote>
+
+
+
+
+
+
 <hr>
 <h3><a name="583"></a>583. div() for unsigned integral types</h3>
 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
@@ -9598,69 +9844,270 @@ Recommend NAD, editorial.  Send to Pete.
 
 
 <hr>
-<h3><a name="633"></a>633. Return clause mentions undefined "type()"</h3>
-<p><b>Section:</b> 20.5.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-20.5.15.2.5 [func.wrap.func.targ], p4 says:
-</p>
-<blockquote><p>
-<i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored
-function target; otherwise a null pointer.
-</p></blockquote>
+        <p>
 
-<ol>
-<li>
-There exists neither a type, a typedef <tt>type</tt>, nor member
-function <tt>type()</tt> in class template function nor in the global or
-<tt>std</tt> namespace.
-</li>
-<li>
-Assuming that <tt>type</tt> should have been <tt>target_type()</tt>,
-this description would lead to false results, if <tt>T = <i>cv</i>
-void</tt> due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1.
-</li>
-</ol>
+Many  member functions  of  <code>basic_string</code> are  overloaded,
+with  some of  the  overloads taking  a <code>string</code>  argument,
+others  <code>value_type*</code>,  others <code>size_type</code>,  and
+others still <code>iterators</code>. Often, the requirements on one of
+the   overloads  are   expressed  in   the  form   of  <i>Effects</i>,
+<i>Throws</i>,      and     in      the     Working      Paper     
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
+also <i>Remark</i> clauses,  while those on the rest  of the overloads
+via a reference to this overload and using a <i>Returns</i> clause.
+
+        </p><p>
+        </p>
 
+The  difference between  the two  forms of  specification is  that per
+17.3.1.3 [structure.specifications],  p3,  an  <i>Effects</i> clause  specifies
+<i>"actions  performed  by the  functions,"</i>  i.e., its  observable
+effects,  while a <i>Returns</i>  clause is  <i>"a description  of the
+return  value(s)   of  a  function"</i>  that  does   not  impose  any
+requirements on the function's observable effects.
 
+        <p>
+        </p>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.5.15.2.5 [func.wrap.func.targ], p4:
-</p>
+Since only  <i>Notes</i> are explicitly defined to  be informative and
+all  other paragraphs  are explicitly  defined to  be  normative, like
+<i>Effects</i> and <i>Returns</i>,  the new <i>Remark</i> clauses also
+impose normative requirements.
 
-<blockquote><p>
-<i>Returns:</i> If <tt><del>type()</del> <ins>target_type()</ins> == typeid(T) <ins>&amp;&amp; typeid(T) !=
-typeid(void)</ins></tt>, a pointer to the stored function target;
-otherwise a null pointer.
-</p></blockquote>
+        <p>
+        </p>
 
-<p><i>[
-Pete: Agreed. It's editorial, so I'll fix it.
-]</i></p>
+So  by this  strict  reading of  the  standard there  are some  member
+functions of  <code>basic_string</code> that are required  to throw an
+exception under  some conditions or use specific  traits members while
+many other otherwise equivalent overloads, while obliged to return the
+same  values, aren't required  to follow  the exact  same requirements
+with regards to the observable effects.
 
+        <p>
+        </p>
 
+Here's an example of this  problem that was precipitated by the change
+from informative Notes to normative <i>Remark</i>s (presumably made to
+address <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>):
 
+        <p>
+        </p>
 
+In the Working  Paper, <code>find(string, size_type)</code> contains a
+<i>Remark</i>  clause (which  is  just a  <i>Note</i>  in the  current
+standard) requiring it to use <code>traits::eq()</code>.
 
+        <p>
+        </p>
 
+<code>find(const  charT  *s,  size_type  pos)</code> is  specified  to
+return  <code>find(string(s), pos)</code>  by a  <i>Returns</i> clause
+and so  it is not required to  use <code>traits::eq()</code>. However,
+the Working  Paper has  replaced the original  informative <i>Note</i>
+about   the  function   using  <code>traits::length()</code>   with  a
+normative  requirement  in  the   form  of  a  <i>Remark</i>.  Calling
+<code>traits::length()</code> may be  suboptimal, for example when the
+argument is a  very long array whose initial  substring doesn't appear
+anywhere in <code>*this</code>.
 
-<hr>
-<h3><a name="636"></a>636. 26.5.2.3 valarray::operator[]</h3>
-<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The signature of the const operator[] has been changed to return a const 
-reference.
-</p>
-<p>
-The description in paragraph 1 still says that the operator returns by 
-value.
+        <p>
+        </p>
+
+Here's another  similar example,  one that existed  even prior  to the
+introduction of <i>Remark</i>s:
+
+        <p>
+        </p>
+
+<code> insert(size_type  pos, string, size_type,  size_type)</code> is
+required   to   throw   <code>out_of_range</code>   if   <code>pos   &gt;
+size()</code>.
+
+        <p>
+        </p>
+
+<code>insert(size_type pos, string  str)</code> is specified to return
+<code>insert(pos, str, 0, npos)</code>  by a <i>Returns</i> clause and
+so its  effects when <code>pos  &gt; size()</code> are  strictly speaking
+unspecified.
+
+        
+        <p>
+
+I  believe  a  careful   review  of  the  current  <i>Effects</i>  and
+<i>Returns</i>  clauses  is  needed  in  order to  identify  all  such
+problematic cases. In  addition, a review of the  Working Paper should
+be done to make sure that the newly introduced normative <i>Remark</i>
+clauses do not impose  any undesirable normative requirements in place
+of the original informative <i>Notes</i>.
+
+        </p>
+<p><i>[
+Batavia:  Alan and Pete to work.
+]</i></p>
+
+
+<p><i>[
+Bellevue:  Marked as NAD Editorial.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="626"></a>626. new <i>Remark</i> clauses not documented</h3>
+<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+        <p>
+
+The <i>Remark</i> clauses newly  introduced into the Working Paper 
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
+are  not mentioned  in  17.3.1.3 [structure.specifications] where  we list  the
+meaning  of <i>Effects</i>, <i>Requires</i>,  and other  clauses (with
+the exception  of <i>Notes</i> which are documented  as informative in
+17.3.1.1 [structure.summary], p2, and which they replace in many cases).
+
+        </p>
+        <p>
+
+Propose add a bullet for <i>Remarks</i> along with a brief description.
+
+        </p>
+<p><i>[
+Batavia:  Alan and Pete to work.
+]</i></p>
+
+
+<p><i>[
+Bellevue: Already resolved in current working paper.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="627"></a>627. Low memory and exceptions</h3>
+<p><b>Section:</b> 18.5.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-01-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I recognize the need for nothrow guarantees in the exception reporting
+mechanism, but I strongly believe that implementors also need an escape hatch
+when memory gets really low. (Like, there's not enough heap to construct and
+copy exception objects, or not enough stack to process the throw.) I'd like to
+think we can put this escape hatch in 18.5.1.1 [new.delete.single],
+<tt>operator new</tt>, but I'm not sure how to do it. We need more than a
+footnote, but the wording has to be a bit vague. The idea is that if
+<tt>new</tt> can't allocate something sufficiently small, it has the right to
+<tt>abort</tt>/call <tt>terminate</tt>/call <tt>unexpected</tt>.
+</p>
+
+<p><i>[
+Bellevue: NAD.  1.4p2 specifies a program must behave correctly "within
+its resource limits", so no further escape hatch is necessary.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="633"></a>633. Return clause mentions undefined "type()"</h3>
+<p><b>Section:</b> 20.5.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-03</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+20.5.15.2.5 [func.wrap.func.targ], p4 says:
+</p>
+<blockquote><p>
+<i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored
+function target; otherwise a null pointer.
+</p></blockquote>
+
+<ol>
+<li>
+There exists neither a type, a typedef <tt>type</tt>, nor member
+function <tt>type()</tt> in class template function nor in the global or
+<tt>std</tt> namespace.
+</li>
+<li>
+Assuming that <tt>type</tt> should have been <tt>target_type()</tt>,
+this description would lead to false results, if <tt>T = <i>cv</i>
+void</tt> due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1.
+</li>
+</ol>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.5.15.2.5 [func.wrap.func.targ], p4:
+</p>
+
+<blockquote><p>
+<i>Returns:</i> If <tt><del>type()</del> <ins>target_type()</ins> == typeid(T) <ins>&amp;&amp; typeid(T) !=
+typeid(void)</ins></tt>, a pointer to the stored function target;
+otherwise a null pointer.
+</p></blockquote>
+
+<p><i>[
+Pete: Agreed. It's editorial, so I'll fix it.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="636"></a>636. 26.5.2.3 valarray::operator[]</h3>
+<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-11</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The signature of the const operator[] has been changed to return a const 
+reference.
+</p>
+<p>
+The description in paragraph 1 still says that the operator returns by 
+value.
 </p>
 <p><i>[
 Pete recommends editorial fix.
@@ -9862,6 +10309,7 @@ input functions because that applies to the case in which badbit is set.
 <h3><a name="641"></a>641. Editorial fix for 27.6.4 (N2134)</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#NAD%20Editorial">NAD Editorial</a>
  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-18</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#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -9962,6 +10410,113 @@ In 27.8.1.13 [ofstream.members], remove footnote:
 
 
 
+<hr>
+<h3><a name="645"></a>645. Missing members in match_results</h3>
+<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+According to the description given in 28.10 [re.results]/2 the class template
+match_results "shall satisfy the requirements of a Sequence, [..],
+except that only operations defined for const-qualified Sequences
+are supported".
+Comparing the provided operations from 28.10 [re.results]/3 with the
+sequence/container tables 80 and 81 one recognizes the following
+missing operations:
+</p>
+
+<p>
+1) The members
+</p>
+
+<blockquote><pre>const_iterator rbegin() const;
+const_iterator rend() const;
+</pre></blockquote>
+
+<p>
+should exists because 23.1/10 demands these for containers
+(all sequences are containers) which support bidirectional
+iterators. Aren't these supported by match_result? This is not
+explicitely expressed, but it's somewhat implied by two arguments:
+</p>
+<p>
+(a) Several typedefs delegate to
+<tt>iterator_traits&lt;BidirectionalIterator&gt;</tt>.
+</p>
+<p>
+(b) The existence of <tt>const_reference operator[](size_type n) const</tt>
+implies even random-access iteration.
+I also suggest, that <tt>match_result</tt> should explicitly mention,
+which minimum iterator category is supported and if this does
+not include random-access the existence of <tt>operator[]</tt> is
+somewhat questionable.
+</p>
+<p>
+2) The new "convenience" members
+</p>
+<blockquote><pre>const_iterator cbegin() const;
+const_iterator cend() const;
+const_iterator crbegin() const;
+const_iterator crend() const;
+</pre></blockquote>
+<p>
+should be added according to tables 80/81.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.10 [re.results]
+para 3:
+</p>
+
+<blockquote><pre>const_iterator cbegin() const; 
+const_iterator cend() const;
+</pre></blockquote>
+
+<p>
+In section 28.10.3 [re.results.acc] change:
+</p>
+
+<blockquote>
+<pre>const_iterator begin() const;
+<ins>const_iterator cbegin() const;</ins>
+</pre>
+<blockquote>
+<p>
+-7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
+</p>
+</blockquote>
+
+<pre>const_iterator end() const;
+<ins>const_iterator cend() const;</ins>
+</pre>
+<blockquote>
+<p>
+-8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+<p><i>[
+Kona (2007): Voted to adopt proposed wording in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>
+except removing the entry in the table container requirements.  Moved to Review.
+]</i></p>
+
+
+<p><i>[
+Bellevue:  Proposed wording now in the WP.
+]</i></p>
+
+
+
+
+
 <hr>
 <h3><a name="647"></a>647. Inconsistent regex_search params</h3>
 <p><b>Section:</b> 28.11.3 [re.alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
@@ -10178,6 +10733,92 @@ constructor sets <tt>*this</tt> to an end-of-sequence iterator.
 
 
 
+<hr>
+<h3><a name="653"></a>653. Library reserved names</h3>
+<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-03-08</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+</p>
+<blockquote>
+<p>
+1.2 [intro.refs] Normative references
+</p>
+
+<p>
+The following standards contain provisions which, through reference in
+this text, constitute provisions of this Interna- tional Standard. At
+the time of publication, the editions indicated were valid. All
+standards are subject to revision, and parties to agreements based on
+this International Standard are encouraged to investigate the
+possibility of applying the most recent editions of the standards
+indicated below. Members of IEC and ISO maintain registers of currently
+valid International Standards.
+</p>
+
+<ul>
+<li>Ecma International, ECMAScript Language Specification, Standard
+Ecma-262, third edition, 1999.</li>
+<li>ISO/IEC 2382 (all parts), Information technology - Vocabulary</li>
+<li>ISO/IEC 9899:1990, Programming languages - C</li>
+<li>ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C
+Integrity</li>
+<li>ISO/IEC 9899:1999, Programming languages - C</li>
+<li>ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C</li>
+<li>ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C</li>
+<li>ISO/IEC 9945:2003, Information Technology-Portable Operating System
+Interface (POSIX)</li>
+<li>ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet
+Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual
+Plane</li>
+</ul>
+</blockquote>
+
+<p>
+I'm not sure how many of those reserve naming patterns that might affect
+us, but I am equally sure I don't own a copy of any of these to check!
+</p>
+<p>
+The point is to list the reserved naming patterns, rather than the
+individual names themselves - although we may want to list C keywords
+that are valid identifiers in C++ but likely to cause trouble in shared
+headers (e.g. restrict)
+</p>
+
+<p><i>[
+Kona (2007): Recommend NAD.  No one has identified a specific defect, just the possibility of one.
+]</i></p>
+
+
+<p><i>[
+Post-Kona: Alisdair request Open. A good example of the problem was a
+discussion of the system error proposal, where it was pointed out an all-caps
+identifier starting with a capital E conflicted with reserved macro names for
+both Posix and C.  I had absolutely no idea of this rule, and suspect I was
+not the only one in the room.<br>
+<br>
+Resolution will require someone with access to all the listed documents to
+research their respective name reservation rules, or people with access to
+specific documents add their rules to this issue until the list is complete.
+]</i></p>
+
+
+<p><i>[
+Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording.
+Suggest a formal paper rather than a defect report is the correct way to proceed.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
 <hr>
 <h3><a name="656"></a>656. Typo in subtract_with_carry_engine declaration</h3>
 <p><b>Section:</b> 26.4.2 [rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
@@ -10585,15 +11226,168 @@ Yep, looks like a typo/administrative fix to me.
 
 
 <hr>
-<h3><a name="690"></a>690. abs(long long) should return long long</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-06-10</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
+<h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3>
+<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Quoting the latest draft (n2135), 26.7 [c.math]: 
+In 28.4 [re.syn] of N2284, two template functions 
+are declared here: 
+</p>
+<blockquote><pre>// 28.10, class template match_results: 
+  &lt;<i>snip</i>&gt;
+// match_results comparisons 
+  template &lt;class BidirectionalIterator, class Allocator&gt; 
+    bool operator== (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
+                     const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2); 
+  template &lt;class BidirectionalIterator, class Allocator&gt; 
+    bool operator!= (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
+                     const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2); 
+
+// 28.10.6, match_results swap:
+</pre></blockquote>
+
+<p>
+But the details of these two bool operator functions (i.e., which members of
+<tt>match_results</tt> should be used in comparison) are not described in any
+following sections.
+</p>
+
+<p><i>[
+John adds:
+]</i></p>
+
+
+<blockquote><p>
+That looks like a bug: <tt>operator==</tt> should return <tt>true</tt> only if
+the two objects refer to the same match - ie if one object was constructed as a
+copy of the other.
+</p></blockquote>
+
+<p><i>[
+Kona (2007): Bill and Pete to add minor wording to that proposed in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a new section after 28.10.6 [re.results.swap], which reads:
+</p>
+<p>
+28.10.7 match_results non-member functions.
+</p>
+
+<blockquote>
+<pre>template&lt;class BidirectionalIterator, class Allocator&gt; 
+  bool operator==(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
+                  const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match.
+</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>template&lt;class BidirectionalIterator, class Allocator&gt; 
+  bool operator!=(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
+                  const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>!(m1 == m2)</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>template&lt;class BidirectionalIterator, class Allocator&gt; 
+  void swap(match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
+            match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>m1.swap(m2)</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+<p><i>[
+Bellevue:  Proposed wording now in WP.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="686"></a>686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type</h3>
+<p><b>Section:</b> 20.6.11.2.4 [unique.ptr.single.observers], 20.6.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-06-14</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in
+five places. In three of those places (20.5.15.2.3 [func.wrap.func.cap], function capacity 
+for example) the returned value is constrained to disallow
+unintended conversions to int. The standardese is
+</p>
+<blockquote><p>
+The return type shall not be convertible to <tt>int</tt>.
+</p></blockquote>
+<p>
+This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Close as NAD. Accepting paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a>
+makes it irrelevant.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>()
+const</tt>
+of 20.6.11.2.4 [unique.ptr.single.observers] paragraph 11 and
+20.6.12.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence:
+</p>
+<blockquote><p>
+The return type shall not be convertible to <tt>int</tt>.
+</p></blockquote>
+
+
+<p><i>[
+Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="690"></a>690. abs(long long) should return long long</h3>
+<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-06-10</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Quoting the latest draft (n2135), 26.7 [c.math]: 
 </p>
 
 <blockquote>
@@ -10624,4 +11418,1893 @@ Had already been fixed in the WP by the time the LWG reviewed this.
 
 
 
+<hr>
+<h3><a name="697"></a>697. New <tt>&lt;system_error&gt;</tt> header leads to name clashes</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#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-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#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The most recent state of 
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>
+as well as the current draft
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
+(section 19.4 [syserr], p.2) proposes a
+new
+enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
+the enumerators has the name <tt>invalid_argument</tt>, or fully qualified:
+<tt>std::invalid_argument</tt>. This name clashes with the exception type
+<tt>std::invalid_argument</tt>, see 19.1 [std.exceptions]/p.3. This clash makes
+e.g. the following snippet invalid:
+</p>
+
+<blockquote><pre>#include &lt;system_error&gt;
+#include &lt;stdexcept&gt;
+
+void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
+</pre></blockquote>
+
+<p>
+I propose that this enumeration type (and probably the remaining parts
+of
+<tt>&lt;system_error&gt;</tt> as well) should be moved into one additional inner
+namespace, e.g. <tt>sys</tt> or <tt>system</tt> to reduce foreseeable future clashes
+due
+to the great number of members that <tt>std::posix_errno</tt> already contains
+(Btw.: Why has the already proposed <tt>std::sys</tt> sub-namespace from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a>
+been rejected?). A further clash <em>candidate</em> seems to be
+<tt>std::protocol_error</tt>
+(a reasonable name for an exception related to a std network library,
+I guess).
+</p>
+
+<p>
+Another possible resolution would rely on the proposed strongly typed
+enums,
+as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2213.pdf">N2213</a>.
+But maybe the forbidden implicit conversion to integral types would
+make
+these enumerators less attractive in this special case?
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422.htm#Issue7">issue 7 of N2422</a>.
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="707"></a>707. null pointer constant for <tt>exception_ptr</tt></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#NAD">NAD</a>
+ <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-07-20</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+From the Toronto Core wiki:
+</p>
+
+<p>
+What do you mean by "null pointer constant"? How do you guarantee that
+<tt>exception_ptr() == 1</tt> doesn't work?  Do you even want to prevent that?
+What's the semantics?  What about <tt>void *p = 0; exception_ptr() == p</tt>?
+Maybe disallow those in the interface, but how do you do that with
+portable C++? Could specify just "make it work".
+</p>
+
+<p>
+Peter's response:
+</p>
+
+<p>
+null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it
+work", can be implemented as assignment operator taking a unique pointer
+to member, as in the unspecified bool type idiom.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Original implementation was possible using the "unspecified-null-pointer" idiom, similar to unspecified-bool.
+</p>
+<p>
+Even simpler now with nullptr_t.
+</p>
+<p>
+NAD Rationale : null pointer constant is a perfectly defined term, and
+while API is clearly implementable there is no need to spell out
+implementation details.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3>
+<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The changes made for <tt>constexpr</tt> in 21.1.3 [char.traits.specializations] have 
+not only changed the <tt>not_eof</tt> function from pass by const reference to 
+pass by value, it has also changed the parameter type from <tt>int_type</tt> to 
+<tt>char_type</tt>.
+</p>
+<p>
+This doesn't work for type <tt>char</tt>, and is inconsistent with the 
+requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require].
+</p>
+
+<p>
+Pete adds:
+</p>
+
+<blockquote><p>
+For what it's worth, that may not have been an intentional change. 
+N2349, which detailed the changes for adding constant expressions to 
+the library, has strikeout bars through the <tt>const</tt> and the <tt>&amp;</tt> that 
+surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself. 
+So the intention may have been just to change to pass by value, with 
+text incorrectly copied from the standard.
+</p></blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the signature in 21.1.3.1 [char.traits.specializations.char],
+21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t],
+and 21.1.3.4 [char.traits.specializations.wchar.t] to
+</p>
+
+<blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c);
+</pre></blockquote>
+
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Resolution: NAD editorial - up to Pete's judgment
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="717"></a>717. Incomplete <tt>valarray::operator[]</tt> specification in [valarray.access]</h3>
+<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been
+changed to <tt>const T&amp;</tt> as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> several paragraphs of
+the section 26.5.2.3 [valarray.access] are now
+incompletely
+specified, because many requirements and guarantees should now also
+apply to the const overload. Most notably, the address and reference
+guarantees should be extended to the const overload case.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.5.2.3 [valarray.access]:
+</p>
+
+<blockquote>
+<p>
+-1- <del>When applied to a constant array, the subscript operator returns a
+reference to the corresponding element of the array. When applied to a
+non-constant array, t</del><ins>T</ins>he subscript operator returns a
+reference to the corresponding element of the array.
+</p>
+
+<p>
+-3- The expression <tt>&amp;a[i+j] == &amp;a[i] + j</tt> evaluates as <tt>true</tt> for all <tt>size_t i</tt>
+and <tt>size_t j</tt> such that <tt>i+j</tt> is less 
+than the length of the <del>non-constant</del> array <tt>a</tt>.
+</p>
+
+<p>
+-4- Likewise, the expression <tt>&amp;a[i] != &amp;b[j]</tt> evaluates
+as <tt>true</tt> for any two <del>non-constant</del> arrays <tt>a</tt> and
+<tt>b</tt> and for any <tt>size_t i</tt> and <tt>size_t j</tt> such that
+<tt>i</tt> is less than the length of <tt>a</tt> and <tt>j</tt> is less
+than the length of <tt>b</tt>. This property indicates an absence of
+aliasing and may be used to advantage by optimizing
+compilers.<sup>281)</sup>
+</p>
+
+<p>
+-5- The reference returned by the subscript operator for a<ins>n</ins> <del>non-constant</del> array is guaranteed to be valid until
+the member function <tt>resize(size_t, T)</tt> (26.5.2.7) is called for that array or until the lifetime 
+of that array ends, whichever happens first.
+</p>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="725"></a>725. Optional sequence container requirements column label</h3>
+<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+ <b>Submitter:</b> David Abrahams <b>Date:</b> 2007-09-16</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Table 90: (Optional sequence container operations) states the
+"assertion note pre/post-condition" of <tt>operator[]</tt> to be
+</p>
+
+<blockquote><pre>*(a.begin() + n)
+</pre></blockquote>
+
+<p>
+Surely that's meant to be "operational semantics?"
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<blockquote>
+<table border="1">
+<caption>Table 90: Optional sequence container operations</caption>
+<tbody><tr>
+<th>expression</th> <th>return type</th> <th><del>assertion/note<br>pre/post-condition</del><br> <ins>operational semantics</ins></th> <th>container</th>
+</tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="729"></a>729. Problem in [rand.req.eng]/3</h3>
+<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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.req.eng">issues</a> in [rand.req.eng].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The 3rd table row in 26.4.1.3 [rand.req.eng]/3 requires random number engines to accept any 
+arithmetic type as a seed, which is then casted to the engine's <tt>result_type</tt> and subsequently 
+used for seeding the state of the engine. The requirement stated as "Creates an engine with 
+initial state determined by <tt>static_cast&lt;X::result_type&gt;(s)</tt>" forces random number engines 
+to either use a seeding method that completely depends on the <tt>result_type</tt> (see the discussion 
+of seeding for the <tt>mersenne_twister_engine</tt> in point T2 above) or at least to throw away "bits 
+of randomness" in the seed value if the <tt>result_type</tt> is smaller than the seed type. This seems 
+to be inappropriate for many modern random number generators, in particular F2-linear or 
+cryptographic ones, which operate on an internal bit array that in principle is independent of the 
+type of numbers returned.
+</p>
+
+<p>
+<b>Posible resolution:</b> I propose to change the wording to a version similar to "Creates an 
+engine with initial state determined by <tt>static_cast&lt;UintType&gt;(s)</tt>, where <tt>UintType</tt> is an 
+implementation specific unsigned integer type."
+</p>
+
+<p>
+Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
+</p>
+
+<p>
+Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified.
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for further discussion.
+</p>
+
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+In reply to the discussion in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+regarding this issue:
+</p>
+<p>
+The descriptions of all engines and engine adaptors given in sections
+26.4.3 [rand.eng] and 26.4.4 [rand.adapt] already specify the concrete
+types of the integer arguments for seeding. Hence, relaxing the general
+requirement in 26.4.1.3 [rand.req.eng] would not affect portability and
+reproducibility of the standard library. Furthermore, it is not clear to
+me what exactly the guarantee "with initial state determined by
+<tt>static_cast&lt;X::result_type&gt;(s)</tt>" is useful for. On the other hand,
+relaxing the requirement would allow developers to implement  other
+random number engines that do not have to cast all arithmetic seed
+arguments to their result_types.
+</p>
+</blockquote>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Propose close NAD for the reasons given in N2424.
+</blockquote>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for further discussion.
+</p>
+
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Change row 3 of table 105 "Random number engine requirements" in 26.4.1.3 [rand.req.eng]/3
+</p>
+
+<blockquote>
+Creates an engine with initial state determined by
+<tt><del>static_cast&lt;X::result_type&gt;(</del>s<del>)</del></tt>
+</blockquote>
+
+<p>
+Similarly, change 26.4.1.4 [rand.req.adapt]/3 e)
+</p>
+
+<blockquote>
+When <tt>X::X</tt> is invoked with <del>an <tt>X::result_type</tt></del> value <tt>s</tt>
+<ins>of arithmetic type (3.9.1)</ins>, ...
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="730"></a>730. Comment on [rand.req.adapt]/3 e)</h3>
+<p><b>Section:</b> 26.4.1.4 [rand.req.adapt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+If an engine adaptor is invoked with an argument of type <tt>seed_seq</tt>, then all base 
+engines are specified to be seeded with this <tt>seed_seq</tt>. As <tt>seed_seq</tt>'s randomization method is 
+qualified as constant, this procedure will ef fectively initialize all base engines with the same seed 
+(though the resulting state might still dif fer to a certain degree if the engines are of different types). 
+It is not clear whether this mode of operation is in general appropriate, hence -- as far as the 
+stated requirements are of general nature and not just specific to the engine adaptors provided by 
+the library -- it might be better to leave the behaviour unspecified, since the current definition of 
+<tt>seed_seq</tt> does not allow for a generally satisfying specification.
+</p>
+
+<p>
+<b>Posssible resolution:</b> [As above]
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for further discussion.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Close NAD for the reasons given in N2424.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="731"></a>731. proposal for a customizable <tt>seed_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#NAD">NAD</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.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#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The proper way to seed random number engines seems to be the most frequently 
+discussed issue of the 26.4 [rand] proposal. While the new <tt>seed_seq</tt> approach is already rather 
+general and probably sufficient for most situations, it is unlikely to be optimal in every case (one 
+problem was pointed out in point T5 above). In some situations it might, for instance, be better to 
+seed the state with a cryptographic generator. 
+</p>
+<p>
+In my opinion this is a pretty strong argument for extending the standard with a simple facility to 
+customize the seeding procedure. This could, for example, be done with the following minimal 
+changes:
+</p>
+
+<p>
+<b>Possible resolution:</b>
+</p>
+
+<ol type="a">
+<li>
+Turn the interface specification of 26.4.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the 
+exact behaviour of the constructors and the randomize method are left unspecified and where the
+const qualification for randomize is removed. Classes implementing this interface are additionally 
+required to specialize the traits class in c).
+</li>
+<li>
+Provide the class <tt>seed_seq</tt> as a default implementation of the SeedSeq interface.
+</li>
+<li>
+<p>
+Supplement the <tt>seed_seq</tt> with a traits class
+</p>
+<blockquote><pre>template &lt;typename T&gt; 
+struct is_seed_seq { static const bool value = false; }
+</pre></blockquote>
+<p>and the specialization</p>
+<blockquote><pre>template &lt;&gt; 
+struct is_seed_seq&lt;seed_seq&gt; { static const bool value = true; }
+</pre></blockquote>
+<p>which users can supplement with further specializations.</p>
+</li>
+<li>
+Change 26.4.1.3 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and 
+modify the constructors and seed methods in 26.4.3 [rand.eng] appropriately (the actual implementation 
+could be done using the SFINAE technique).
+</li>
+</ol>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+See N2424. Close NAD but note that "conceptizing" the library may cause
+this problem to be solved by that route.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="733"></a>733. Comment on [rand.req.dist]/9</h3>
+<p><b>Section:</b> 26.4.1.5 [rand.req.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The requirement "P shall have a declaration of the form <tt>typedef X distribution_- 
+type</tt>" effectively makes the use of inheritance for implementing distributions very inconvenient, 
+because the child of a distribution class in general will not satisfy this requirement. In my opinion 
+the benefits of having a typedef in the parameter class pointing back to the distribution class are 
+not worth the hassle this requirement causes. [In my code base I never made use of the nested 
+typedef but on several occasions could have profited from being able to use simple inheritance for 
+the implementation of a distribution class.]
+</p>
+
+<p>
+<b>Proposed resolution:</b> I propose to drop this requirement.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Close NAD for the reasons given in N2424. In practice it is not inconvenient to meet these requirements.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="735"></a>735. Unfortunate naming</h3>
+<p><b>Section:</b> 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In my opinion the choice of name for the <tt>t</tt> parameter of the <tt>binomial_distribution</tt>
+is very unfortunate. In virtually every internet reference, book and software implementation 
+this parameter is called <tt>n</tt> instead, see for example Wikipedia, Mathworld, Evans et al. (1993) 
+Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926, 
+Mathematica and Matlab.
+</p>
+
+<p>
+Similarly, the choice of <tt>k</tt> for the parameter of the negative binomial distributions is rather unusual. 
+The most common choice for the negative binomial distribution seems to be <tt>r</tt> instead.
+</p>
+
+<p>
+Choosing unusual names for the parameters causes confusion among users and makes the 
+interface unnecessarily inconvenient to use.
+</p>
+
+<p>
+<b>Possible resolution:</b> For these reasons, I propose to change the name of the respective parameters
+to <tt>n</tt> and <tt>r</tt>.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+In N2424. NAD It has been around for a while. It is hardly universal,
+there is prior art, and this would confuse people.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="736"></a>736. Comment on [rand.dist.samp.discrete]</h3>
+<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<ol type="a">
+<li>
+The specification for <tt>discrete_distribution</tt> requires the member <tt>probabilities()</tt>
+to return a vector of <i>standardized</i> probabilities, which forces the implementation every time to 
+divide each probability by the sum of all probabilities, as the sum will in practice almost never be 
+exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to 
+compute the standardized probabilities at all and could instead work with the non-standardized 
+probabilities and the sum. If there was no standardization the user would just get back the 
+probabilities that were previously supplied to the distribution object, which to me seems to be the 
+more obvious solution.
+</li>
+<li>
+The behaviour of <tt>discrete_distribution</tt> is not specified in case the number of given
+probabilities is larger than the maximum number representable by the IntType.
+</li>
+</ol>
+
+<p>
+<b>Possible resolution:</b> I propose to change the specification such that the non-standardized 
+probabilities need to be returned and that an additional requirement is included for the number 
+of probabilities to be smaller than the maximum of IntType.
+</p>
+
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+In reply to the discussion in 
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+of this issue:
+</p>
+<p>
+Rescaled floating-point parameter vectors can not be expected to compare
+equal because of the limited precision of floating-point numbers.
+My proposal would at least guarantee that a parameter
+vector (of type double) passed into the distribution would compare equal
+with the one returned by the <tt>probabilities()</tt> method. Furthermore, I do
+not understand why "the changed requirement would lead to a significant
+increase in the amount of state in the distribution object". A typical
+implementation's state would increase by exactly one number: the sum of
+all probabilities. The textual representation for serialization would
+not need to grow at all. Finally, the proposed replacement "<tt>0 &lt; n &lt;=
+numeric_limits&lt;IntType&gt;::max() + 1</tt>" makes the implementation
+unnecessarily complicated, "<tt>0 &lt; n &lt;= numeric_limits&lt;IntType&gt;::max()</tt>"
+would be better.
+</p>
+</blockquote>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+In N2424. We agree with the observation and the proposed resolution to
+part b). We recommend the wording n &gt; 0 be replaced with 0 &lt; n
+numeric_limits::max() + 1. However, we disagree with part a), as it
+would interfere with the definition of parameters' equality. Further,
+the changed requirement would lead to a significant increase in the
+amount of state of the distribution object.
+</p>
+
+<p>
+As it stands now, it is convenient, and the changes proposed make it
+much less so.
+</p>
+
+<p>
+NAD. Part a the current behavior is desirable. Part b, any constructor
+can fail, but the rules under which it can fail do not need to be listed
+here.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
+
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+In 26.4.8.5.1 [rand.dist.samp.discrete]:
+</p>
+
+<p>
+Proposed wording a):
+</p>
+
+<blockquote>
+<p>
+Changae in para. 2
+</p>
+
+<blockquote>
+Constructs a <tt>discrete_distribution</tt> object with <tt>n=1</tt> and <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt>
+</blockquote>
+
+<p>
+and change in para. 5
+</p>
+
+<blockquote>
+<i>Returns:</i> A <tt>vector&lt;double&gt;</tt> whose <tt>size</tt> member returns <tt>n</tt> and whose
+<tt>operator[]</tt> member returns <del><tt>p<sub>k</sub></tt></del>
+<ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins>
+when invoked with argument <tt>k</tt> for <tt>k = 0,
+..., n-1</tt>
+</blockquote>
+
+</blockquote>
+
+<p>
+Proposed wording b):
+</p>
+
+<blockquote>
+<p>
+Change in para. 3:
+</p>
+
+<blockquote>
+If <tt>firstW == lastW</tt>, let the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist
+of the single value <tt>w<sub>0</sub> = 1</tt>. Otherwise, <tt>[firstW,lastW)</tt> shall form a
+sequence <tt>w</tt> of length <tt>n <del>&gt; 0</del></tt> 
+<ins>such that <tt>0 &lt; n &lt;= numeric_limits&lt;IntType&gt;::max()</tt>,</ins>
+and <tt>*firstW</tt> shall yield a value <tt>w<sub>0</sub></tt>
+convertible to <tt>double</tt>. [<i>Note:</i> The values <tt>w<sub>k</sub></tt> are commonly known
+as the weights . <i>-- end note</i>]
+</blockquote>
+
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</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#NAD">NAD</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.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#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<ol type="a">
+<li>
+The discussion in point T11 above regarding <tt>probabilities()</tt> similarly applies 
+to the method <tt>densities()</tt> of <tt>piecewise_constant_distribution</tt>.
+</li>
+<li>
+<p>
+The design of the constructor
+</p>
+<blockquote><pre>template &lt;class InputIteratorB, class InputIteratorW&gt; 
+piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, 
+                                 InputIteratorW firstW);
+</pre></blockquote>
+<p>
+is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see 
+any performance or convenience reasons that would justify the risks inherent in such a function 
+interface, in particular the risk that input error might go unnoticed.
+</p>
+</li>
+</ol>
+
+<p>
+<b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface.
+</p>
+
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
+
+<blockquote>
+In reply to the discussion in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+I'd like to make the same comments as for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>.
+</blockquote>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
+
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+In 26.4.8.5.2 [rand.dist.samp.pconst]:
+</p>
+
+<p>
+Proposed wording a)
+</p>
+
+<blockquote>
+<p>
+Change in para. 2
+</p>
+<blockquote>
+Constructs a <tt>piecewise_constant_distribution</tt> object with <tt>n = 1</tt>, <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt>,
+<tt>b<sub>0</sub> = 0</tt>, and <tt>b<sub>1</sub> = 1</tt>
+</blockquote>
+
+<p>
+and change in para. 5
+</p>
+
+<blockquote>
+A <tt>vector&lt;result_type&gt;</tt> whose <tt>size</tt> member returns <tt>n</tt> and whose <tt>operator[]</tt>
+member returns <del><tt>p<sub>k</sub></tt></del>
+<ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins>
+when invoked with argument <tt>k</tt> for <tt>k = 0, ..., n-1</tt>
+</blockquote>
+
+</blockquote>
+
+<p>
+Proposed wording b)
+</p>
+
+<blockquote>
+<p>
+Change both occurrences of
+</p>
+
+<blockquote>
+"piecewise_constant_distribution(InputIteratorB firstB, InputIteratorB lastB,
+                                 InputIteratorW firstW<ins>, InputIteratorW lastW</ins>)
+</blockquote>
+
+<p>
+and change in para. 3
+</p>
+
+<blockquote>
+<del>the length of the sequence <tt>w</tt> starting from <tt>firstW</tt> shall be at least <tt>n</tt>,
+<tt>*firstW</tt> shall return a value <tt>w<sub>0</sub></tt> that is convertible to <tt>double</tt>, and any
+<tt>w<sub>k</sub></tt> for <tt>k &gt;= n</tt> shall be ignored by the distribution</del>
+<ins><tt>[firstW, lastW)</tt> shall form a sequence <tt>w</tt> of length <tt>n</tt> whose leading element
+<tt>w<sub>0</sub></tt> shall be convertible to <tt>double</tt></ins>
+</blockquote>
+
+</blockquote>
+
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="738"></a>738. Editorial issue in [rand.adapt.disc]/3</h3>
+<p><b>Section:</b> 26.4.4.1 [rand.adapt.disc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+ <b>Submitter:</b> 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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Since the template parameter <tt>p</tt> and <tt>r</tt> are of type <tt>size_t</tt>, the member <tt>n</tt> in the class 
+exposition should have type <tt>size_t</tt>, too.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="739"></a>739. Defect in [rand.util.canonical]/3</h3>
+<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The complexity of <tt>generate_canonical</tt> is specified to be "exactly k=max(1, ceil(b/log2 
+R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in 
+general) be computed at compile time. As this function template is performance critical, I propose 
+to replace ceil(b/log2 R) with ceil(b/floor(log2 R)).
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for further discussion.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+In N2424. Close NAD as described there.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3>
+<p><b>Section:</b> 20.6.12.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-27</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
+</p>
+
+<p>
+According to the recent draft N2369, both the header memory synopsis
+of 20.6 [memory] and 20.6.12.2.11 [util.smartptr.getdeleter] declare:
+</p>
+
+<blockquote><pre>template&lt;class D, class T&gt; D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
+</pre></blockquote>
+
+<p>
+This allows to retrieve the pointer to a mutable deleter of a <tt>const
+shared_ptr</tt> (if that owns one) and therefore contradicts the usual
+philosophy that associated functors are either read-only (e.g.
+<tt>key_comp</tt> or <tt>value_comp</tt> of <tt>std::map</tt>) or do at least reflect
+the mutability of the owner (as seen for the both overloads of
+<tt>unique_ptr::get_deleter</tt>).
+Even the next similar counter-part of <tt>get_deleter</tt> - the two
+overloads of <tt>function::target</tt> in the class template function
+synopsis 20.5.15.2 [func.wrap.func] or in 20.5.15.2.5 [func.wrap.func.targ] - do
+properly mirror the const-state of the owner.
+</p>
+
+<b>Possible proposed resolutions:</b>
+
+<p>
+Replace the declarations of <tt>get_deleter</tt> in the header <tt>&lt;memory&gt;</tt>
+synopsis of 20.6 [memory] and in 20.6.12.2.11 [util.smartptr.getdeleter] by one of the
+following alternatives (A) or (B):
+</p>
+
+<ol type="A">
+<li>
+Provide <b>only</b> the immutable variant. This would reflect the
+current praxis of <tt>container::get_allocator()</tt>, <tt>map::key_comp()</tt>, or
+<tt>map::value_comp</tt>.
+
+<blockquote><pre>template&lt;class D, class T&gt; const D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
+</pre></blockquote>
+</li>
+<li>
+Just remove the function.
+</li>
+</ol>
+
+<p>
+Alberto Ganesh Barbati adds:
+</p>
+
+<ol start="3" type="A">
+<li>
+<p>
+Replace it with two functions:
+</p>
+<blockquote><pre>template &lt;class D, class T&gt; D get_deleter(shared_ptr&lt;T&gt; const&amp;);
+template &lt;class D, class T&gt; bool has_deleter(shared_ptr&lt;T&gt; const&amp;);
+</pre></blockquote>
+
+<p>
+The first one would throw if <tt>D</tt> is the wrong type, while the latter would
+never throw. This approach would reflect the current praxis of
+<tt>use_facet/has_facet</tt>, with the twist of returning the deleter by value as
+<tt>container::get_allocator()</tt> do.
+</p>
+</li>
+</ol>
+
+<p>
+Peter Dimov adds:
+</p>
+
+<blockquote>
+<p>
+My favorite option is "not a defect". A, B and C break useful code.
+</p>
+</blockquote>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Concern this is similar to confusing "pointer to const" with "a constant pointer".
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="745"></a>745. copy_exception API slices.</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#NAD">NAD</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#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#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+It could be I did not understand the design rationale, but I thought
+copy_exception would produce an exception_ptr to the most-derived (dynamic)
+type of the passed exception.  Instead it slices, which appears to be less
+useful, and a likely source of FAQ questions in the future.
+</p>
+<p>
+(Peter Dimov suggests NAD)
+</p>
+
+<p><i>[
+Bellevue: 
+]</i></p>
+
+
+<blockquote>
+<p>
+How could this be implemented in a way that the dynamic type is cloned?
+</p>
+<p>
+The feature is designed to create an exception_ptr from an object whose
+static type is identical to the dynamic type and thus there is no
+slicing involved.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3>
+<p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I am trying to decide is a pure virtual function is a <i>necessary</i> as well as
+sufficient requirement to be classified as abstract?
+</p>
+<p>
+For instance, is the following (non-polymorphic) type considered abstract?
+</p>
+<blockquote><pre>struct abstract {
+protected:
+&nbsp;abstract(){}
+&nbsp;abstract( abstract const &amp; ) {}
+&nbsp;~abstract() {}
+};
+</pre></blockquote>
+<p>
+(Suggested that this may be NAD, with an editorial fix-up from Pete on the
+core wording to make clear that abstract requires a pure virtual function)
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Core has clarified that the definition abstract is adequate. Issue withdrawn by submitter. NAD.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3>
+<p><b>Section:</b> 20.6.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-10-15</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+14882-2003, [lib.uninitialized.copy] is currently written as follows:
+</p>
+
+<blockquote>
+<pre>template &lt;class InputIterator, class ForwardIterator&gt;
+  ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>,
+                                     ForwardIterator <i>result</i>);
+</pre>
+<blockquote>
+<p>
+-1- <i>Effects:</i>
+</p>
+<blockquote><pre>for (; first != last; ++result, ++first)
+  new (static_cast&lt;void*&gt;(&amp;*result))
+    typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
+</pre></blockquote>
+<p>
+-2- <i>Returns:</i> <tt><i>result</i></tt>
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+similarily for N2369, and its corresponding section
+20.6.10.1 [uninitialized.copy].
+</p>
+
+<p>
+It's not clear to me what the return clause is supposed to mean, I see
+two
+possible interpretations:
+</p>
+
+<ol type="a">
+<li>
+The notion of <tt><i>result</i></tt> is supposed to mean the value given by the
+function parameter <tt><i>result</i></tt> [Note to the issue editor: Please use italics for
+<tt><i>result</i></tt>].
+This seems somewhat implied by recognizing that both the function
+parameter
+and the name used in the clause do have the same italic font.
+</li>
+<li>
+The notion of "result" is supposed to mean the value of <tt><i>result</i></tt>
+after the
+preceding effects clause. This is in fact what all implementations I
+checked
+do (and which is probably it's intend, because it matches the
+specification of <tt>std::copy</tt>).
+</li>
+</ol>
+
+<p>
+The problem is: I see nothing in the standard which grants that this
+interpretation
+is correct, specifically [lib.structure.specifications] or
+17.3.1.3 [structure.specifications]
+resp. do not clarify which "look-up" rules apply for names found in
+the elements
+of the detailed specifications - Do they relate to the corresponding
+synopsis or
+to the effects clause (or possibly other elements)? Fortunately most
+detailed
+descriptions are unambigious in this regard, e.g. this problem does
+not apply
+for <tt>std::copy</tt>.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the wording of the return clause to say (20.6.10.1 [uninitialized.copy]):
+</p>
+
+<blockquote>
+<p>
+-2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins>
+</p>
+</blockquote>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Resolution: NAD editorial -- project editor to decide if change is
+worthwhile. Concern is that there are many other places this might
+occur.
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="757"></a>757. Typo in the synopsis of vector</h3>
+<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+ <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-11-04</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In the synopsis 23.2.6 [vector], there is the signature:
+</p>
+
+<blockquote><pre>void insert(const_iterator position, size_type n, T&amp;&amp; x);
+</pre></blockquote>
+
+<p>
+instead of:
+</p>
+
+<blockquote><pre>iterator insert(const_iterator position, T&amp;&amp; x);
+</pre></blockquote>
+
+<p>
+23.2.6.4 [vector.modifiers] is fine.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 23.2.6 [vector]:
+</p>
+
+<blockquote><pre>iterator insert(const_iterator position, const T&amp; x); 
+<ins>iterator insert(const_iterator position, T&amp;&amp; x);</ins>
+void     insert(const_iterator position, size_type n, const T&amp; x); 
+<del>void     insert(const_iterator position, size_type n, T&amp;&amp; x);</del>
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="763"></a>763. Renaming <tt>emplace()</tt> overloads</h3>
+<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-04</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The associative containers provide 2 overloads of <tt>emplace()</tt>:
+</p>
+
+<blockquote><pre>template &lt;class... Args&gt; pair&lt;iterator, bool&gt; emplace(Args&amp;&amp;... args);
+template &lt;class... Args&gt; iterator emplace(const_iterator position, Args&amp;&amp;... args);
+</pre></blockquote>
+
+<p>
+This is a problem if you mean the first overload while passing
+a <tt>const_iterator</tt> as first argument.
+</p>
+
+<p><i>[
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+</blockquote>
+<p>
+This can be disambiguated by passing "begin" as the first argument in
+the case when the non-default choice is desired. We believe that desire
+will be rare.
+</p>
+<p>
+Resolution: Change state to NAD.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Rename one of the two overloads.
+For example to <tt>emplace_here</tt>, <tt>hint_emplace</tt>...
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="764"></a>764. <tt>equal_range</tt> on unordered containers should return a <tt>pair</tt> of <tt>local_iterators</tt></h3>
+<p><b>Section:</b> 23.1.3 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-29</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+    A major attribute of the unordered containers is that iterating 
+though them inside a bucket is very fast while iterating between buckets 
+can be much slower.  If an unordered container has a low load factor, 
+iterating between the last iterator in one bucket and the next iterator, 
+which is in another bucket, is <tt>O(bucket_count())</tt> which may be much 
+larger than <tt>O(size())</tt>.
+</p>
+<p>
+    If <tt>b</tt> is an non-const unordered container of type <tt>B</tt> and <tt>k</tt> is an 
+object of it's <tt>key_type</tt>, then <tt>b.equal_range(k)</tt> currently returns 
+<tt>pair&lt;B::iterator, B::iterator&gt;</tt>. Consider the following code:
+</p>
+
+<blockquote><pre>B::iterator lb, ub;
+tie(lb, ub) = b.equal_range(k);
+for (B::iterator it = lb; it != ub; ++it) {
+        // Do something with *it
+}
+</pre></blockquote>
+
+<p>
+If <tt>b.equal_range(k)</tt> returns a non-empty range (i.e. <tt>b</tt> contains at least 
+on element whose key is equivalent to <tt>k</tt>), then every iterator in the 
+half-open range <tt>[lb, ub)</tt> will be in the same bucket, but <tt>ub</tt> will likely 
+either be in a different bucket or be equal to <tt>b.end()</tt>.  In either case, 
+iterating between <tt>ub - 1</tt> and <tt>ub</tt> could take a much longer time than 
+iterating through the rest of the range.
+</p>
+<p>
+If instead of returning <tt>pair&lt;iterator, iterator&gt;</tt>, <tt>equal_range</tt> were to 
+return <tt>pair&lt;local_iterator, local_iterator&gt;</tt>, then <tt>ub</tt> (which, like <tt>lb</tt>, 
+would now be a <tt>local_iterator</tt>) could be guaranteed to always be in the 
+same bucket as <tt>lb</tt>. In the cases where currently <tt>ub</tt> is equal to <tt>b.end()</tt>
+or is in a different bucket, <tt>ub</tt> would be equal to <tt>b.end(b.bucket(key))</tt>. 
+  This would make iterating between <tt>lb</tt> and <tt>ub</tt> much faster, as every 
+iteration would be constant time.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+The proposed resolution breaks consistency with other container types
+for dubious benefit, and iterators are already constant time.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the entry for <tt>equal_range</tt> in Table 93 (23.1.3 [unord.req]) as follows:
+</p>
+<table border="1">
+<tbody><tr>
+<th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
+</tr>
+
+<tr>
+<td><tt>b.equal_range(k)</tt></td>
+<td><tt>pair&lt;<ins>local_</ins>iterator,<ins>local_</ins>iterator&gt;; pair&lt;const_<ins>local_</ins>iterator,const_<ins>local_</ins>iterator&gt;</tt> for <tt>const b</tt>.</td>
+<td>Returns a range containing all elements with keys equivalent to <tt>k</tt>. Returns <tt>make_pair(b.end(<ins>b.bucket(key)</ins>),b.end(<ins>b.bucket(key)</ins>))</tt> if no such elements exist.</td>
+<td>Average case &#920;<tt>(b.count(k))</tt>. Worst case &#920;<tt>(b.size())</tt>. </td>
+</tr>
+</tbody></table>
+
+
+
+
+
+<hr>
+<h3><a name="773"></a>773. issues with random</h3>
+<p><b>Section:</b> 26.4.8.1 [rand.dist.uni] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-01-14</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.uni">issues</a> in [rand.dist.uni].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<ol>
+<li>
+26.4.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> constructor has changed the default
+max constructor parameter from 9 (in TR1) to <tt>max()</tt>. The value
+is arbitrary at best and shouldn't be lightly changed because
+it breaks backward compatibility.
+</li>
+
+<li>
+26.4.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> has a parameter <tt>param</tt> that you can
+provide on construction or <tt>operator()</tt>, set, and get. But there
+is not even a hint of what this might be for.
+</li>
+
+<li>
+26.4.8.1.2 [rand.dist.uni.real] <tt>uniform_real</tt>. Same issue as #2.
+</li>
+</ol>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+NAD. Withdrawn.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="784"></a>784. unique_lock::release</h3>
+<p><b>Section:</b> 30.3.3.2.3 [thread.lock.unique.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Constantine Sapuntzakis <b>Date:</b> 2008-02-02</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>unique_lock::release</tt> will probably lead to many mistakes where people
+call <tt>release</tt> instead of <tt>unlock</tt>. I just coded such a mistake using the
+boost pre-1.35 threads library last week.
+</p>
+
+<p>
+In many threading libraries, a call with <tt>release</tt> in it unlocks the
+lock (e.g. ReleaseMutex in Win32, java.util.concurrent.Semaphore).
+</p>
+
+<p>
+I don't call <tt>unique_lock::lock</tt> much at all, so I don't get to see the
+symmetry between <tt>::lock</tt> and <tt>::unlock</tt>. I usually use the constructor to
+lock the mutex. So I'm left to remember whether to call <tt>release</tt> or
+<tt>unlock</tt> during the few times I need to release the mutex before the scope
+ends. If I get it wrong, the compiler doesn't warn me.
+</p>
+
+<p>
+An alternative name for release may be <tt>disown</tt>.
+</p>
+
+<p>
+This might be a rare case where usability is hurt by consistency with
+the rest of the C++ standard (e.g. <tt>std::auto_ptr::release</tt>).
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Change a name from release to disown. However prior art uses the release
+name. Compatibility with prior art is more important that any possible
+benefit such a change might make. We do not see the benefit for
+changing. NAD
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 30.3.3.2 [thread.lock.unique]:
+</p>
+
+<blockquote><pre>template &lt;class Mutex&gt; 
+class unique_lock 
+{ 
+public:
+   ...
+   mutex_type* <del>release</del> <ins>disown</ins>();
+   ...
+};
+</pre></blockquote>
+
+<p>
+Change 30.3.3.2.3 [thread.lock.unique.mod]:
+</p>
+
+<blockquote><pre>mutex_type *<del>release</del> <ins>disown</ins>();
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="790"></a>790. <tt>xor_combine::seed</tt> not specified</h3>
+<p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>xor_combine::seed(result_type)</tt> and <tt>seed(seed_seq&amp;)</tt> don't say what
+happens to each of the sub-engine seeds. (Should probably do the same
+to both, unlike TR1.)
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Overcome by the previous proposal. NAD mooted by resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#789">789</a>.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="791"></a>791. <tt>piecewise_constant_distribution::densities</tt> has wrong name</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#NAD">NAD</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#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>piecewise_constant_distribution::densities()</tt> should be <tt>probabilities()</tt>,
+just like <tt>discrete_distribution</tt>. (There's no real use for weights divided
+by areas.)
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Fermilab does not agree with this summary. As defined in the equation in
+26.4.8.5.2/4, the quantities are indeed probability densities not
+probabilities. Because we view this distribution as a parameterization
+of a *probability density function*, we prefer to work in terms of
+probability densities.
+</p>
+
+<p>
+We don't think this should be changed.
+</p>
+
+<p>
+If there is a technical argument about why the implementation dealing
+with these values can't be as efficient as one dealing with
+probabilities, we might reconsider. We don't care about this one member
+function being somewhat more or less efficient; we care about the size
+of the distribution object and the speed of the calls to generate
+variates.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change synopsis in 26.4.8.5.2 [rand.dist.samp.pconst]:
+</p>
+
+<blockquote><pre>template &lt;class RealType = double&gt; 
+class piecewise_constant_distribution 
+{ 
+public:
+    ...
+    vector&lt;double&gt; <del>densities</del> <ins>probabilities</ins>() const;
+    ...
+};
+</pre></blockquote>
+
+<p>
+Change 26.4.8.5.2 [rand.dist.samp.pconst]/6:
+</p>
+
+<blockquote><pre>vector&lt;double&gt; <del>densities</del> <ins>probabilities</ins>() const;
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="795"></a>795. <tt>general_pdf_distribution</tt> should be dropped</h3>
+<p><b>Section:</b> 26.4.8.5.3 [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a></p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>general_pdf_distribution</tt> should be dropped. (It's a research topic in
+adaptive numerical integration.)
+</p>
+
+<p><i>[
+Stephan Tolksdorf notes:
+]</i></p>
+
+
+<blockquote>
+This appears to be a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="796"></a>796. <tt>ranlux48_base</tt> returns wrong value</h3>
+<p><b>Section:</b> 26.4.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The 10,000<sup>th</sup> value returned by <tt>ranlux48_base</tt> is supposed to be
+61839128582725. We get 192113843633948. (Note that the underlying
+generator was changed in Kona.)
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Submitter withdraws defect.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.4.5 [rand.predef]/p5:
+</p>
+
+<blockquote>
+<pre>typedef subtract_with_carry_engine&lt;uint_fast64_t, 48, 5, 12&gt; 
+        ranlux48_base; 
+</pre>
+<blockquote>
+<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
+object of type <tt>ranlux48_base</tt> shall produce the value
+<del>61839128582725</del> <ins>192113843633948</ins>.
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="797"></a>797. <tt>ranlux48</tt> returns wrong value</h3>
+<p><b>Section:</b> 26.4.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The 10,000<sup>th</sup> value returned by <tt>ranlux48</tt> is supposed to be
+249142670248501. We get 88229545517833. (Note that this depends
+on <tt>ranlux48_base</tt>.)
+</p>
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Submitter withdraws defect.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.4.5 [rand.predef]/p6:
+</p>
+
+<blockquote>
+<pre>typedef discard_block_engine&lt;ranlux48_base, 389, 11&gt; 
+        ranlux48
+</pre>
+<blockquote>
+<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
+object of type <tt>ranlux48</tt> shall produce the value
+<del>249142670248501</del> <ins>88229545517833</ins>.
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="799"></a>799. [tr.rand.eng.mers] and [rand.eng.mers]</h3>
+<p><b>Section:</b> 26.4.3.2 [rand.eng.mers], TR1 5.1.4.2 [tr.rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2008-02-18</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#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+TR1 5.1.4.2 [tr.rand.eng.mers](10) requires that <tt>operator==</tt> for the <tt>mersenne_twister</tt>
+returns <tt>true</tt> if and only if the states of two <tt>mersenne_twisters</tt>,
+consisting each of <tt>n</tt> integers between <tt>0</tt> and <tt>2<sup>w</sup> - 1</tt>, are completely
+equal. This is a contradiction with TR1 5.1.1 [tr.rand.req](3) because the given
+definition of the state also includes the lower <tt>r</tt> bits of <tt>x(i-n)</tt>, which
+will never be used to generate a random number. If two <tt>mersenne_twister</tt>s
+only differ in the lower bits of <tt>x(i-n)</tt> they will not compare equal,
+although they will produce an identical sequence of random numbers.
+</p>
+
+<p>
+26.4.3.2 [rand.eng.mers] in the latest C++ draft does not specify the behaviour
+of <tt>operator==</tt> but uses a similar definition of the state and, just like
+TR1 5.1.4.2 [tr.rand.eng.mers], requires the textual representation of a
+<tt>mersenne_twister_engine</tt> to consist of <tt>X<sub>i-n</sub></tt> to <tt>X<sub>i-1</sub></tt>, including the
+lower bits of <tt>X<sub>i-n</sub></tt>. This leads to two problems: First, the
+unsuspecting implementer is likely to erroneously compare the lower <tt>r</tt>
+bits of <tt>X<sub>i-n</sub></tt> in <tt>operator==</tt>. Second, if only the lower <tt>r</tt> bits differ,
+two <tt>mersenne_twister_engine</tt>s will compare equal (if correctly
+implemented) but have different textual representations, which
+conceptually is a bit ugly.
+</p>
+
+<p>
+I propose that a paragraph or footnote is added to 26.4.3.2 [rand.eng.mers] which
+clarifies that the lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> are not to be compared in
+<tt>operator==</tt> and <tt>operator!=</tt>. It would only be consequent if furthermore
+the specification for the textual respresentation was changed to
+<tt>X<sub>i-n</sub> bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)), X<sub>i-(n-1)</sub>, ...,  X<sub>i-1</sub></tt> or
+something similar.
+</p>
+
+<p>
+These changes would likely have no practical effect, but would allow an
+implementation that does the right thing to be standard-conformant.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Fermi Lab has no objection to the proposed change. However it feels that
+more time is needed to check the details, which would suggest a change
+to REVIEW.
+</p>
+<p>
+Bill feels that this is NAD, not enough practical importance to abandon
+the simple definition of equality, and someone would have to do a lot
+more study to ensure that all cases are covered for a very small
+payback. The submitter admits that "These changes would likely have no
+practical effect,", and according to Plum's razor this means that it is
+not worth the effort!
+</p>
+<p>
+Revisted: Agree that the fact that there is no practical difference means that no change can be justified.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 26.4.3.2 [rand.eng.mers]:
+</p>
+
+<blockquote>
+<p>
+Insert at the end of para 2.:
+</p>
+
+<blockquote>
+[<i>Note:</i> The lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> do not influence
+the state transition and hence should not be compared when comparing two
+<tt>mersenne_twister_engine</tt> objects. <i>-- end note</i>]
+</blockquote>
+
+<p>
+In para 5. change:
+</p>
+
+<blockquote>
+The textual representation of <tt>x<sub>i</sub></tt> consists of the values of
+<tt>X<sub>i-n</sub> <ins>bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)),  X<sub>i-(n-1)</sub></ins>,
+..., X<sub>i-1</sub></tt>, in that order.
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="802"></a>802. <tt>knuth_b</tt> returns wrong value</h3>
+<p><b>Section:</b> 26.4.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-20</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The 10,000<sup>th</sup> value returned by <tt>knuth_b</tt> is supposed to be
+1112339016. We get 2126698284.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.4.5 [rand.predef]/p8:
+</p>
+
+<blockquote>
+<pre>typedef shuffle_order_engine&lt;minstd_rand0, 256&gt; 
+        knuth_b; 
+</pre>
+<blockquote>
+<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
+object of type <tt>knuth_b</tt> shall produce the value
+<del>1112339016</del> <ins>2126698284</ins>.
+</blockquote>
+</blockquote>
+
+
+<p><i>[
+Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD.
+]</i></p>
+
+
+
+
+
+
 </body></html>
\ No newline at end of file
diff --git a/libstdc++-v3/doc/html/ext/lwg-defects.html b/libstdc++-v3/doc/html/ext/lwg-defects.html
index cefbee652e630f310e5e16afb8bc257e3d9b6cb4..013350328849792593a4168d1af3d56631f187c5 100644
--- a/libstdc++-v3/doc/html/ext/lwg-defects.html
+++ b/libstdc++-v3/doc/html/ext/lwg-defects.html
@@ -12,11 +12,11 @@ del {background-color:#FFA0A0}
 <table>
 <tbody><tr>
 <td align="left">Doc. no.</td>
-<td align="left">N2457=07-0327</td>
+<td align="left">N2613=08-0123</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">2007-10-20</td>
+<td align="left">2008-05-18</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -27,7 +27,7 @@ del {background-color:#FFA0A0}
 <td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
 </tr>
 </tbody></table>
-<h1>C++ Standard Library Defect Report List (Revision R52)</h1>
+<h1>C++ Standard Library Defect Report List (Revision R56)</h1>
 
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
@@ -49,6 +49,89 @@ del {background-color:#FFA0A0}
 
 <h2>Revision History</h2>
 <ul>
+<li>R56: 
+2008-05-16 pre-Sophia Antipolis mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>191 open issues, up by 24.</li>
+<li>647 closed issues, up by 1.</li>
+<li>838 issues total, up by 25.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="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>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>
+</li>
+<li>R55: 
+2008-03-14 post-Bellevue mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>167 open issues, down by 39.</li>
+<li>646 closed issues, up by 65.</li>
+<li>813 issues total, up by 26.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
+<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>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>
+<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</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-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</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#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
+<li>Changed the following issues from 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 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 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 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>
+<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R54: 
+2008-02-01 pre-Bellevue mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>206 open issues, up by 23.</li>
+<li>581 closed issues, up by 0.</li>
+<li>787 issues total, up by 23.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="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>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>
+<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</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#527">527</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R53: 
+2007-12-09 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>183 open issues, up by 11.</li>
+<li>581 closed issues, down by 1.</li>
+<li>764 issues total, up by 10.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="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>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>
+</ul>
+</li>
 <li>R52: 
 2007-10-19 post-Kona mailing.
 <ul>
@@ -58,16 +141,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-active.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-active.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.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-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>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-active.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-active.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-active.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-active.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-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 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-active.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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 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 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 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>
@@ -83,7 +166,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-active.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-active.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-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>
 </ul></li>
 </ul>
 </li>
@@ -96,13 +179,13 @@ del {background-color:#FFA0A0}
 <li>708 issues total, up by 12.</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#697">697</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-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</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-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</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-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</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#528">528</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#637">637</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#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</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#525">525</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#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-active.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-active.html#680">680</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 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>
@@ -123,7 +206,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-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-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 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>
@@ -140,12 +223,12 @@ 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-active.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-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-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>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-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Changed the following issues from 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>
 <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li>
-<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
+<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</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-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
 <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
 <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>
@@ -167,11 +250,11 @@ del {background-color:#FFA0A0}
 <li>656 issues total, up by 37.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#626">626</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-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 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 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-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
+<li>Changed the following issues from 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>
 </ul></li>
 </ul>
@@ -201,7 +284,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-active.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-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#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>
@@ -245,9 +328,9 @@ del {background-color:#FFA0A0}
 <li>574 issues total, up by 8.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
@@ -278,7 +361,7 @@ del {background-color:#FFA0A0}
 <li>535 issues total.</li>
 </ul></li>
 <li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
 </ul></li>
 </ul>
 </li>
@@ -323,12 +406,12 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#
 <li>R31: 
 2004-07 mid-term mailing: reflects new proposed resolutions and
 new issues received after the post-Sydney mailing.  Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
+new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
 </li>
 <li>R30: 
 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 Voted all "Ready" issues from R29 into the working paper.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>.
 </li>
 <li>R29: 
 Pre-Sydney mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
@@ -473,7 +556,7 @@ of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3
 <li>R10: 
 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a> to
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 </li>
 <li>R9: 
@@ -492,7 +575,7 @@ pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
 </li>
 <li>R6: 
-pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
+pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>,
 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 </li>
 <li>R5: 
@@ -962,7 +1045,6 @@ supporting to the proposed resolution.</p>
 <h3><a name="11"></a>11. Bitset minor problems</h3>
 <p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -3314,7 +3396,7 @@ item from:</p>
 
 <hr>
 <h3><a name="69"></a>69. Must elements of a vector be contiguous?</h3>
-<p><b>Section:</b> 23.2.5 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
+<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1998-07-29</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
@@ -3328,7 +3410,7 @@ debugging implementations)</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Add the following text to the end of 23.2.5 [vector],
+<p>Add the following text to the end of 23.2.6 [vector],
 paragraph 1. </p>
 
 <blockquote>
@@ -4567,7 +4649,6 @@ example, printing short(-1) in hex format should yield 0xffff.)</p>
 <h3><a name="118"></a>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3>
 <p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-11-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -4681,7 +4762,7 @@ exception-specification for a non-virtual function". </p>
 
 <hr>
 <h3><a name="120"></a>120. Can an implementor add specializations?</h3>
-<p><b>Section:</b> 17.4.3.1 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -4732,7 +4813,7 @@ different explicit instantiations might be harmless.</p>
 
 
 <p><b>Proposed resolution:</b></p>
-  <p>Append to 17.4.3.1 [reserved.names] paragraph 1: </p>
+  <p>Append to 17.4.3.2 [reserved.names] paragraph 1: </p>
   <blockquote><p>
     A program may explicitly instantiate any templates in the standard
     library only if the declaration depends on the name of a user-defined
@@ -4751,7 +4832,7 @@ different explicit instantiations might be harmless.</p>
 <blockquote>
   <p>In light of the resolution to core issue 259, no normative changes
   in the library clauses are necessary.  Add the following non-normative
-  note to the end of 17.4.3.1 [reserved.names] paragraph 1:</p>
+  note to the end of 17.4.3.2 [reserved.names] paragraph 1:</p>
   <blockquote><p>
     [<i>Note:</i> A program may explicitly instantiate standard library
     templates, even when an explicit instantiation does not depend on
@@ -5226,7 +5307,7 @@ Redmond:  formally voted into WP.
 
 <hr>
 <h3><a name="132"></a>132. list::resize description uses random access iterators</h3>
-<p><b>Section:</b> 23.2.3.2 [list.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
+<p><b>Section:</b> 23.2.4.2 [list.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -5245,7 +5326,7 @@ Redmond:  formally voted into WP.
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Change 23.2.3.2 [list.capacity] paragraph 1 to:</p>
+<p>Change 23.2.4.2 [list.capacity] paragraph 1 to:</p>
 
 <p>Effects:</p>
 
@@ -5286,7 +5367,7 @@ after operator= in the map declaration:</p>
 
 <hr>
 <h3><a name="134"></a>134. vector constructors over specified</h3>
-<p><b>Section:</b> 23.2.5.1 [vector.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
+<p><b>Section:</b> 23.2.6.1 [vector.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -5298,7 +5379,7 @@ tradeoff for the implementor.</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Change 23.2.5.1 [vector.cons], paragraph 1 to:</p>
+<p>Change 23.2.6.1 [vector.cons], paragraph 1 to:</p>
 
 <p>-1- Complexity: The constructor template &lt;class
 InputIterator&gt; vector(InputIterator first, InputIterator last)
@@ -6085,7 +6166,6 @@ is the correct spelling.]</i></p>
 <h3><a name="161"></a>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt></h3>
 <p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -6311,7 +6391,6 @@ sentences, change the word "formatted" to
 <h3><a name="169"></a>169. Bad efficiency of <tt>overflow()</tt> mandated</h3>
 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -6758,7 +6837,7 @@ proposed resolution passed their test suites.</p>
 <p><b>Discussion:</b></p>
 <p>Many references to <tt> size_t</tt> throughout the document
 omit the <tt> std::</tt> namespace qualification.</p> <p>For
-example, 17.4.3.4 [replacement.functions] paragraph 2:</p>
+example, 17.4.3.5 [replacement.functions] paragraph 2:</p>
 <blockquote>
 <pre> operator new(size_t)
  operator new(size_t, const std::nothrow_t&amp;)
@@ -6768,7 +6847,7 @@ example, 17.4.3.4 [replacement.functions] paragraph 2:</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>   In 17.4.3.4 [replacement.functions] paragraph 2: replace:</p>
+<p>   In 17.4.3.5 [replacement.functions] paragraph 2: replace:</p>
 <blockquote>
 <p><tt>     - operator new(size_t)<br>
      - operator new(size_t, const std::nothrow_t&amp;)<br>
@@ -6845,7 +6924,7 @@ declaration of template &lt;class charT&gt; class ctype.<br>
 <p>The LWG believes correcting names like <tt>size_t</tt> and
 <tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
 to be essentially editorial.  There there can't be another size_t or
-ptrdiff_t meant anyway because, according to 17.4.3.1.4 [extern.types],</p>
+ptrdiff_t meant anyway because, according to 17.4.3.2.4 [extern.types],</p>
 
 <blockquote><p>
 For each type T from the Standard C library, the types ::T and std::T
@@ -7700,7 +7779,7 @@ otherwise <tt>const U&amp;</tt>".
 <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
 there are multiple const problems with the STL portion of the library
 and that these should be addressed as a single package.&nbsp; Note
-that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a> has already been declared NAD Future for
+that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a> has already been declared NAD Future for
 that very reason.]</i></p>
 
 
@@ -8382,6 +8461,7 @@ is.setstate(ios::failbit) which may throw ios_base::failure
 <h3><a name="212"></a>212. Empty range behavior unclear for several algorithms</h3>
 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -8839,7 +8919,7 @@ resolution for this issue is in accordance with Howard's paper.]</i></p>
 
 <hr>
 <h3><a name="226"></a>226. User supplied specializations or overloads of namespace std function templates</h3>
-<p><b>Section:</b> 17.4.3.1 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-01</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -9452,7 +9532,7 @@ where precision is 0 and mode is %g.]</i></p>
 
 <hr>
 <h3><a name="232"></a>232. "depends" poorly defined in 17.4.3.1</h3>
-<p><b>Section:</b> 17.4.3.1 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2000-04-18</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -9557,10 +9637,10 @@ adjacent to the insertion point.]</i></p>
 
 <p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
 in which an insertion hint would be used even when it is far from the
-insertion point.  This was contingent on seeing a reference
+insertion point.  This was contingent on seeing a example
 implementation showing that it is possible to implement this
 requirement without loss of efficiency.  John Potter provided such a
-reference implementation.]</i></p>
+example implementation.]</i></p>
 
 
 <p><i>[Redmond: The LWG was reluctant to adopt the proposal that
@@ -9656,7 +9736,7 @@ logarithmic in general, but amortized constant if <tt>t</tt> is inserted right <
 
 <hr>
 <h3><a name="234"></a>234. Typos in allocator definition</h3>
-<p><b>Section:</b> 20.6.1.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -10184,12 +10264,12 @@ Jerry Schwarz's message c++std-lib-7618.</p>
 
 <hr>
 <h3><a name="247"></a>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3>
-<p><b>Section:</b> 23.2.5.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-06-06</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>Paragraph 2 of 23.2.5.4 [vector.modifiers] describes the complexity
+<p>Paragraph 2 of 23.2.6.4 [vector.modifiers] describes the complexity
 of <tt>vector::insert</tt>:</p>
 
    <blockquote><p>
@@ -10226,7 +10306,7 @@ paragraph 3):</p>
 
 <p><b>Proposed resolution:</b></p>
 
-<p>Change Paragraph 2 of 23.2.5.4 [vector.modifiers] to</p>
+<p>Change Paragraph 2 of 23.2.6.4 [vector.modifiers] to</p>
    <blockquote><p>
    Complexity: The complexity is linear in the number of elements 
    inserted plus the distance to the end of the vector.
@@ -10292,13 +10372,13 @@ input facets.</p>
 
 <hr>
 <h3><a name="250"></a>250. splicing invalidates iterators</h3>
-<p><b>Section:</b> 23.2.3.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Brian Parker  <b>Date:</b> 2000-07-14</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Section 23.2.3.4 [list.ops] states that
+Section 23.2.4.4 [list.ops] states that
 </p>
 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
 </pre>
@@ -10315,14 +10395,14 @@ after <tt>splice</tt>.
 
 <p><b>Proposed resolution:</b></p>
 
-<p>Add a footnote to 23.2.3.4 [list.ops], paragraph 1:</p>
+<p>Add a footnote to 23.2.4.4 [list.ops], paragraph 1:</p>
 <blockquote><p>
 [<i>Footnote:</i> As specified in  [default.con.req], paragraphs
 4-5, the semantics described in this clause applies only to the case
 where allocators compare equal.  --end footnote]
 </p></blockquote>
 
-<p>In 23.2.3.4 [list.ops], replace paragraph 4 with:</p>
+<p>In 23.2.4.4 [list.ops], replace paragraph 4 with:</p>
 <blockquote><p>
 Effects: Inserts the contents of x before position and x becomes 
 empty.  Pointers and references to the moved elements of x now refer to 
@@ -10331,7 +10411,7 @@ moved elements will continue to refer to their elements, but they now
 behave as iterators into *this, not into x.
 </p></blockquote>
 
-<p>In 23.2.3.4 [list.ops], replace paragraph 7 with:</p>
+<p>In 23.2.4.4 [list.ops], replace paragraph 7 with:</p>
 <blockquote><p>
 Effects: Inserts an element pointed to by i from list x before 
 position and removes the element from x. The result is unchanged if 
@@ -10341,7 +10421,7 @@ to refer to this same element but as a member of *this.  Iterators to *i
 behave as iterators into *this, not into x.
 </p></blockquote>
 
-<p>In 23.2.3.4 [list.ops], replace paragraph 12 with:</p>
+<p>In 23.2.4.4 [list.ops], replace paragraph 12 with:</p>
 <blockquote><p>
 Requires: [first, last) is a valid range in x. The result is 
 undefined if position is an iterator in the range [first, last).  
@@ -10439,7 +10519,6 @@ issue is stylistic rather than a matter of correctness.</p>
 <h3><a name="253"></a>253. valarray helper functions are almost entirely useless</h3>
 <p><b>Section:</b> 26.5.2.1 [valarray.cons], 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Robert Klarer <b>Date:</b> 2000-07-31</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -11043,6 +11122,7 @@ the need to explicit include or construct a <tt>std::string</tt>.
 <h3><a name="256"></a>256. typo in 27.4.4.2, p17: copy_event does not exist</h3>
 <p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-21</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -12193,13 +12273,13 @@ implement <tt>vector::push_back</tt> in terms of
 
 <hr>
 <h3><a name="278"></a>278. What does iterator validity mean?</h3>
-<p><b>Section:</b> 23.2.3.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2000-11-27</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Section 23.2.3.4 [list.ops] states that
+Section 23.2.4.4 [list.ops] states that
 </p>
 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
 </pre>
@@ -12345,6 +12425,7 @@ this solution is safe and correct.
 <h3><a name="281"></a>281. std::min() and max() requirements overly restrictive</h3>
 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-02</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#486">486</a></p>
@@ -12855,6 +12936,7 @@ m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
 <h3><a name="292"></a>292. effects of a.copyfmt (a)</h3>
 <p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-05</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -12892,11 +12974,11 @@ objects of <tt>rhs</tt>, except that...
 
 <hr>
 <h3><a name="294"></a>294. User defined macros and standard headers</h3>
-<p><b>Section:</b> 17.4.3.1.1 [macro.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 17.4.3.2.1 [macro.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> James Kanze <b>Date:</b> 2001-01-11</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>Paragraph 2 of 17.4.3.1.1 [macro.names] reads: "A
+<p>Paragraph 2 of 17.4.3.2.1 [macro.names] reads: "A
 translation unit that includes a header shall not contain any macros
 that define names declared in that header." As I read this, it
 would mean that the following program is legal:</p>
@@ -12917,7 +12999,7 @@ it isn't stringent enough.</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>For 17.4.3.1.1 [macro.names], replace the current wording, which reads:</p>
+<p>For 17.4.3.2.1 [macro.names], replace the current wording, which reads:</p>
 <blockquote>
      <p>Each name defined as a macro in a header is reserved to the
      implementation for any use if the translation unit includes
@@ -13101,7 +13183,7 @@ For a null value of <i><tt>ptr</tt></i> , does nothing.
 Any other value of <i><tt>ptr</tt></i> shall be a value returned
 earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
 [Footnote: The value must not have been invalidated by an intervening
-call to <tt>operator delete[](void*)</tt> (17.4.3.7 [res.on.arguments]).
+call to <tt>operator delete[](void*)</tt> (17.4.3.8 [res.on.arguments]).
 --- end footnote]
 For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
 allocated by the earlier call to the default <tt>operator new[]</tt>.
@@ -13123,13 +13205,13 @@ or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
 
 <hr>
 <h3><a name="300"></a>300. list::merge() specification incomplete</h3>
-<p><b>Section:</b> 23.2.3.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> John Pedretti <b>Date:</b> 2001-01-23</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The "Effects" clause for list::merge() (23.2.3.4 [list.ops], p23)
+The "Effects" clause for list::merge() (23.2.4.4 [list.ops], p23)
 appears to be incomplete: it doesn't cover the case where the argument
 list is identical to *this (i.e., this == &amp;x). The requirement in the
 note in p24 (below) is that x be empty after the merge which is surely
@@ -13138,7 +13220,7 @@ unintended in this case.
 
 
 <p><b>Proposed resolution:</b></p>
-<p>In 23.2.3.4 [list.ops], replace paragraps 23-25 with:</p>
+<p>In 23.2.4.4 [list.ops], replace paragraps 23-25 with:</p>
 <blockquote>
 <p>
 23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
@@ -13167,7 +13249,7 @@ effects.
 </blockquote>
 
 <p><i>[Copenhagen: The original proposed resolution did not fix all of
-the problems in 23.2.3.4 [list.ops], p22-25.  Three different
+the problems in 23.2.4.4 [list.ops], p22-25.  Three different
 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
 Changing p23, without changing the other two, appears to introduce
 contradictions.  Additionally, "merges the argument list into the
@@ -13507,7 +13589,7 @@ possible.]</i></p>
 
 <hr>
 <h3><a name="307"></a>307. Lack of reference typedefs in container adaptors</h3>
-<p><b>Section:</b> 23.2.3 [list] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.4 [list] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-03-13</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -13515,8 +13597,8 @@ possible.]</i></p>
 <p>From reflector message c++std-lib-8330.  See also lib-8317.</p>
 
 <p>
-The standard is currently inconsistent in 23.2.3.2 [list.capacity]
-paragraph 1 and 23.2.3.3 [list.modifiers] paragraph 1.
+The standard is currently inconsistent in 23.2.4.2 [list.capacity]
+paragraph 1 and 23.2.4.3 [list.modifiers] paragraph 1.
 23.2.3.3/1, for example, says:
 </p>
 
@@ -13975,13 +14057,13 @@ as &lt;memory&gt;.</p>
 
 <hr>
 <h3><a name="315"></a>315. Bad "range" in list::unique complexity</h3>
-<p><b>Section:</b> 23.2.3.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-05-01</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-23.2.3.4 [list.ops], Para 21 describes the complexity of
+23.2.4.4 [list.ops], Para 21 describes the complexity of
 list::unique as: "If the range (last - first) is not empty, exactly
 (last - first) -1 applications of the corresponding predicate,
 otherwise no applications of the predicate)".
@@ -14176,13 +14258,13 @@ should be specified as "Requires".</p>
 
 <hr>
 <h3><a name="320"></a>320. list::assign overspecified</h3>
-<p><b>Section:</b> 23.2.3.1 [list.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.4.1 [list.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-05-17</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.cons].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Section 23.2.3.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
+Section 23.2.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
 the "effects" of a call to erase followed by a call to insert.
 </p>
 
@@ -14208,7 +14290,7 @@ Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Change 23.2.3.1 [list.cons]/7 from:</p>
+<p>Change 23.2.4.1 [list.cons]/7 from:</p>
 
 <blockquote>
 <p>Effects:</p>
@@ -14235,7 +14317,7 @@ add two new rows:</p>
                                   of t.
 </pre>
 
-<p>Change 23.2.3.1 [list.cons]/8 from:</p>
+<p>Change 23.2.4.1 [list.cons]/8 from:</p>
 
 <blockquote>
 <p>Effects:</p>
@@ -14608,18 +14690,18 @@ modifier.</p>
 
 <hr>
 <h3><a name="329"></a>329. vector capacity, reserve and reallocation</h3>
-<p><b>Section:</b> 23.2.5.2 [vector.capacity], 23.2.5.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.6.2 [vector.capacity], 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-07-13</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
 There is an apparent contradiction about which circumstances can cause
-a reallocation of a vector in Section 23.2.5.2 [vector.capacity] and
-section 23.2.5.4 [vector.modifiers].
+a reallocation of a vector in Section 23.2.6.2 [vector.capacity] and
+section 23.2.6.4 [vector.modifiers].
 </p>
 
-<p>23.2.5.2 [vector.capacity],p5 says:</p>
+<p>23.2.6.2 [vector.capacity],p5 says:</p>
 <blockquote><p>
 Notes: Reallocation invalidates all the references, pointers, and iterators
 referring to the elements in the sequence. It is guaranteed that no
@@ -14639,7 +14721,7 @@ greater than the size specified in the most recent call to reserve().
 <p>then the implementation may reallocate the vector for the insert,
 as the size specified in the previous call to reserve was zero.</p>
 
-<p>However, the previous paragraphs (23.2.5.2 [vector.capacity], p1-2) state:</p>
+<p>However, the previous paragraphs (23.2.6.2 [vector.capacity], p1-2) state:</p>
 <blockquote>
 <p>
 (capacity) Returns: The total number of elements the vector
@@ -14655,7 +14737,7 @@ of capacity() otherwise...
 <p>
 This implies that vec.capacity() is still 23, and so the insert()
 should not require a reallocation, as vec.size() is 0. This is backed
-up by 23.2.5.4 [vector.modifiers], p1:
+up by 23.2.6.4 [vector.modifiers], p1:
 </p>
 <blockquote><p>
 (insert) Notes: Causes reallocation if the new size is greater than the old
@@ -14670,7 +14752,7 @@ than the old capacity, I think the intent is clear.
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Change the wording of 23.2.5.2 [vector.capacity] paragraph 5 to:</p>
+<p>Change the wording of 23.2.6.2 [vector.capacity] paragraph 5 to:</p>
 
 <blockquote><p>
 Notes: Reallocation invalidates all the references, pointers, and
@@ -15009,7 +15091,7 @@ library (though a deprecated one).</p>
 <li>17.3.2.3 [objects.within.classes] Private members/1/(2 places)</li>
 <li>17.4 [requirements] Library-wide requirements/1</li>
 <li>17.4.1.2 [headers] Headers/4</li>
-<li>17.4.3.4 [replacement.functions] Replacement functions/1</li>
+<li>17.4.3.5 [replacement.functions] Replacement functions/1</li>
 <li>17.4.4.3 [global.functions] Global or non-member functions/2</li>
 <li>17.4.4.6 [protection.within.classes] Protection within classes/1</li>
 </ul>
@@ -15268,7 +15350,7 @@ complete list of the ones we need.</p>
 
 <hr>
 <h3><a name="341"></a>341. Vector reallocation and swap</h3>
-<p><b>Section:</b> 23.2.5.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.6.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-09-27</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -15281,7 +15363,7 @@ an empty one:</p>
   // vec is now empty, with minimal capacity
 </pre>
 
-<p>However, the wording of 23.2.5.2 [vector.capacity]paragraph 5 prevents
+<p>However, the wording of 23.2.6.2 [vector.capacity]paragraph 5 prevents
 the capacity of a vector being reduced, following a call to
 reserve(). This invalidates the idiom, as swap() is thus prevented
 from reducing the capacity. The proposed wording for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a> does not affect this.  Consequently, the example above
@@ -15314,7 +15396,7 @@ referred to one vector now refer to the other, and vice-versa.</li>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Add a new paragraph after 23.2.5.2 [vector.capacity] paragraph 5:</p>
+<p>Add a new paragraph after 23.2.6.2 [vector.capacity] paragraph 5:</p>
 <blockquote>
 <pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
 </pre>
@@ -16435,7 +16517,6 @@ In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmt
 <h3><a name="375"></a>375. basic_ios should be ios_base in 27.7.1.3</h3>
 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -16462,7 +16543,6 @@ paragraph 14 to "ios_base".
 <h3><a name="376"></a>376. basic_streambuf semantics</h3>
 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -17025,13 +17105,13 @@ implementation is permitted to use <tt>rand</tt>.]
 
 <hr>
 <h3><a name="400"></a>400. redundant type cast in lib.allocator.members</h3>
-<p><b>Section:</b> 20.6.1.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-20.6.1.1 [allocator.members] allocator members, contains
+20.6.5.1 [allocator.members] allocator members, contains
 the following 3 lines:
 </p>
 
@@ -17143,7 +17223,7 @@ issue to Ready status to be voted into the WP at Kona.
 
 <hr>
 <h3><a name="402"></a>402. wrong new expression in [some_]allocator::construct</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements], 20.6.1.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.1.2 [allocator.requirements], 20.6.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
@@ -17151,13 +17231,13 @@ issue to Ready status to be voted into the WP at Kona.
 <p><b>Discussion:</b></p>
 <p>
 This applies to the new expression that is contained in both par12 of
-20.6.1.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
+20.6.5.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
 I think this new expression is wrong, involving unintended side
 effects.
 </p>
 
 
-<p>20.6.1.1 [allocator.members]  contains the following 3 lines:</p>
+<p>20.6.5.1 [allocator.members]  contains the following 3 lines:</p>
 
 <pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
      void construct(pointer p, const_reference val);
@@ -17278,7 +17358,7 @@ Throws: Shall not throw exceptions.
 
 <hr>
 <h3><a name="404"></a>404. May a replacement allocation function be declared inline?</h3>
-<p><b>Section:</b> 17.4.3.4 [replacement.functions], 18.5.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 17.4.3.5 [replacement.functions], 18.5.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-04-24</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -17292,7 +17372,7 @@ in preference to the implementation's definition.
 
 <p>
 Three different parts of the standard mention requirements on
-replacement functions: 17.4.3.4 [replacement.functions], 18.5.1.1 [new.delete.single]
+replacement functions: 17.4.3.5 [replacement.functions], 18.5.1.1 [new.delete.single]
 and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto].
 </p>
 
@@ -17310,7 +17390,7 @@ and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto].
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add a new sentence to the end of 17.4.3.4 [replacement.functions] paragraph 3:
+Add a new sentence to the end of 17.4.3.5 [replacement.functions] paragraph 3:
 "The program's definitions shall not be specified as <tt>inline</tt>.
 No diagnostic is required."
 </p>
@@ -17367,7 +17447,7 @@ type."
 
 <hr>
 <h3><a name="406"></a>406. vector::insert(s) exception safety</h3>
-<p><b>Section:</b> 23.2.5.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
+<p><b>Section:</b> 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2003-04-27</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
@@ -17384,7 +17464,7 @@ existing implementation.
 
 
 <p><b>Proposed resolution:</b></p>
-<p>Replace 23.2.5.4 [vector.modifiers] paragraph 1 with:</p>
+<p>Replace 23.2.6.4 [vector.modifiers] paragraph 1 with:</p>
 <blockquote><p>
   1- Notes: Causes reallocation if the new size is greater than the
   old capacity. If no reallocation happens, all the iterators and
@@ -17522,22 +17602,22 @@ flags.]</i></p>
 
 <hr>
 <h3><a name="410"></a>410. Missing semantics for stack and queue comparison operators</h3>
-<p><b>Section:</b> 23.2.3.1 [list.cons], 23.2.3.3 [list.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.4.1 [list.cons], 23.2.4.3 [list.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Hans Bos <b>Date:</b> 2003-06-07</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.cons].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Sections 23.2.3.1 [list.cons] and 23.2.3.3 [list.modifiers] list
+Sections 23.2.4.1 [list.cons] and 23.2.4.3 [list.modifiers] list
 comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
-stack.  Only the semantics for queue::operator== (23.2.3.1 [list.cons] par2) and queue::operator&lt; (23.2.3.1 [list.cons]
+stack.  Only the semantics for queue::operator== (23.2.4.1 [list.cons] par2) and queue::operator&lt; (23.2.4.1 [list.cons]
 par3) are defined.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 
-<p>Add the following new paragraphs after 23.2.3.1 [list.cons]
+<p>Add the following new paragraphs after 23.2.4.1 [list.cons]
   paragraph 3:</p>
 
 <blockquote>
@@ -17560,7 +17640,7 @@ par3) are defined.
 
 </blockquote>
 
-<p>Add the following paragraphs at the end of 23.2.3.3 [list.modifiers]:</p>
+<p>Add the following paragraphs at the end of 23.2.4.3 [list.modifiers]:</p>
 
 <blockquote>
 
@@ -17728,7 +17808,7 @@ then the caught exception is rethrown.
 
 <hr>
 <h3><a name="414"></a>414. Which iterators are invalidated by v.erase()?</h3>
-<p><b>Section:</b> 23.2.5.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-08-19</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -17783,7 +17863,7 @@ techniques.)
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In 23.2.5.4 [vector.modifiers] paragraph 3, change "Invalidates all the
+In 23.2.6.4 [vector.modifiers] paragraph 3, change "Invalidates all the
 iterators and references after the point of the erase" to
 "Invalidates iterators and references at or after the point of the
 erase". 
@@ -17946,7 +18026,7 @@ allowed to just declare it without providing a full definition?
 
 <hr>
 <h3><a name="422"></a>422. explicit specializations of member functions of class templates</h3>
-<p><b>Section:</b> 17.4.3.1 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -17966,7 +18046,7 @@ the program) by relying on the "as if" rule.
 <p><b>Proposed resolution:</b></p>
 
 <p>
-  Add the following sentence to 17.4.3.1 [reserved.names], p1:
+  Add the following sentence to 17.4.3.2 [reserved.names], p1:
 </p>
 
 <blockquote><p>
@@ -18014,7 +18094,7 @@ use the right wording.]</i></p>
 
 <hr>
 <h3><a name="425"></a>425. return value of std::get_temporary_buffer</h3>
-<p><b>Section:</b> 20.6.3 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.8 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -18160,7 +18240,6 @@ which is most likely not the intent.
 <h3><a name="432"></a>432. stringbuf::overflow() makes only one write position available</h3>
 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Christian W Brock <b>Date:</b> 2003-09-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -19303,7 +19382,6 @@ undefined."
 <h3><a name="453"></a>453. basic_stringbuf::seekoff need not always fail for an empty stream</h3>
 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -19529,6 +19607,7 @@ names within the namespace <tt>std</tt>.</ins> <i>-- end example</i>]
 <h3><a name="457"></a>457. bitset constructor: incorrect number of initialized bits</h3>
 <p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
  <b>Submitter:</b> Dag Henriksson <b>Date:</b> 2004-01-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#bitset.cons">active issues</a> in [bitset.cons].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -19703,7 +19782,7 @@ An implementation may also accept additional implementation-defined formats.
 
 <hr>
 <h3><a name="464"></a>464. Suggestion for new member functions in standard containers</h3>
-<p><b>Section:</b> 23.2.5 [vector], 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.6 [vector], 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2004-05-12</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -19733,14 +19812,14 @@ at() (which will then throw if the vector is empty). </li>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>In 23.2.5 [vector], add the following to the <tt>vector</tt>
+<p>In 23.2.6 [vector], add the following to the <tt>vector</tt>
   synopsis after "element access" and before "modifiers":</p>
 <pre>  // <i>[lib.vector.data] data access</i>
   pointer       data();
   const_pointer data() const;
 </pre>
 
-<p>Add a new subsection of 23.2.5 [vector]:</p>
+<p>Add a new subsection of 23.2.6 [vector]:</p>
 <blockquote>
 <p>23.2.4.x <tt>vector</tt> data access</p>
 <pre>   pointer       data();
@@ -19954,7 +20033,7 @@ the value need not be valid.
 
 <hr>
 <h3><a name="469"></a>469. vector&lt;bool&gt; ill-formed relational operators</h3>
-<p><b>Section:</b> 23.2.5 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
+<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</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#vector">issues</a> in [vector].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
@@ -20321,13 +20400,13 @@ requirements of charT (described in 21 [strings]).
 
 <hr>
 <h3><a name="496"></a>496. Illegal use of "T" in vector&lt;bool&gt;</h3>
-<p><b>Section:</b> 23.2.5 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> richard@ex-parrot.com <b>Date:</b> 2005-02-10</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.2.5 [vector],
+In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.2.6 [vector],
 the non-template assign() function has the signature</p>
 
 <pre>  void assign( size_type n, const T&amp; t );
@@ -20493,6 +20572,7 @@ Precondition:  <tt>distribution().operator()(e,value)</tt> is well-formed.
 <h3><a name="508"></a>508. Bad parameters for ranlux64_base_01</h3>
 <p><b>Section:</b> 26.4.5 [rand.predef], TR1 5.1.5 [tr.rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Walter Brown <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#rand.predef">issues</a> in [rand.predef].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
@@ -20799,6 +20879,98 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
+<hr>
+<h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3>
+<p><b>Section:</b> 20.5.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2005-10-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The original bind proposal gives the guarantee that tr1::bind(f, t1,
+..., tN) does not throw when the copy constructors of f, t1, ..., tN
+don't.
+</p>
+
+<p>
+This guarantee is not present in the final version of TR1.
+</p>
+
+<p>
+I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
+</p>
+
+<p><i>[
+Berlin: not quite editorial, needs proposed wording.
+]</i></p>
+
+<p><i>[
+Batavia:  Doug to translate wording to variadic templates.
+]</i></p>
+
+
+<p><i>[
+Toronto:  We agree but aren't quite happy with the wording.  The "t"'s no
+longer refer to anything.  Alan to provide improved wording.
+]</i></p>
+
+
+
+<p><i>[
+Pre-Bellevue:  Alisdair provided wording.
+]</i></p>
+
+
+<p>
+TR1 proposed resolution:
+</p>
+
+<blockquote>
+<p>
+In TR1 3.6.3 [tr.func.bind.bind], add a new paragraph after p2:
+</p>
+<blockquote><p>
+<i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
+throws an exception.
+</p></blockquote>
+
+<p>
+Add a new paragraph after p4:
+</p>
+<blockquote><p>
+<i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
+throws an exception.
+</p></blockquote>
+
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.5.11.1.3 [func.bind.bind], add a new paragraph after p2:
+</p>
+
+<blockquote>
+<i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types
+in the <tt>BoundArgs...</tt> pack expansion throws an exception. 
+</blockquote>
+
+<p>
+In 20.5.11.1.3 [func.bind.bind], add a new paragraph after p4:
+</p>
+
+<blockquote>
+<i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types
+in the <tt>BoundArgs...</tt> pack expansion throws an exception. 
+</blockquote>
+
+
+
+
+
+
 <hr>
 <h3><a name="530"></a>530. Must elements of a string be contiguous?</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#WP">WP</a>
@@ -20931,7 +21103,7 @@ writing to out of bounds memory when <tt>n == 0</tt>.  Martin provided fix.
 
 <hr>
 <h3><a name="533"></a>533. typo in 2.2.3.10/1</h3>
-<p><b>Section:</b> 20.6.6.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
+<p><b>Section:</b> 20.6.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-11-09</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
@@ -21256,7 +21428,7 @@ Otherwise CopyConstructible is not required.
 
 <hr>
 <h3><a name="540"></a>540. shared_ptr&lt;void&gt;::operator*()</h3>
-<p><b>Section:</b> 20.6.6.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-15</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -21314,7 +21486,7 @@ definition) of the function shall be well-formed.</ins>
 
 <hr>
 <h3><a name="541"></a>541. shared_ptr template assignment and void</h3>
-<p><b>Section:</b> 20.6.6.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.12.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-16</p>
 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
@@ -21395,7 +21567,7 @@ public:
 
 <hr>
 <h3><a name="542"></a>542. shared_ptr observers</h3>
-<p><b>Section:</b> 20.6.6.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-18</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -21435,7 +21607,7 @@ capture the intent.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 20.6.6.2.5 [util.smartptr.shared.obs] p12:
+Change 20.6.12.2.5 [util.smartptr.shared.obs] p12:
 </p>
 <blockquote><p>
 [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
@@ -21443,7 +21615,7 @@ debugging and testing purposes, not for production code.</del> --<i>end note</i>
 </p></blockquote>
 
 <p>
-Change 20.6.6.3.5 [util.smartptr.weak.obs] p3:
+Change 20.6.12.3.5 [util.smartptr.weak.obs] p3:
 </p>
 <blockquote><p>
 [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
@@ -21532,7 +21704,7 @@ lengths, and strides, as explained in the previous section.
 
 <hr>
 <h3><a name="545"></a>545. When is a deleter deleted?</h3>
-<p><b>Section:</b> 20.6.6.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -21550,7 +21722,7 @@ instances). We should say which it is.
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Add after the first sentence of 20.6.6.2.11 [util.smartptr.getdeleter]/1:
+Add after the first sentence of 20.6.12.2.11 [util.smartptr.getdeleter]/1:
 </p>
 <blockquote>
 <p>
@@ -21746,498 +21918,535 @@ automatically.
 
 
 <hr>
-<h3><a name="566"></a>566. array forms of unformatted input function undefined for zero-element arrays</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
+<h3><a name="561"></a>561. inserter overly generic</h3>
+<p><b>Section:</b> 24.4.2.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-21</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-        <p>
-
-The array forms of unformatted input functions don't have well-defined
-semantics for zero-element  arrays in a couple of  cases. The affected
-ones (<tt>istream::get()</tt> and  <tt>getline()</tt>) are supposed to
-terminate when <tt>(n - 1)</tt> characters are stored, which obviously
-can never be true when <tt>(n == 0)</tt> to start with.
-
-        </p>
-
-
-<p><b>Proposed resolution:</b></p>
-        <p>
-
-I  propose  the following  changes  (references  are  relative to  the
-Working Draft (document N1804).
-
-        </p>
-        <p>
-
-Change 27.6.1.3, p8 (<tt>istream::get()</tt>), bullet 1 as follows:
-
-        </p>
-        <blockquote>
-            <p>
-
-<ins>if  <tt>(n  &lt; 1)</tt>  is  true  or  </ins> <tt>(n  -  1)</tt>
-characters are stored;
+<p>
+The declaration of <tt>std::inserter</tt> is:
+</p>
 
-            </p>
-        </blockquote>
-        <p>
+<blockquote><pre>template &lt;class Container, class Iterator&gt;
+insert_iterator&lt;Container&gt;
+inserter(Container&amp; x, Iterator i);
+</pre></blockquote>
 
-Similarly, change  27.6.1.3, p18 (<tt>istream::getline()</tt>), bullet
-3 as follows:
+<p>
+The template parameter <tt>Iterator</tt> in this function is completely unrelated
+to the template parameter <tt>Container</tt> when it doesn't need to be.  This
+causes the code to be overly generic.  That is, any type at all can be deduced
+as <tt>Iterator</tt>, whether or not it makes sense.  Now the same is true of
+<tt>Container</tt>.  However, for every free (unconstrained) template parameter
+one has in a signature, the opportunity for a mistaken binding grows geometrically.
+</p>
 
-        </p>
-        <blockquote>
-            <p>
+<p>
+It would be much better if <tt>inserter</tt> had the following signature instead:
+</p>
 
-<ins><tt>(n &lt; 1)</tt> is  true or </ins><tt>(n - 1)</tt> characters
-are     stored     (in    which     case     the    function     calls
-<tt>setstate(failbit)</tt>).
+<blockquote><pre>template &lt;class Container&gt;
+insert_iterator&lt;Container&gt;
+inserter(Container&amp; x, typename Container::iterator i);
+</pre></blockquote>
 
-            </p>
-        </blockquote>
-        <p>
+<p>
+Now there is only one free template parameter.  And the second argument to
+<tt>inserter</tt> must be implicitly convertible to the container's iterator,
+else the call will not be a viable overload (allowing other functions in the
+overload set to take precedence).  Furthermore, the first parameter must have a
+nested type named <tt>iterator</tt>, or again the binding to <tt>std::inserter</tt>
+is not viable.  Contrast this with the current situation
+where any type can bind to <tt>Container</tt> or <tt>Iterator</tt> and those
+types need not be anything closely related to containers or iterators.
+</p>
 
-Finally, change p21 as follows:
+<p>
+This can adversely impact well written code.  Consider:
+</p>
 
-        </p>
-        <blockquote>
-            <p>
+<blockquote><pre>#include &lt;iterator&gt;
+#include &lt;string&gt;
 
-In any  case, <ins>provided  <tt>(n &gt; 0)</tt>  is true,  </ins>it then
-stores  a null  character  (using charT())  into  the next  successive
-location of the array.
+namespace my
+{
 
-            </p>
-        </blockquote>
+template &lt;class String&gt;
+struct my_type {};
 
+struct my_container
+{
+template &lt;class String&gt;
+void push_back(const my_type&lt;String&gt;&amp;);
+};
 
+template &lt;class String&gt;
+void inserter(const my_type&lt;String&gt;&amp; m, my_container&amp; c) {c.push_back(m);}
 
+}  // my
 
+int main()
+{
+    my::my_container c;
+    my::my_type&lt;std::string&gt; m;
+    inserter(m, c);
+}
+</pre></blockquote>
 
-<hr>
-<h3><a name="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3>
-<p><b>Section:</b> 20.6.6.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-04-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-[tr.util.smartptr.shared.dest] says in its second bullet:
+Today this code fails because the call to <tt>inserter</tt> binds to
+<tt>std::inserter</tt> instead of to <tt>my::inserter</tt>.  However with the
+proposed change <tt>std::inserter</tt> will no longer be a viable function which
+leaves only <tt>my::inserter</tt> in the overload resolution set.  Everything
+works as the client intends.
 </p>
 
 <p>
-"If *this shares ownership with another shared_ptr instance (use_count() &gt; 1),
-decrements that instance's use count."
+To make matters a little more insidious, the above example works today if you
+simply change the first argument to an rvalue:
 </p>
 
+<blockquote><pre>    inserter(my::my_type(), c);
+</pre></blockquote>
+
 <p>
-The problem with this formulation is that it presupposes the existence of an
-"use count" variable that can be decremented and that is part of the state of a
-shared_ptr instance (because of the "that instance's use count".)
+It will also work if instantiated with some string type other than
+<tt>std::string</tt> (or any other <tt>std</tt> type).  It will also work if
+<tt>&lt;iterator&gt;</tt> happens to not get included.
 </p>
 
 <p>
-This is contrary to the spirit of the rest of the specification that carefully
-avoids to require an use count variable. Instead, use_count() is specified to
-return a value, a number of instances.
+And it will fail again for such inocuous reaons as <tt>my_type</tt> or
+<tt>my_container</tt> privately deriving from any <tt>std</tt> type.
 </p>
 
 <p>
-In multithreaded code, the usual implicit assumption is that a shared variable
-should not be accessed by more than one thread without explicit synchronization,
-and by introducing the concept of an "use count" variable, the current wording
-implies that two shared_ptr instances that share ownership cannot be destroyed
-simultaneously.
+It seems unfortunate that such simple changes in the client's code can result
+in such radically differing behavior.
 </p>
 
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-In addition, if we allow the interpretation that an use count variable is part
-of shared_ptr's state, this would lead to other undesirable consequences WRT
-multiple threads. For example,
+Change 24.2:
 </p>
 
-<blockquote><pre>p1 = p2;
+<blockquote><p>
+<b>24.2 Header</b> <tt>&lt;iterator&gt;</tt> <b>synopsis</b>
+</p>
+<blockquote><pre>...
+template &lt;class Container<del>, class Iterator</del>&gt;
+   insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
+...
 </pre></blockquote>
+</blockquote>
 
 <p>
-would now visibly modify the state of p2, a "write" operation, requiring a lock.
+Change 24.4.2.5:
 </p>
 
+<blockquote><p>
+<b>24.4.2.5 Class template</b> <tt>insert_iterator</tt></p>
+<blockquote><pre>...
+template &lt;class Container<del>, class Iterator</del>&gt;
+   insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
+...
+</pre></blockquote>
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to:
+Change 24.4.2.6.5:
 </p>
 
 <blockquote>
-<ul>
-<li>If <tt>*this</tt> is <i>empty</i> <ins>or shares ownership with another
-<tt>shared_ptr</tt> instance (<tt>use_count() &gt; 1</tt>)</ins>, there are no side effects.</li>
-<li><del>If <tt>*this</tt> <i>shares ownership</i> with another <tt>shared_ptr</tt> instance
-(<tt>use_count() &gt; 1</tt>), decrements that instance's use count.</del></li>
-</ul>
-</blockquote>
-
 <p>
-Add the following paragraph after [lib.util.smartptr.shared.dest]/1:
+<b>24.4.2.6.5</b> <tt>inserter</tt>
 </p>
-
+<pre>template &lt;class Container<del>, class Inserter</del>&gt;
+   insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Inserter</del> <ins>typename Container::iterator</ins> i);
+</pre>
 <blockquote><p>
-[<i>Note:</i> since the destruction of <tt>*this</tt> decreases the number of instances in
-<tt>*this</tt>'s ownership group by one, all <tt>shared_ptr</tt> instances that share ownership
-with <tt>*this</tt> will report an <tt>use_count()</tt> that is one lower than its previous value
-after <tt>*this</tt> is destroyed. <i>--end note</i>]
+-1- <i>Returns:</i> <tt>insert_iterator&lt;Container&gt;(x,<del>typename Container::iterator(</del>i<del>)</del>)</tt>.
 </p></blockquote>
+</blockquote>
+
+
+
+<p><i>[
+Kona (2007): This issue will probably be addressed as a part of the
+concepts overhaul of the library anyway, but the proposed resolution is
+correct in the absence of concepts. Proposed Disposition: Ready
+]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="576"></a>576. find_first_of is overconstrained</h3>
-<p><b>Section:</b> 25.1.4 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Doug Gregor <b>Date:</b> 2006-04-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
+<h3><a name="562"></a>562. stringbuf ctor inefficient</h3>
+<p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
+        <p>
+
+For  better efficiency,  the requirement  on the  stringbuf  ctor that
+takes  a  string  argument  should  be  loosened  up  to  let  it  set
+<code>epptr()</code>  beyond  just   one  past  the  last  initialized
+character  just like  <code>overflow()</code> has  been changed  to be
+allowed  to  do   (see  issue  432).  That  way   the  first  call  to
+<code>sputc()</code> on  an object won't  necessarily cause a  call to
+<code>overflow</code>. The corresponding change  should be made to the
+string overload of the <code>str()</code> member function.
+
+        </p>
+
+
+<p><b>Proposed resolution:</b></p>
+        <p>
+
+Change 27.7.1.1, p3 of the Working Draft, N1804, as follows:
+
+        </p>
+
+<blockquote><pre>explicit basic_stringbuf(const basic_string&lt;charT,traits,Allocator&gt;&amp; <i>s<del>tr</del></i>,
+               ios_base::openmode <i>which</i> = ios_base::in | ios_base::out);
+</pre>
+
 <p>
-In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
-find_first_of are specified to require Forward Iterators, as follows:
+-3- <i>Effects:</i>  Constructs an object of class <tt>basic_stringbuf</tt>,
+initializing the base class with <tt>basic_streambuf()</tt>
+(27.5.2.1), and initializing <tt><i>mode</i></tt> with <tt><i>which</i></tt>.
+Then <ins>calls <tt>str(<i>s</i>)</tt>.</ins> <del>copies the content of
+<i>str</i> into the <tt>basic_stringbuf</tt> underlying character
+sequence. If <tt><i>which</i> &amp; ios_base::out</tt> is true, initializes the
+output sequence such that <tt>pbase()</tt> points to the first underlying
+character, <tt>epptr()</tt> points one past the last underlying character, and
+<tt>pptr()</tt> is equal to <tt>epptr()</tt> if <tt><i>which</i> &amp; ios_base::ate</tt>
+is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
+<tt>which &amp; ios_base::in</tt> is true, initializes the input sequence such
+that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying 
+character and <tt>egptr()</tt> points one past the last underlying character.</del>
 </p>
+</blockquote>
 
-<blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
-  ForwardIterator1
-  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
-                        ForwardIterator2 first2, ForwardIterator2 last2);
-template&lt;class ForwardIterator1, class ForwardIterator2,
-                  class BinaryPredicate&gt;
-ForwardIterator1
-  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
-                         ForwardIterator2 first2, ForwardIterator2 last2,
-                        BinaryPredicate pred);
-</pre></blockquote>
+        <p>
+
+Change the Effects clause of the <code>str()</code> in 27.7.1.2, p2 to
+read:
 
+        </p>
+<blockquote>
 <p>
-However, ForwardIterator1 need not actually be a Forward Iterator; an Input
-Iterator suffices, because we do not need the multi-pass property of the Forward
-Iterator or a true reference.
+-2- <i>Effects:</i> Copies the content<ins>s</ins> of <tt><i>s</i></tt> into the
+<tt>basic_stringbuf</tt> underlying character sequence <ins>and
+initializes the input and output sequences according to <tt><i>mode</i></tt></ins>.
+<del>If
+<tt><i>mode</i> &amp; ios_base::out</tt> is true, initializes the output
+sequence such that <tt>pbase()</tt> points to the first underlying character, 
+<tt>epptr()</tt> points one past the last underlying character, and <tt>pptr()</tt>
+is equal to <tt>epptr()</tt> if <tt><i>mode</i> &amp; ios_base::in</tt>
+is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
+<tt>mode &amp; ios_base::in</tt> is true, initializes the input sequence 
+such that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying
+character and <tt>egptr()</tt> points one past the last underlying character.</del>
 </p>
 
+        <p>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the declarations of <tt>find_first_of</tt> to:
-</p>
+<ins>-3- <i>Postconditions:</i>  If  <code>mode  &amp; ios_base::out</code>  is  true,
+<code>pbase()</code>  points  to the  first  underlying character  and
+<code>(epptr() &gt;= pbase() + s.size())</code> holds; in addition, if
+<code>mode &amp; ios_base::in</code> is true, <code>(pptr() == pbase()
++ s.data())</code>  holds, otherwise <code>(pptr()  == pbase())</code>
+is   true.    If  <code>mode   &amp;   ios_base::in</code>  is   true,
+<code>eback()</code>  points to  the first  underlying  character, and
+<code>(gptr()  ==  eback())</code>  and  <code>(egptr() ==  eback()  +
+s.size())</code> hold.</ins>
+
+        </p>
+</blockquote>
 
-<blockquote><pre>template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2&gt;
-  <del>ForwardIterator1</del><ins>InputIterator1</ins>
-  find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
-                        ForwardIterator2 first2, ForwardIterator2 last2);
-template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2,
-                  class BinaryPredicate&gt;
-<del>ForwardIterator1</del><ins>InputIterator1</ins>
-  find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
-                         ForwardIterator2 first2, ForwardIterator2 last2,
-                        BinaryPredicate pred);
-</pre></blockquote>
 
+<p><i>[
+Kona (2007) Moved to Ready.
+]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="577"></a>577. upper_bound(first, last, ...) cannot return last</h3>
-<p><b>Section:</b> 25.3.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-05-03</p>
+<h3><a name="563"></a>563. stringbuf seeking from end</h3>
+<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-ISO/IEC 14882:2003 says:
+According to  Table 92  (unchanged by issue  432), when  <code>(way ==
+end)</code> the  <code>newoff</code> value in out mode  is computed as
+the difference between <code>epptr()</code> and <code>pbase()</code>.
 </p>
+        <p>
 
-<blockquote>
-<p>
-25.3.3.2 upper_bound
-</p>
-<p>
-<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
-<tt>[<i>first</i>, <i>last</i>)</tt> such that
-for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
-conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
-</p>
-</blockquote>
+This value  isn't meaningful unless the  value of <code>epptr()</code>
+can be  precisely controlled by a  program.  That used  to be possible
+until  we accepted the  resolution of  issue 432,  but since  then the
+requirements on <code>overflow()</code> have  been relaxed to allow it
+to  make  more than  1  write  position  available (i.e.,  by  setting
+<code>epptr()</code>     to     some     unspecified    value     past
+<code>pptr()</code>).      So    after     the    first     call    to
+<code>overflow()</code>  positioning the  output sequence  relative to
+end will have unspecified results.
 
-<p>
-From the description above, upper_bound cannot return last, since it's
-not in the interval [first, last). This seems to be a typo, because if
-value is greater than or equal to any other values in the range, or if
-the range is empty, returning last seems to be the intended behaviour.
-The corresponding interval for lower_bound is also [first, last].
-</p>
+        </p>
+        <p>
+
+In  addition,  in <code>in|out</code>  mode,  since <code>(egptr()  ==
+epptr())</code> need not hold, there are two different possible values
+for   <code>newoff</code>:    <code>epptr()   -   pbase()</code>   and
+<code>egptr() - eback()</code>.
+
+        </p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>
-Change [lib.upper.bound]:
-</p>
+        <p>
+
+Change the <code>newoff</code>  column in the last row  of Table 94 to
+read:
+
+        </p>
+<blockquote><p>
+
+the <del>end</del> <ins>high mark</ins> pointer minus the beginning 
+pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>).
+
+</p></blockquote>
 
-<blockquote>
-<p>
-<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
-<tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that
-for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
-conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
-</p>
-</blockquote>
 
+<p><i>[
+Kona (2007) Moved to Ready.
+]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3>
-<p><b>Section:</b> 20.6.1.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
+<h3><a name="566"></a>566. array forms of unformatted input function undefined for zero-element arrays</h3>
+<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
         <p>
 
-The     description    of     the     allocator    member     function
-<code>allocate()</code>  requires  that  the <i>hint</i>  argument  be
-either 0 or a  value previously returned from <code>allocate()</code>.
-Footnote 227 further suggests that  containers may pass the address of
-an adjacent element as this argument.
+The array forms of unformatted input functions don't have well-defined
+semantics for zero-element  arrays in a couple of  cases. The affected
+ones (<tt>istream::get()</tt> and  <tt>getline()</tt>) are supposed to
+terminate when <tt>(n - 1)</tt> characters are stored, which obviously
+can never be true when <tt>(n == 0)</tt> to start with.
 
         </p>
+
+
+<p><b>Proposed resolution:</b></p>
         <p>
 
-I  believe  that  either  the  footnote  is  wrong  or  the  normative
-requirement that  the argument be  a value previously returned  from a
-call to  <code>allocate()</code> is wrong. The latter  is supported by
-the resolution  to issue 20-004 proposed in  c++std-lib-3736 by Nathan
-Myers. In addition,  the <i>hint</i> is an ordinary  void* and not the
-<code>pointer</code>  type returned  by  <code>allocate()</code>, with
-the  two  types potentially  being  incompatible  and the  requirement
-impossible to satisfy.
+I  propose  the following  changes  (references  are  relative to  the
+Working Draft (document N1804).
 
         </p>
         <p>
 
-See also c++std-lib-14323 for some  more context on where this came up
-(again).
+Change 27.6.1.3, p8 (<tt>istream::get()</tt>), bullet 1 as follows:
 
         </p>
-    
+        <blockquote>
+            <p>
 
-    <p><b>Proposed resolution:</b></p>
+<ins>if  <tt>(n  &lt; 1)</tt>  is  true  or  </ins> <tt>(n  -  1)</tt>
+characters are stored;
+
+            </p>
+        </blockquote>
         <p>
 
-Remove  the requirement  in  20.6.1.1, p4  that  the hint  be a  value
-previously returned from <code>allocate()</code>. Specifically, change
-the paragraph as follows:
+Similarly, change  27.6.1.3, p18 (<tt>istream::getline()</tt>), bullet
+3 as follows:
 
         </p>
-<p>
-<del><i>Requires</i>: <i>hint</i> either 0 or previously obtained  from  member
-<code>allocate</code>  and  not  yet passed  to member  <code>deallocate</code>.
-The value hint may be used by an implementation to help improve performance
-<sup>223)</sup>.</del> <ins>[<i>Note:</i> The value <i>hint</i> may be used by an
-implementation to help improve performance. -- <i>end note</i>]</ins>
-</p>
-<blockquote><p>
-<del>[Footnote: <sup>223)</sup>In a container member function, the address of an
-adjacent element is often a good choice to pass for this argument.</del>
-</p></blockquote>
-    
+        <blockquote>
+            <p>
+
+<ins><tt>(n &lt; 1)</tt> is  true or </ins><tt>(n - 1)</tt> characters
+are     stored     (in    which     case     the    function     calls
+<tt>setstate(failbit)</tt>).
+
+            </p>
+        </blockquote>
+        <p>
+
+Finally, change p21 as follows:
+
+        </p>
+        <blockquote>
+            <p>
+
+In any  case, <ins>provided  <tt>(n &gt; 0)</tt>  is true,  </ins>it then
+stores  a null  character  (using charT())  into  the next  successive
+location of the array.
+
+            </p>
+        </blockquote>
+
+
 
 
 
 <hr>
-<h3><a name="586"></a>586. string inserter not a formatted function</h3>
-<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
+<h3><a name="567"></a>567. streambuf inserter and extractor should be unformatted</h3>
+<p><b>Section:</b> 27.6 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-25</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
         <p>
 
-Section  and paragraph  numbers  in  this paper  are  relative to  the
-working draft document number N2009 from 4/21/2006.
+Issue  60 explicitly made  the extractor  and inserter  operators that
+take a  <tt>basic_streambuf*</tt> argument formatted  input and output
+functions,  respectively.  I  believe that's  wrong, certainly  in the
+case of  the extractor, since formatted functions  begin by extracting
+and  discarding  whitespace.  The  extractor  should  not discard  any
+characters.
 
         </p>
 
+
+<p><b>Proposed resolution:</b></p>
         <p>
 
-The  <code>basic_string</code> extractor  in 21.3.7.9,  p1  is clearly
-required  to  behave  as  a   formatted  input  function,  as  is  the
-<code>std::getline()</code> overload for string described in p7.
+I propose to  change each operator to behave  as unformatted input and
+output function,  respectively. The changes below are  relative to the
+working draft document number N1804.
 
         </p>
         <p>
 
-However, the <code>basic_string</code> inserter described in p5 of the
-same section has no such requirement. This has implications on how the
-operator  responds  to  exceptions thrown  from  <code>xsputn()</code>
-(formatted  output functions are  required to  set <code>badbit</code>
-and swallow  the exception unless  <code>badbit</code> is also  set in
-<code>exceptions()</code>; the  string inserter doesn't  have any such
-requirement).
+Specifically, change 27.6.1.2.3, p14 as follows:
 
         </p>
+
+            <blockquote>
         <p>
 
-I don't  see anything in the  spec for the string  inserter that would
-justify requiring  it to treat  exceptions differently from  all other
-similar operators. (If it did, I think it should be made this explicit
-by saying  that the  operator "does not  behave as a  formatted output
-function" as has been made customary by the adoption of the resolution
-of issue 60).
+<i>Effects</i>:  Behaves as  a<ins>n un</ins>formatted  input function
+(as   described   in   <del>27.6.1.2.1</del><ins>27.6.1.3,   paragraph
+1</ins>).
 
         </p>
-    
-
-    <p><b>Proposed resolution:</b></p>
+            </blockquote>
         <p>
 
-I propose to change the Effects clause in 21.3.7.9, p5, as follows:
+And change 27.6.2.5.3, p7 as follows:
 
         </p>
+
             <blockquote>
         <p>
 
-<i>Effects</i>: <del>Begins by constructing a  sentry object k as if k
-were    constructed    by    typename    <code>basic_ostream&lt;charT,
-traits&gt;::sentry   k   (os)</code>.    If  <code>bool(k)</code>   is
-<code>true</code>, </del><ins>Behaves  as a formatted  output function
-(27.6.2.5.1).   After constructing  a  <code>sentry</code> object,  if
-this  object returns <code>true</code>  when converted  to a  value of
-type   <code>bool</code>,   determines   padding   as   described   in
-22.2.2.2.2</ins>,  then inserts the  resulting sequence  of characters
-<code><i>seq</i></code> as if by calling <code>os.rdbuf()-&gt;sputn(seq ,
-n)</code>,    where   <code><i>n</i></code>    is   the    larger   of
-<code>os.width()</code>   and   <code>str.size()</code>;  then   calls
-<code>os.width(0)</code>.  <del>If  the  call  to sputn  fails,  calls
-<code>os.setstate(ios_base::failbit)</code>.</del>
+<i>Effects</i>: Behaves  as a<ins>n un</ins>formatted  output function
+(as   described   in   <del>27.6.2.5.1</del><ins>27.6.2.6,   paragraph
+1</ins>).
 
         </p>
             </blockquote>
-        <p>
 
-This proposed  resilution assumes the  resolution of issue  394 (i.e.,
-that   all   formatted   output   functions  are   required   to   set
-<code>ios_base::badbit</code>  in response  to any  kind  of streambuf
-failure),   and   implicitly   assumes   that  a   return   value   of
-<code>sputn(seq,  <i>n</i>)</code>  other  than  <code><i>n</i></code>
-indicates a failure.
 
-        </p>
-    
+<p><i>[
+Kona (2007): Proposed Disposition: Ready
+]</i></p>
+
+
 
 
 
 <hr>
-<h3><a name="589"></a>589. Requirements on iterators of member template functions 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#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-08-02</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="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3>
+<p><b>Section:</b> 20.6.12.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-04-23</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a></p>
 <p><b>Discussion:</b></p>
 <p>
-There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in
-terms of their value_type, and the requirements in 23.1.2 appear to be overly strict
-(requires InputIterator::value_type be the same type as the container's value_type).
+[tr.util.smartptr.shared.dest] says in its second bullet:
 </p>
 
+<p>
+"If *this shares ownership with another shared_ptr instance (use_count() &gt; 1),
+decrements that instance's use count."
+</p>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 23.1.1 p3:
+The problem with this formulation is that it presupposes the existence of an
+"use count" variable that can be decremented and that is part of the state of a
+shared_ptr instance (because of the "that instance's use count".)
 </p>
 
-<blockquote><p>
-In Tables 82 and 83, <tt>X</tt> denotes a sequence class, <tt>a</tt> denotes a
-value of <tt>X</tt>, <tt>i</tt> and <tt>j</tt> denote iterators satisfying input
-iterator requirements <ins>and refer to elements <ins>implicitly
-convertible to</ins> <tt>value_type</tt></ins>, <tt>[i, j)</tt> denotes a valid
-range, <tt>n</tt> denotes a value of <tt>X::size_type</tt>, <tt>p</tt> denotes a
-valid iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable
-iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range in <tt>a</tt>,
-and <tt>t</tt> denotes a value of <tt>X::value_type</tt>.
-</p></blockquote>
-
 <p>
-Change 23.1.2 p7:
+This is contrary to the spirit of the rest of the specification that carefully
+avoids to require an use count variable. Instead, use_count() is specified to
+return a value, a number of instances.
 </p>
 
-<blockquote><p>
-In Table 84, <tt>X</tt> is an associative container class, <tt>a</tt> is a value
-of <tt>X</tt>, <tt>a_uniq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
-unique keys, and <tt>a_eq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
-multiple keys, <tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and
-refer to elements <del>of</del> <ins>implicitly convertible to</ins>
-<tt>value_type</tt>, <tt>[i, j)</tt> is a valid range, <tt>p</tt> is a valid
-iterator to <tt>a</tt>, <tt>q</tt> is a valid dereferenceable iterator to
-<tt>a</tt>, <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <tt>t</tt> is a
-value of <tt>X::value_type</tt>, <tt>k</tt> is a value of <tt>X::key_type</tt>
-and <tt>c</tt> is a value of type <tt>X::key_compare</tt>.
-</p></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
 <p>
-Concepts will probably come in and rewrite this section anyway.  But just in case it is
-easy to fix this up as a safety net and as a clear statement of intent.
+In multithreaded code, the usual implicit assumption is that a shared variable
+should not be accessed by more than one thread without explicit synchronization,
+and by introducing the concept of an "use count" variable, the current wording
+implies that two shared_ptr instances that share ownership cannot be destroyed
+simultaneously.
 </p>
 
-
-
-
-
-<hr>
-<h3><a name="593"></a>593. __STDC_CONSTANT_MACROS</h3>
-<p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2006-08-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
-&lt;cstdint&gt; and &lt;stdint.h&gt;.  These are of course based on the C99 header
-&lt;stdint.h&gt;, and were part of TR1.
+In addition, if we allow the interpretation that an use count variable is part
+of shared_ptr's state, this would lead to other undesirable consequences WRT
+multiple threads. For example,
 </p>
 
+<blockquote><pre>p1 = p2;
+</pre></blockquote>
+
 <p>
-Per 18.3.1/1, these headers define a number of macros and function macros. 
-While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99
-footnotes do mention __STDC_CONSTANT_MACROS.  Further, 18.3.1/2 states that "The
-header defines all ... macros the same as C99 subclause 7.18."
+would now visibly modify the state of p2, a "write" operation, requiring a lock.
 </p>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Therefore, if I wish to have the above-referenced macros and function macros
-defined, must I #define __STDC_CONSTANT_MACROS before I #include &lt;cstdint&gt;, or
-does the C++ header define these macros/function macros unconditionally?
+Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to:
 </p>
 
+<blockquote>
+<ul>
+<li>If <tt>*this</tt> is <i>empty</i> <ins>or shares ownership with another
+<tt>shared_ptr</tt> instance (<tt>use_count() &gt; 1</tt>)</ins>, there are no side effects.</li>
+<li><del>If <tt>*this</tt> <i>shares ownership</i> with another <tt>shared_ptr</tt> instance
+(<tt>use_count() &gt; 1</tt>), decrements that instance's use count.</del></li>
+</ul>
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-To put this issue to rest for C++0X, I propose the following addition to 
-18.3.1/2 of the Working Paper N2009:
+Add the following paragraph after [lib.util.smartptr.shared.dest]/1:
 </p>
 
 <blockquote><p>
-[Note: The macros defined by &lt;cstdint&gt; are provided unconditionally: in
-particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
-(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note]
+[<i>Note:</i> since the destruction of <tt>*this</tt> decreases the number of instances in
+<tt>*this</tt>'s ownership group by one, all <tt>shared_ptr</tt> instances that share ownership
+with <tt>*this</tt> will report an <tt>use_count()</tt> that is one lower than its previous value
+after <tt>*this</tt> is destroyed. <i>--end note</i>]
 </p></blockquote>
 
 
@@ -22245,78 +22454,52 @@ particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
 
 
 <hr>
-<h3><a name="598"></a>598. Decimal: Conversion to integral should truncate, not round.</h3>
-<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<h3><a name="576"></a>576. find_first_of is overconstrained</h3>
+<p><b>Section:</b> 25.1.4 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Doug Gregor <b>Date:</b> 2006-04-25</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-
-<p>
-In a private email, Daniel writes:
-</p>
-<blockquote>
 <p>
-I would like to 
-ask, what where the reason for the decision to 
-define the semantics of the integral conversion of the decimal types, namely
+In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
+find_first_of are specified to require Forward Iterators, as follows:
 </p>
-<pre>"operator long long() const;
 
-     Returns: Returns the result of the 
-conversion of *this to the type long long, as if 
-performed by the expression llrounddXX(*this)."
-</pre>
-<p>
-where XX stands for either 32, 64, or 128, 
-corresponding to the proper decimal type. The 
-exact meaning of llrounddXX is not given in that 
-paper, so I compared it to the corresponding 
-definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
-</p>
-<p>
-"The lround and llround functions round their 
-argument to the nearest integer value,
-rounding halfway cases away from zero, regardless 
-of the current rounding direction. [..]"
-</p>
-<p>
-Now considering the fact that integral conversion 
-of the usual floating-point types ("4.9 
-Floating-integral conversions") has truncation 
-semantic I wonder why this conversion behaviour 
-has not been transferred for the decimal types. 
-</p>
-</blockquote>
-<p>
-Robert comments:
-</p>
+<blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
+  ForwardIterator1
+  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
+                        ForwardIterator2 first2, ForwardIterator2 last2);
+template&lt;class ForwardIterator1, class ForwardIterator2,
+                  class BinaryPredicate&gt;
+ForwardIterator1
+  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
+                         ForwardIterator2 first2, ForwardIterator2 last2,
+                        BinaryPredicate pred);
+</pre></blockquote>
+
 <p>
-Also, there is a further error in the <b>Returns:</b> clause for converting <code>decimal::decimal128</code> to <code>long long</code>.  It currently calls <code>llroundd64</code>, not <code>llroundd128</code>.
+However, ForwardIterator1 need not actually be a Forward Iterator; an Input
+Iterator suffices, because we do not need the multi-pass property of the Forward
+Iterator or a true reference.
 </p>
 
 
-
 <p><b>Proposed resolution:</b></p>
 <p>
-Change the <b>Returns:</b> clause in 3.2.2.4 to:
-</p>
-<blockquote><p>
-<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd32(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
-</p></blockquote>
-<p>
-Change the <b>Returns:</b> clause in 3.2.3.4 to:
-</p>
-<blockquote><p>
-<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
-</p></blockquote>
-<p>
-Change the <b>Returns:</b> clause in 3.2.4.4 to:
+Change the declarations of <tt>find_first_of</tt> to:
 </p>
-<blockquote><p>
-<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
-</p></blockquote>
+
+<blockquote><pre>template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2&gt;
+  <del>ForwardIterator1</del><ins>InputIterator1</ins>
+  find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
+                        ForwardIterator2 first2, ForwardIterator2 last2);
+template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2,
+                  class BinaryPredicate&gt;
+<del>ForwardIterator1</del><ins>InputIterator1</ins>
+  find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
+                         ForwardIterator2 first2, ForwardIterator2 last2,
+                        BinaryPredicate pred);
+</pre></blockquote>
 
 
 
@@ -22324,402 +22507,2078 @@ Change the <b>Returns:</b> clause in 3.2.4.4 to:
 
 
 <hr>
-<h3><a name="599"></a>599. Decimal: Say "octets" instead of "bytes."</h3>
-<p><b>Section:</b> TRDecimal 3.1 [trdec.types.encodings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<h3><a name="577"></a>577. upper_bound(first, last, ...) cannot return last</h3>
+<p><b>Section:</b> 25.3.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-05-03</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Daniel writes in a private email:
+ISO/IEC 14882:2003 says:
 </p>
 
 <blockquote>
 <p>
-- 3.1 'Decimal type encodings' says in its note:
+25.3.3.2 upper_bound
 </p>
-<pre>"this implies that 
-sizeof(std::decimal::decimal32) == 4, 
-sizeof(std::decimal::decimal64) == 8, and 
-sizeof(std::decimal::decimal128) == 16."
-</pre>
 <p>
-This is a wrong assertion, because the definition 
-of 'byte' in 1.7 'The C+ + memory model' of ISO 
-14882 (2nd edition) does not specify that a byte 
-must be necessarily 8 bits large, which would be 
-necessary to compare with the specified bit sizes 
-of the types decimal32, decimal64, and decimal128.
+<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
+<tt>[<i>first</i>, <i>last</i>)</tt> such that
+for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
+conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
 </p>
 </blockquote>
 
-
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 3.1 as follows:
+From the description above, upper_bound cannot return last, since it's
+not in the interval [first, last). This seems to be a typo, because if
+value is greater than or equal to any other values in the range, or if
+the range is empty, returning last seems to be the intended behaviour.
+The corresponding interval for lower_bound is also [first, last].
 </p>
-<blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
+Change [lib.upper.bound]:
 </p>
-<ul>
-<li>
-decimal32 is a <em>decimal32</em> number, which is encoded in four consecutive <del>bytes</del> <ins>octets</ins> (32 bits)
-</li>
-<li>
-decimal64 is a <em>decimal64</em> number, which is encoded in eight consecutive <del>bytes</del> <ins>octets</ins> (64 bits)
 
-</li>
-<li>
-decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive <del>bytes</del> <ins>octets</ins> (128 bits)
-</li>
-</ul>
+<blockquote>
 <p>
-<del>[<i>Note:</i> this implies that <code>sizeof(std::decimal::decimal32) == 4</code>, <code>sizeof(std::decimal::decimal64) == 8</code>, and <code>sizeof(std::decimal::decimal128) == 16</code>.  <i>--end note</i>]</del>
+<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
+<tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that
+for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
+conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
 </p>
 </blockquote>
 
 
 
 
+
+
 <hr>
-<h3><a name="600"></a>600. Decimal: Wrong parameters for wcstod* functions</h3>
-<p><b>Section:</b> TRDecimal 3.9 [trdec.types.cwchar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3>
+<p><b>Section:</b> 20.6.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-17</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-Daniel writes:
-</p>
-<blockquote><p>
-- 3.9.1 'Additions to &lt;cwchar&gt;' provides wrong 
-signatures to the wcstod32, wcstod64, and 
-wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
-</p></blockquote>
+        <p>
+
+The     description    of     the     allocator    member     function
+<code>allocate()</code>  requires  that  the <i>hint</i>  argument  be
+either 0 or a  value previously returned from <code>allocate()</code>.
+Footnote 227 further suggests that  containers may pass the address of
+an adjacent element as this argument.
+
+        </p>
+        <p>
+
+I  believe  that  either  the  footnote  is  wrong  or  the  normative
+requirement that  the argument be  a value previously returned  from a
+call to  <code>allocate()</code> is wrong. The latter  is supported by
+the resolution  to issue 20-004 proposed in  c++std-lib-3736 by Nathan
+Myers. In addition,  the <i>hint</i> is an ordinary  void* and not the
+<code>pointer</code>  type returned  by  <code>allocate()</code>, with
+the  two  types potentially  being  incompatible  and the  requirement
+impossible to satisfy.
+
+        </p>
+        <p>
+
+See also c++std-lib-14323 for some  more context on where this came up
+(again).
+
+        </p>
+    
+
+    <p><b>Proposed resolution:</b></p>
+        <p>
+
+Remove  the requirement  in  20.6.1.1, p4  that  the hint  be a  value
+previously returned from <code>allocate()</code>. Specifically, change
+the paragraph as follows:
+
+        </p>
+<p>
+<del><i>Requires</i>: <i>hint</i> either 0 or previously obtained  from  member
+<code>allocate</code>  and  not  yet passed  to member  <code>deallocate</code>.
+The value hint may be used by an implementation to help improve performance
+<sup>223)</sup>.</del> <ins>[<i>Note:</i> The value <i>hint</i> may be used by an
+implementation to help improve performance. -- <i>end note</i>]</ins>
+</p>
+<blockquote><p>
+<del>[Footnote: <sup>223)</sup>In a container member function, the address of an
+adjacent element is often a good choice to pass for this argument.</del>
+</p></blockquote>
+    
+
+
+
+<hr>
+<h3><a name="581"></a>581. <code>flush()</code> not unformatted function</h3>
+<p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+        <p>
+
+The resolution of issue 60 changed <code>basic_ostream::flush()</code>
+so as not  to require it to behave as  an unformatted output function.
+That has at least two in my opinion problematic consequences:
+
+        </p>
+        <p>
+
+First, <code>flush()</code>  now calls <code>rdbuf()-&gt;pubsync()</code>
+unconditionally, without  regard to the  state of the stream.  I can't
+think of any reason why <code>flush()</code> should behave differently
+from the vast majority of stream functions in this respect.
+
+        </p>
+        <p>
+
+Second, <code>flush()</code> is not  required to catch exceptions from
+<code>pubsync()</code> or set  <code>badbit</code> in response to such
+events. That doesn't seem right either, as most other stream functions
+do so.
+
+        </p>
+    
+
+    <p><b>Proposed resolution:</b></p>
+        <p>
+
+I  propose  to revert  the  resolution of  issue  60  with respect  to
+<code>flush()</code>. Specifically,  I propose to  change 27.6.2.6, p7
+as follows:
+
+        </p>
+
+<p>
+Effects: <ins>Behaves as an  unformatted output function (as described
+in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null
+pointer,  <ins>constructs a  sentry  object.  If  this object  returns
+<code>true</code> when converted to a  value of type bool the function
+</ins>calls <code>rdbuf()-&gt;pubsync()</code>.  If that function returns
+-1    calls    <code>setstate(badbit)</code>    (which    may    throw
+<code>ios_base::failure</code>  (27.4.4.3)).   <ins>Otherwise, if  the
+sentry object returns <code>false</code>, does nothing.</ins><del>Does
+not  behave  as  an  unformatted  output  function  (as  described  in
+27.6.2.6, paragraph 1).</del>
+</p>
+
+    
+
+<p><i>[
+Kona (2007): Proposed Disposition: Ready
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="586"></a>586. string inserter not a formatted function</h3>
+<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+        <p>
+
+Section  and paragraph  numbers  in  this paper  are  relative to  the
+working draft document number N2009 from 4/21/2006.
+
+        </p>
+
+        <p>
+
+The  <code>basic_string</code> extractor  in 21.3.7.9,  p1  is clearly
+required  to  behave  as  a   formatted  input  function,  as  is  the
+<code>std::getline()</code> overload for string described in p7.
+
+        </p>
+        <p>
+
+However, the <code>basic_string</code> inserter described in p5 of the
+same section has no such requirement. This has implications on how the
+operator  responds  to  exceptions thrown  from  <code>xsputn()</code>
+(formatted  output functions are  required to  set <code>badbit</code>
+and swallow  the exception unless  <code>badbit</code> is also  set in
+<code>exceptions()</code>; the  string inserter doesn't  have any such
+requirement).
+
+        </p>
+        <p>
+
+I don't  see anything in the  spec for the string  inserter that would
+justify requiring  it to treat  exceptions differently from  all other
+similar operators. (If it did, I think it should be made this explicit
+by saying  that the  operator "does not  behave as a  formatted output
+function" as has been made customary by the adoption of the resolution
+of issue 60).
+
+        </p>
+    
+
+    <p><b>Proposed resolution:</b></p>
+        <p>
+
+I propose to change the Effects clause in 21.3.7.9, p5, as follows:
+
+        </p>
+            <blockquote>
+        <p>
+
+<i>Effects</i>: <del>Begins by constructing a  sentry object k as if k
+were    constructed    by    typename    <code>basic_ostream&lt;charT,
+traits&gt;::sentry   k   (os)</code>.    If  <code>bool(k)</code>   is
+<code>true</code>, </del><ins>Behaves  as a formatted  output function
+(27.6.2.5.1).   After constructing  a  <code>sentry</code> object,  if
+this  object returns <code>true</code>  when converted  to a  value of
+type   <code>bool</code>,   determines   padding   as   described   in
+22.2.2.2.2</ins>,  then inserts the  resulting sequence  of characters
+<code><i>seq</i></code> as if by calling <code>os.rdbuf()-&gt;sputn(seq ,
+n)</code>,    where   <code><i>n</i></code>    is   the    larger   of
+<code>os.width()</code>   and   <code>str.size()</code>;  then   calls
+<code>os.width(0)</code>.  <del>If  the  call  to sputn  fails,  calls
+<code>os.setstate(ios_base::failbit)</code>.</del>
+
+        </p>
+            </blockquote>
+        <p>
+
+This proposed  resilution assumes the  resolution of issue  394 (i.e.,
+that   all   formatted   output   functions  are   required   to   set
+<code>ios_base::badbit</code>  in response  to any  kind  of streambuf
+failure),   and   implicitly   assumes   that  a   return   value   of
+<code>sputn(seq,  <i>n</i>)</code>  other  than  <code><i>n</i></code>
+indicates a failure.
+
+        </p>
+    
+
+
+
+<hr>
+<h3><a name="589"></a>589. Requirements on iterators of member template functions 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#WP">WP</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-08-02</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a></p>
+<p><b>Discussion:</b></p>
+<p>
+There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in
+terms of their value_type, and the requirements in 23.1.2 appear to be overly strict
+(requires InputIterator::value_type be the same type as the container's value_type).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 23.1.1 p3:
+</p>
+
+<blockquote><p>
+In Tables 82 and 83, <tt>X</tt> denotes a sequence class, <tt>a</tt> denotes a
+value of <tt>X</tt>, <tt>i</tt> and <tt>j</tt> denote iterators satisfying input
+iterator requirements <ins>and refer to elements <ins>implicitly
+convertible to</ins> <tt>value_type</tt></ins>, <tt>[i, j)</tt> denotes a valid
+range, <tt>n</tt> denotes a value of <tt>X::size_type</tt>, <tt>p</tt> denotes a
+valid iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable
+iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range in <tt>a</tt>,
+and <tt>t</tt> denotes a value of <tt>X::value_type</tt>.
+</p></blockquote>
+
+<p>
+Change 23.1.2 p7:
+</p>
+
+<blockquote><p>
+In Table 84, <tt>X</tt> is an associative container class, <tt>a</tt> is a value
+of <tt>X</tt>, <tt>a_uniq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
+unique keys, and <tt>a_eq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
+multiple keys, <tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and
+refer to elements <del>of</del> <ins>implicitly convertible to</ins>
+<tt>value_type</tt>, <tt>[i, j)</tt> is a valid range, <tt>p</tt> is a valid
+iterator to <tt>a</tt>, <tt>q</tt> is a valid dereferenceable iterator to
+<tt>a</tt>, <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <tt>t</tt> is a
+value of <tt>X::value_type</tt>, <tt>k</tt> is a value of <tt>X::key_type</tt>
+and <tt>c</tt> is a value of type <tt>X::key_compare</tt>.
+</p></blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+Concepts will probably come in and rewrite this section anyway.  But just in case it is
+easy to fix this up as a safety net and as a clear statement of intent.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="593"></a>593. __STDC_CONSTANT_MACROS</h3>
+<p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Walter Brown <b>Date:</b> 2006-08-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
+&lt;cstdint&gt; and &lt;stdint.h&gt;.  These are of course based on the C99 header
+&lt;stdint.h&gt;, and were part of TR1.
+</p>
+
+<p>
+Per 18.3.1/1, these headers define a number of macros and function macros. 
+While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99
+footnotes do mention __STDC_CONSTANT_MACROS.  Further, 18.3.1/2 states that "The
+header defines all ... macros the same as C99 subclause 7.18."
+</p>
+
+<p>
+Therefore, if I wish to have the above-referenced macros and function macros
+defined, must I #define __STDC_CONSTANT_MACROS before I #include &lt;cstdint&gt;, or
+does the C++ header define these macros/function macros unconditionally?
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+To put this issue to rest for C++0X, I propose the following addition to 
+18.3.1/2 of the Working Paper N2009:
+</p>
+
+<blockquote><p>
+[Note: The macros defined by &lt;cstdint&gt; are provided unconditionally: in
+particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
+(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note]
+</p></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="598"></a>598. Decimal: Conversion to integral should truncate, not round.</h3>
+<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+In a private email, Daniel writes:
+</p>
+<blockquote>
+<p>
+I would like to 
+ask, what where the reason for the decision to 
+define the semantics of the integral conversion of the decimal types, namely
+</p>
+<pre>"operator long long() const;
+
+     Returns: Returns the result of the 
+conversion of *this to the type long long, as if 
+performed by the expression llrounddXX(*this)."
+</pre>
+<p>
+where XX stands for either 32, 64, or 128, 
+corresponding to the proper decimal type. The 
+exact meaning of llrounddXX is not given in that 
+paper, so I compared it to the corresponding 
+definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
+</p>
+<p>
+"The lround and llround functions round their 
+argument to the nearest integer value,
+rounding halfway cases away from zero, regardless 
+of the current rounding direction. [..]"
+</p>
+<p>
+Now considering the fact that integral conversion 
+of the usual floating-point types ("4.9 
+Floating-integral conversions") has truncation 
+semantic I wonder why this conversion behaviour 
+has not been transferred for the decimal types. 
+</p>
+</blockquote>
+<p>
+Robert comments:
+</p>
+<p>
+Also, there is a further error in the <b>Returns:</b> clause for converting <code>decimal::decimal128</code> to <code>long long</code>.  It currently calls <code>llroundd64</code>, not <code>llroundd128</code>.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the <b>Returns:</b> clause in 3.2.2.4 to:
+</p>
+<blockquote><p>
+<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd32(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
+</p></blockquote>
+<p>
+Change the <b>Returns:</b> clause in 3.2.3.4 to:
+</p>
+<blockquote><p>
+<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
+</p></blockquote>
+<p>
+Change the <b>Returns:</b> clause in 3.2.4.4 to:
+</p>
+<blockquote><p>
+<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
+</p></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="599"></a>599. Decimal: Say "octets" instead of "bytes."</h3>
+<p><b>Section:</b> TRDecimal 3.1 [trdec.types.encodings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Daniel writes in a private email:
+</p>
+
+<blockquote>
+<p>
+- 3.1 'Decimal type encodings' says in its note:
+</p>
+<pre>"this implies that 
+sizeof(std::decimal::decimal32) == 4, 
+sizeof(std::decimal::decimal64) == 8, and 
+sizeof(std::decimal::decimal128) == 16."
+</pre>
+<p>
+This is a wrong assertion, because the definition 
+of 'byte' in 1.7 'The C+ + memory model' of ISO 
+14882 (2nd edition) does not specify that a byte 
+must be necessarily 8 bits large, which would be 
+necessary to compare with the specified bit sizes 
+of the types decimal32, decimal64, and decimal128.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 3.1 as follows:
+</p>
+<blockquote>
+<p>
+The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
+</p>
+<ul>
+<li>
+decimal32 is a <em>decimal32</em> number, which is encoded in four consecutive <del>bytes</del> <ins>octets</ins> (32 bits)
+</li>
+<li>
+decimal64 is a <em>decimal64</em> number, which is encoded in eight consecutive <del>bytes</del> <ins>octets</ins> (64 bits)
+
+</li>
+<li>
+decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive <del>bytes</del> <ins>octets</ins> (128 bits)
+</li>
+</ul>
+<p>
+<del>[<i>Note:</i> this implies that <code>sizeof(std::decimal::decimal32) == 4</code>, <code>sizeof(std::decimal::decimal64) == 8</code>, and <code>sizeof(std::decimal::decimal128) == 16</code>.  <i>--end note</i>]</del>
+</p>
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="600"></a>600. Decimal: Wrong parameters for wcstod* functions</h3>
+<p><b>Section:</b> TRDecimal 3.9 [trdec.types.cwchar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Daniel writes:
+</p>
+<blockquote><p>
+- 3.9.1 'Additions to &lt;cwchar&gt;' provides wrong 
+signatures to the wcstod32, wcstod64, and 
+wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
+</p></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change "3.9.1 Additions to <code>&lt;cwchar&gt;</code> synopsis" to:
+</p>
+<pre>       namespace std {
+       namespace decimal {
+         // 3.9.2 wcstod functions:
+         decimal32  wcstod32  (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
+         decimal64  wcstod64  (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
+         decimal128 wcstod128 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
+       }
+       }
+</pre>
+
+
+
+
+<hr>
+<h3><a name="601"></a>601. Decimal: numeric_limits typos</h3>
+<p><b>Section:</b> TRDecimal 3.3 [trdec.types.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Daniel writes in a private email:
+</p>
+
+<blockquote>
+<p>
+- 3.3 'Additions to header &lt;limits&gt;' contains two 
+errors in the specialisation of numeric_limits&lt;decimal::decimal128&gt;:
+</p>
+<ol>
+<li>The static member max() returns DEC128_MIN, this should be DEC128_MAX.</li>
+<li>The static member digits is assigned to 384,
+this should be 34 (Probably mixed up with the
+max. exponent for decimal::decimal64).</li>
+</ol>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In "3.3 Additions to header <code>&lt;limits&gt;</code>" change numeric_limits&lt;decimal::decimal128&gt; as follows:
+</p>
+<pre>        template&lt;&gt; class numeric_limits&lt;decimal::decimal128&gt; {
+          public:
+            static const bool is_specialized = true;
+
+            static decimal::decimal128 min() throw() { return DEC128_MIN; }
+            static decimal::decimal128 max() throw() { return <del>DEC128_MIN;</del> <ins>DEC128_MAX;</ins> }
+
+            static const int digits       = <del>384</del> <ins>34</ins>;
+            /* ... */
+</pre>
+
+
+
+
+<hr>
+<h3><a name="602"></a>602. Decimal: "generic floating type" not defined.</h3>
+<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The document uses the term "generic floating types," but defines it nowhere.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the first paragraph of "3 Decimal floating-point types" as follows:
+</p>
+<blockquote><p>
+This Technical Report introduces three decimal floating-point types, named
+decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
+subset of the set of values of type decimal64; the set of values of the type
+decimal64 is a subset of the set of values of the type decimal128. Support for
+decimal128 is optional.  <ins>These types supplement the Standard C++ types
+<code>float</code>, <code>double</code>, and <code>long double</code>, which are
+collectively described as the <i>basic floating types</i></ins>.
+</p></blockquote>
+
+
+
+
+<hr>
+<h3><a name="603"></a>603. Decimal: Trivially simplifying decimal classes.</h3>
+<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>In c++std-lib-17198, Martin writes:</p>
+
+<blockquote><p>
+Each of the three classes proposed in the paper (decimal32, decimal64,
+and decimal128) explicitly declares and specifies the semantics of its
+copy constructor, copy assignment operator, and destructor. Since the
+semantics of all three functions are identical to the trivial versions
+implicitly generated by the compiler in the absence of any declarations
+it is safe to drop them from the spec. This change would make the
+proposed classes consistent with other similar classes already in the
+standard (e.g., std::complex).
+</p></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change "3.2.2 Class <code>decimal32</code>" as follows:
+</p>
+<pre>      namespace std {
+      namespace decimal {
+        class decimal32 {
+          public:
+            // 3.2.2.1 construct/copy/destroy:
+            decimal32();
+            <del>decimal32(const decimal32 &amp; d32);</del>
+            <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
+            <del>~decimal32();</del>
+            /* ... */
+</pre>
+<p>
+Change "3.2.2.1 construct/copy/destroy" as follows:
+</p>
+<pre>        decimal32();
+
+    Effects: Constructs an object of type decimal32 with the value 0;
+
+        <del>decimal32(const decimal32 &amp; d32);</del>
+        <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
+
+    <del>Effects: Copies an object of type decimal32.</del>
+
+        <del>~decimal32();</del>
+
+    <del>Effects: Destroys an object of type decimal32.</del>
+
+</pre>
+<p>
+Change "3.2.3 Class <code>decimal64</code>" as follows:
+</p>
+<pre>      namespace std {
+      namespace decimal {
+        class decimal64 {
+          public:
+            // 3.2.3.1 construct/copy/destroy:
+            decimal64();
+            <del>decimal64(const decimal64 &amp; d64);</del>
+            <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
+            <del>~decimal64();</del>
+            /* ... */
+</pre>
+<p>
+Change "3.2.3.1 construct/copy/destroy" as follows:
+</p>
+<pre>        decimal64();
+
+    Effects: Constructs an object of type decimal64 with the value 0;
+
+        <del>decimal64(const decimal64 &amp; d64);</del>
+        <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
+
+    <del>Effects: Copies an object of type decimal64.</del>
+
+        <del>~decimal64();</del>
+
+    <del>Effects: Destroys an object of type decimal64.</del>
+
+</pre>
+<p>
+Change "3.2.4 Class <code>decimal128</code>" as follows:
+</p>
+<pre>      namespace std {
+      namespace decimal {
+        class decimal128 {
+          public:
+            // 3.2.4.1 construct/copy/destroy:
+            decimal128();
+            <del>decimal128(const decimal128 &amp; d128);</del>
+            <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
+            <del>~decimal128();</del>
+            /* ... */
+</pre>
+<p>
+Change "3.2.4.1 construct/copy/destroy" as follows:
+</p>
+<pre>        decimal128();
+
+    Effects: Constructs an object of type decimal128 with the value 0;
+
+        <del>decimal128(const decimal128 &amp; d128);</del>
+        <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
+
+    <del>Effects: Copies an object of type decimal128.</del>
+
+        <del>~decimal128();</del>
+
+    <del>Effects: Destroys an object of type decimal128.</del>
+
+</pre>
+
+
+
+
+<hr>
+<h3><a name="604"></a>604. Decimal: Storing a reference to a facet unsafe.</h3>
+<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In c++std-lib-17197, Martin writes:
+</p>
+<blockquote><p>
+The extended_num_get and extended_num_put facets are designed
+to store a reference to a num_get or num_put facet which the
+extended facets delegate the parsing and formatting of types
+other than decimal. One form of the extended facet's ctor (the
+default ctor and the size_t overload) obtains the reference
+from the global C++ locale while the other form takes this
+reference as an argument.
+</p></blockquote>
+<blockquote><p>
+The problem with storing a reference to a facet in another
+object (as opposed to storing the locale object in which the
+facet is installed) is that doing so bypasses the reference
+counting mechanism designed to prevent a facet that is still
+being referenced (i.e., one that is still installed in some
+locale) from being destroyed when another locale that contains
+it is destroyed. Separating a facet reference from the locale
+it comes from van make it cumbersome (and in some cases might
+even make it impossible) for programs to prevent invalidating
+the reference. (The danger of this design is highlighted in
+the paper.)
+</p></blockquote>
+<blockquote><p>
+This problem could be easily avoided by having the extended
+facets store a copy of the locale from which they would extract
+the base facet either at construction time or when needed. To
+make it possible, the forms of ctors of the extended facets that
+take a reference to the base facet would need to be changed to
+take a locale argument instead.
+</p></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+1. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows:
+</p>
+<pre>            extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
+
+            /* ... */
+
+            <del>// <i>const std::num_get&lt;charT, InputIterator&gt; &amp; <b>base</b></i>;        <i><b>exposition only</b></i></del>
+            <ins>// <i>std::locale <b>baseloc</b></i>;                                    <i><b>exposition only</b></i></ins>
+</pre>
+<p>
+2. Change the description of the above constructor in 3.10.2.1:
+</p>
+<pre>            extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
+
+</pre>
+<blockquote>
+<p>
+<b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by:
+</p>
+<pre>       extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
+                : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
+                { /* ... */ }
+
+</pre>
+<p>
+<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_get</code> facet.</del>
+</p>
+</blockquote>
+<p>
+3. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &amp;, ios_base::iostate &amp;, bool &amp;) const</code>, <i>et al</i> to
+</p>
+<blockquote><p>
+<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_get&lt;charT, InputIterator&gt; &gt;(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>. 
+</p></blockquote>
+<p>
+4. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows:
+</p>
+<pre>            extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
+
+            /* ... */
+
+            <del>// <i>const std::num_put&lt;charT, OutputIterator&gt; &amp; <b>base</b></i>;       <i><b>exposition only</b></i></del>
+            <ins>// <i>std::locale <b>baseloc</b></i>;                                    <i><b>exposition only</b></i></ins>
+</pre>
+<p>
+5. Change the description of the above constructor in 3.10.3.1:
+</p>
+<pre>            extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
+</pre>
+<blockquote>
+<p>
+<b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by:
+</p>
+<pre>       extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
+                : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
+                { /* ... */ }
+
+</pre>
+<p>
+<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_put</code> facet.</del>
+</p>
+</blockquote>
+<p>
+6. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &amp;, char_type, bool &amp;) const</code>, <i>et al</i> to
+</p>
+<blockquote><p>
+<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_put&lt;charT, OutputIterator&gt; &gt;(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>. 
+</p></blockquote>
+
+<p><i>[
+Redmond:  We would prefer to rename "extended" to "decimal".
+]</i></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="605"></a>605. Decimal: &lt;decfloat.h&gt; doesn't live here anymore.</h3>
+<p><b>Section:</b> TRDecimal 3.4 [trdec.types.cdecfloat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Robert Klarer <b>Date:</b> 2006-10-17</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In Berlin, WG14 decided to drop the &lt;decfloat.h&gt; header. The
+contents of that header have been moved into &lt;float.h&gt;. For the
+sake of C compatibility, we should make corresponding changes.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+1. Change the heading of subclause 3.4, "Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code>" to "Additions to headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code>."
+</p>
+<p>
+2. Change the text of subclause 3.4 as follows:
+</p>
+<blockquote>
+<p>
+<del>The standard C++ headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>.  Their contents remain unchanged by this Technical Report.</del>
+</p>
+<p>
+<del>Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;decfloat.h&gt;</code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
+</p>
+<p>
+<ins>The header <code>&lt;cfloat&gt;</code> is described in [tr.c99.cfloat].  The header <code>&lt;float.h&gt;</code>
+is described in [tr.c99.floath]. These headers are extended by this
+Technical Report to define characteristics of the decimal
+floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;float.h&gt;</code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins>
+</p>
+</blockquote>
+<p>
+3. Change the heading of subclause 3.4.1, "Header <code>&lt;cdecfloat&gt;</code> synopsis"  to "Additions to header <code>&lt;cfloat&gt;</code> synopsis."
+</p>
+<p>
+4. Change the heading of subclause 3.4.2, "Header <code>&lt;decfloat.h&gt;</code> synopsis" to "Additions to header <code>&lt;float.h&gt;</code> synopsis."
+</p>
+<p>
+5. Change the contents of 3.4.2 as follows:
+</p>
+<pre>      <del>#include &lt;cdecfloat&gt;</del>
+
+      // <i>C-compatibility convenience typedefs:</i>
+
+      typedef std::decimal::decimal32  _Decimal32;
+      typedef std::decimal::decimal64  _Decimal64;
+      typedef std::decimal::decimal128 _Decimal128;
+</pre>
+
+
+
+
+
+<hr>
+<h3><a name="607"></a>607. Concern about short seed vectors</h3>
+<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Short seed vectors of 32-bit quantities all result in different states. However
+this is not true of seed vectors of 16-bit (or smaller) quantities.  For example
+these two seeds
+</p>
+
+<blockquote><pre>unsigned short seed = {1, 2, 3};
+unsigned short seed = {1, 2, 3, 0};
+</pre></blockquote>
+
+<p>
+both pack to
+</p>
+
+<blockquote><pre>unsigned seed = {0x20001, 0x3};
+</pre></blockquote>
+
+<p>
+yielding the same state.
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="608"></a>608. Unclear seed_seq construction details</h3>
+<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
+treatment of signed quantities is unclear. Better to spell it out.
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="609"></a>609. missing static const</h3>
+<p><b>Section:</b> 26.4.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Walter E. Brown <b>Date:</b> 2006-11-02</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In preparing N2111, an error on my part resulted in the omission of the
+following line from the template synopsis in the cited section:
+</p>
+
+<blockquote><pre>static const size_t word_size = w;
+</pre></blockquote>
+
+<p>
+(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
+</p>
+
+<blockquote><pre>// engine characteristics
+<ins>static const size_t word_size = w;</ins>
+</pre></blockquote>
+
+<p>
+and accept my apologies for the oversight.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="610"></a>610. Suggested non-normative note for C++0x</h3>
+<p><b>Section:</b> 20.5.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Scott Meyers <b>Date:</b> 2006-11-02</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+My suggestion is that implementers of both tr1::function and its 
+official C++0x successor be explicitly encouraged (but not required) to 
+optimize for the cases mentioned above, i.e., function pointers and 
+small function objects.  They could do this by using a small internal 
+buffer akin to the buffer used by implementations of the small string 
+optimization.  (That would make this the small functor optimization -- 
+SFO :-})  The form of this encouragement could be a note in the standard 
+akin to footnote 214 of the current standard.
+</p>
+
+<p>
+Dave Abrahams notes:
+</p>
+
+<p>
+"shall not throw exceptions" should really be "nothing," both to be more
+grammatical and to be consistent with existing wording in the standard.
+</p>
+
+<p>
+Doug Gregor comments: I think this is a good idea. Currently, implementations of
+tr1::function are required to have non-throwing constructors and assignment
+operators when the target function object is a function pointer or a
+reference_wrapper. The common case, however, is for a tr1::function to store
+either an empty function object or a member pointer + an object pointer.
+</p>
+<p>
+The function implementation in the upcoming Boost 1.34.0 uses the
+"SFO", so that the function objects for typical bind expressions like
+</p>
+<blockquote><pre>bind(&amp;X::f, this, _1, _2, _3)
+</pre></blockquote>
+
+<p>
+do not require heap allocation when stored in a boost::function. I
+believe Dinkumware's implementation also performs this optimization.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
+</p>
+
+<blockquote>
+<p>
+<i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a function
+pointer or a function object passed via <tt>reference_wrapper</tt>. Otherwise,
+may throw <tt>bad_alloc</tt> or any exception thrown by the copy constructor of
+the stored function object.
+</p>
+<p>
+<ins><i>Note:</i> Implementations are encouraged to avoid the use of dynamically
+allocated memory for "small" function objects, e.g., where <tt>f</tt>'s target
+is an object holding only a pointer or reference to an object and a member
+function pointer (a "bound member function").</ins>
+</p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="611"></a>611. Standard library templates and incomplete types</h3>
+<p><b>Section:</b> 17.4.3.7 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Nicola Musatti <b>Date:</b> 2006-11-13</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In the latest available draft standard 
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
+§ 17.4.3.6 [res.on.functions] states:
+</p>
+
+<blockquote>
+<p>
+-1- In certain cases (replacement functions, handler functions, operations on
+types used to instantiate standard library template components), the C++
+Standard Library depends on components supplied by a C++ program. If these
+components do not meet their requirements, the Standard places no requirements
+on the implementation.
+</p>
+
+<p>
+-2- In particular, the effects are undefined in the following cases:
+</p>
+<p>
+[...]
+</p>
+<ul>
+<li>if an incomplete type (3.9) is used as a template argument when
+instantiating a template component. </li>
+</ul>
+</blockquote>
+
+<p>
+This is contradicted by § 20.6.6.2/2 [util.smartptr.shared] which
+states:
+</p>
+
+<blockquote>
+<p>
+[...]
+</p>
+
+<p>
+The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Modify the last bullet of § 17.4.3.6/2 [res.on.functions] to allow for
+exceptions:
+</p>
+
+<blockquote>
+<ul>
+<li>if an incomplete type (3.9) is used as a template argument when
+instantiating a template component<ins>, unless specifically allowed for the
+component</ins>. </li>
+</ul>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="613"></a>613. max_digits10 missing from numeric_limits</h3>
+<p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-11-20</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Section 18.2.1.5 [numeric.special] starts out by saying that "All members shall be provided 
+for all specializations."
+</p>
+<p>
+Then it goes on to show specializations for float and bool, where one member 
+is missing (max_digits10).
+</p>
+
+<p>
+Maarten Kronenburg adds:
+</p>
+
+<p>
+I agree, just adding the comment that the exact number of decimal digits
+is digits * ln(radix) / ln(10), where probably this real number is
+rounded downward for digits10, and rounded upward for max_digits10
+(when radix=10, then digits10=max_digits10).
+Why not add this exact definition also to the standard, so the user
+knows what these numbers exactly mean.
+</p>
+
+<p>
+Howard adds:
+</p>
+
+<p>
+For reference, here are the correct formulas from
+<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1822.pdf">N1822</a>:
+</p>
+
+<blockquote><pre>digits10 = floor((digits-1) * log10(2))
+max_digits10 = ceil((1 + digits) * log10(2))
+</pre></blockquote>
+
+<p>
+We are also missing a statement regarding for what specializations this member has meaning.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change and add after 18.2.1.2 [numeric.limits.members], p11:
+</p>
+
+<blockquote>
+<pre>static const int max_digits10;</pre>
+<blockquote>
+<p>
+-11- Number of base 10 digits required to ensure that values which
+differ <del>by only one epsilon</del> are always differentiated.
+</p>
+<p><ins>
+-12- Meaningful for all floating point types.
+</ins></p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 18.2.1.5 [numeric.special], p2:
+</p>
+
+<blockquote><pre>template&lt;&gt; class numeric_limits&lt;float&gt; { 
+public: 
+  static const bool is_specialized = true; 
+  ...
+  static const int digits10 = 6;
+  <ins>static const int max_digits10 = 9</ins>;
+  ...
+</pre></blockquote>
+
+<p>
+Change 18.2.1.5 [numeric.special], p3:
+</p>
+
+<blockquote><pre>template&lt;&gt; class numeric_limits&lt;bool&gt; { 
+public: 
+  static const bool is_specialized = true; 
+  ...
+  static const int digits10 = 0;
+  <ins>static const int max_digits10 = 0</ins>;
+  ...
+</pre></blockquote>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="616"></a>616. missing 'typename' in ctype_byname</h3>
+<p><b>Section:</b> 22.2.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-16</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.byname">issues</a> in [locale.ctype.byname].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Section 22.2.1.2 defines the ctype_byname class template. It contains the 
+line
+</p>
+
+<blockquote><pre>typedef ctype&lt;charT&gt;::mask   mask;
+</pre></blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+as this is a dependent type, it should obviously be
+</p>
+
+<blockquote><pre>typedef <ins>typename</ins> ctype&lt;charT&gt;::mask   mask;
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="619"></a>619. Longjmp wording problem</h3>
+<p><b>Section:</b> 18.8 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2007-01-12</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The wording for <tt>longjmp</tt> is confusing.
+</p>
+<p>
+18.8 [support.runtime] -4- Other runtime support
+</p>
+<blockquote><p>
+The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted
+behavior in this International Standard.  If any automatic objects would
+be destroyed by a thrown exception transferring control to another
+(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> that
+the throw point that transfers control to the same (destination) point has
+undefined behavior.
+</p></blockquote>
+<p>
+Someone at Google thinks that should say "then a call to <tt>longjmp(jbuf, val)</tt>
+*at* the throw point that transfers control".
+</p>
+<p>
+Bill Gibbons thinks it should say something like "If any automatic objects
+would be destroyed by an exception thrown at the point of the longjmp and
+caught only at the point of the setjmp, the behavior is undefined."
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In general, accept Bill Gibbons' recommendation,
+but add "call" to indicate that the undefined behavior
+comes from the dynamic call, not from its presence in the code.
+In 18.8 [support.runtime] paragraph 4, change
+</p>
+
+<blockquote><p>
+The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
+restricted behavior in this International Standard.  <del>If any automatic
+objects would be destroyed by a thrown exception transferring control to another
+(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt>
+that the throw point that transfers control to the same (destination) point has
+undefined behavior.</del> <ins>A <tt>setjmp</tt>/<tt>longjmp</tt> call pair has
+undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by
+<tt>catch</tt> and <tt>throw</tt> would destroy any automatic objects.</ins>
+</p></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="620"></a>620. valid uses of empty valarrays</h3>
+<p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+        <p>
+
+The <i>Effects</i>  clause for the  default <code>valarray</code> ctor
+suggests  that  it  is possible  to  increase  the  size of  an  empty
+<code>valarray</code>  object   by  calling  other   non-const  member
+functions of the class besides <code>resize()</code>. However, such an
+interpretation would  be contradicted by  the requirement on  the copy
+assignment  operator  (and  apparently   also  that  on  the  computed
+assignments)  that the  assigned arrays  be  the same  size.  See  the
+reflector discussion starting with c++std-lib-17871.
+
+        </p>
+        <p>
+
+In  addition,  <i>Footnote</i> 280  uses  some questionable  normative
+language.
+
+        </p>
+
+
+<p><b>Proposed resolution:</b></p>
+        <p>
+
+Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.5.2.1 [valarray.cons]):
+
+        </p>
+        <blockquote>
+            <p>
+
+<code>valarray();</code>
+
+            </p>
+            <p>
+
+<i>Effects</i>:      Constructs      an      object      of      class
+<code>valarray&lt;T&gt;</code>,<sup>279)</sup>    which    has    zero
+length<del> until it is passed into a library function as a modifiable
+lvalue or through a non-constant this pointer</del>.<sup>280)</sup>
+
+            </p>
+            <p>
+
+<ins><i>Postcondition</i>: <code>size() == 0</code>.</ins>
+
+            </p>
+            <p>
+
+<i>Footnote  280</i>:  This default  constructor  is essential,  since
+arrays  of  <code>valarray</code>  <del>are  likely to  prove  useful.
+There  shall also  be  a way  to change  the  size of  an array  after
+initialization;  this  is  supplied  by the  semantics</del>  <ins>may be
+useful.   The  length  of  an  empty  array  can  be  increased  after
+initialization  by  means</ins>  of the  <code>resize()</code>  member
+function.
+
+            </p>
+        </blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="621"></a>621. non-const copy assignment operators of helper arrays</h3>
+<p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+        <p>
+
+The computed and  "fill" assignment operators of <code>valarray</code>
+helper     array     class    templates     (<code>slice_array</code>,
+<code>gslice_array</code>,         <code>mask_array</code>,        and
+<code>indirect_array</code>) are const  member functions of each class
+template     (the     latter    by     the     resolution    of  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>
+since  they have reference  semantics and thus do  not affect
+the state of  the object on which they are  called.  However, the copy
+assignment  operators  of  these  class  templates,  which  also  have
+reference semantics,  are non-const.   The absence of  constness opens
+the door to speculation about whether they really are intended to have
+reference semantics (existing implementations vary widely).
+
+        </p>
+
+<p>
+Pre-Kona, Martin adds:
+</p>
+
+<p>
+I realized that adding the const qualifier to the
+functions as I suggested would break the const correctness of the
+classes. A few possible solutions come to mind:
+</p>
+
+<ol>
+<li>Add the const qualifier to the return types of these functions.</li>
+<li>Change the return type of all the functions to void to match
+the signatures of all the other assignment operators these classes
+define.</li>
+<li>Prohibit the copy assignment of these classes by declaring the
+copy assignment operators private (as is done and documented by
+some implementations).</li>
+</ol>
+
+
+
+<p><b>Proposed resolution:</b></p>
+        <p>
+
+Declare  the  copy  assignment  operators  of all  four  helper  array
+class templates const.
+
+        </p>
+        <p>
+
+Specifically,  make the following edits:
+
+        </p>
+        <p>
+
+Change     the    signature     in     26.5.5 [template.slice.array]    and
+26.5.5.1 [slice.arr.assign] as follows:
+
+        </p>
+        <blockquote><pre>
+<code><ins>const</ins> slice_array&amp; operator= (const slice_array&amp;)<ins> const</ins>;</code>
+
+        </pre></blockquote>
+        <p>
+
+Change     the     signature     in    26.5.7 [template.gslice.array]     and
+26.5.7.1 [gslice.array.assign] as follows:
+
+        </p>
+        <blockquote><pre>
+<code><ins>const</ins> gslice_array&amp; operator= (const gslice_array&amp;)<ins> const</ins>;</code>
+
+        </pre></blockquote>
+        <p>
+
+Change the  signature in 26.5.8 [template.mask.array]  and 26.5.8.1 [mask.array.assign] as
+follows:
+
+        </p>
+        <blockquote><pre>
+<code><ins>const</ins> mask_array&amp; operator= (const mask_array&amp;)<ins> const</ins>;</code>
+
+        </pre></blockquote>
+        <p>
+
+Change     the     signature     in    26.5.9 [template.indirect.array] and
+26.5.9.1 [indirect.array.assign] as follows:
+
+        </p>
+        <blockquote><pre>
+<code><ins>const</ins> indirect_array&amp; operator= (const indirect_array&amp;)<ins> const</ins>;</code>
+
+        </pre></blockquote>
+
+
+<p><i>[
+Kona (2007) Added const qualification to the return types and set to Ready.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="622"></a>622. behavior of <code>filebuf</code> dtor and <code>close</code> on error</h3>
+<p><b>Section:</b> 27.8.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+        <p>
+
+<code>basic_filebuf</code>  dtor is  specified to  have  the following
+straightforward effects:
+
+        </p>
+        <blockquote><p>
+
+<i>Effects</i>:       Destroys      an      object       of      class
+<code>basic_filebuf</code>. Calls <code>close()</code>.
+
+        </p></blockquote>
+        <p>
+
+<code>close()</code> does a lot of potentially complicated processing,
+including calling <code>overflow()</code> to write out the termination
+sequence  (to   bring  the  output  sequence  to   its  initial  shift
+state). Since  any of the  functions called during the  processing can
+throw an exception, what should the  effects of an exception be on the
+dtor? Should the  dtor catch and swallow it or  should it propagate it
+to the caller?  The text doesn't  seem to provide any guidance in this
+regard  other  than  the  general  restriction on  throwing  (but  not
+propagating)  exceptions  from   destructors  of  library  classes  in
+17.4.4.8 [res.on.exception.handling].
+
+        </p>
+        <p>
+
+Further,  the last thing  <code>close()</code> is  specified to  do is
+call <code>fclose()</code> to close the <code>FILE</code> pointer. The
+last sentence of the <i>Effects</i> clause reads:
+
+        </p>
+        <blockquote><p>
+
+...   If    any   of    the   calls   to    <code>overflow</code>   or
+<code>std::fclose</code> fails then <code>close</code> fails.
+
+        </p></blockquote>
+        <p>
+
+This  suggests that  <code>close()</code>  might be  required to  call
+<code>fclose()</code>   if  and  only   if  none   of  the   calls  to
+<code>overflow()</code> fails, and avoid closing the <code>FILE</code>
+otherwise. This  way, if  <code>overflow()</code> failed to  flush out
+the data, the caller  would have  the opportunity to  try to  flush it
+again (perhaps  after trying  to deal with  whatever problem  may have
+caused the failure), rather than losing it outright.
+
+        </p>
+        <p>
+
+On the other hand,  the function's <i>Postcondition</i> specifies that
+<code>is_open() ==  false</code>, which  suggests that it  should call
+<code>fclose()</code>       unconditionally.       However,      since
+<i>Postcondition</i> clauses  are specified for many  functions in the
+standard,  including constructors  where they  obviously  cannot apply
+after an  exception, it's not clear  whether this <i>Postcondition</i>
+clause is intended to apply even after an exception.
+
+        </p>
+        <p>
+
+It  might  be worth  noting  that  the  traditional behavior  (Classic
+Iostreams  <code>fstream::close()</code> and  C <code>fclose()</code>)
+is  to  close  the  <code>FILE</code> unconditionally,  regardless  of
+errors.
+
+        </p>
+
+<p><i>[
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> for related issues.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+        <p>
+
+After discussing this  on the reflector (see the  thread starting with
+c++std-lib-17650) we propose that <code>close()</code> be clarified to
+match the traditional behavior, that is to close the <code>FILE</code>
+unconditionally,  even after  errors or  exceptions.  In  addition, we
+propose the dtor description be amended so as to explicitly require it
+to catch and swallow any exceptions thrown by <code>close()</code>.
+
+        </p>
+        <p>
+
+Specifically,   we   propose   to   make  the   following   edits   in
+27.8.1.4 [filebuf.members]:
+
+        </p>
+        <blockquote>
+            <pre>
+<code>basic_filebuf&lt;charT,traits&gt;* close();</code>
+
+            </pre>
+            <p>
+
+<i>Effects</i>:  If <code>is_open()  == false</code>,  returns  a null
+pointer.        If      a       put      area       exists,      calls
+<code>overflow(traits::eof())</code> to flush  characters. If the last
+virtual   member  function   called  on   <code>*this</code>  (between
+<code>underflow</code>,  <code>overflow</code>,  <code>seekoff</code>,
+and   <code>seekpos</code>)  was   <code>overflow</code>   then  calls
+<code>a_codecvt.unshift</code> (possibly several times) to determine a
+termination   sequence,    inserts   those   characters    and   calls
+<code>overflow(traits::eof())</code>  again.  Finally<ins>, regardless
+of whether  any of the preceding  calls fails or  throws an exception,
+the  function</ins> <del>it</del>  closes   the  file   ("as   if"  by   calling
+<code>std::fclose(file)</code>).<sup>334)</sup>  If any  of  the calls
+<ins>made    by   the    function</ins><del>to   <code>overflow</code>
+or</del><ins>,  including  </ins><code>std::fclose</code><ins>, </ins>
+fails then <code>close</code> fails<ins>  by returning a null pointer.
+If one of these calls throws an exception, the exception is caught and
+rethrown after closing the file.</ins>
+
+            </p>
+        </blockquote>
+        <p>
+
+And to make the following edits in 27.8.1.2 [filebuf.cons].
+
+        </p>
+        <blockquote>
+            <pre>
+<code>virtual ~basic_filebuf();</code>
+
+            </pre>
+            <p>
+
+<i>Effects</i>:       Destroys      an      object       of      class
+<code>basic_filebuf&lt;charT,traits&gt;</code>.                   Calls
+<code>close()</code>.    <ins>If  an   exception  occurs   during  the
+destruction of the object, including the call to <code>close()</code>,
+the     exception    is     caught    but     not     rethrown    (see
+17.4.4.8 [res.on.exception.handling]).</ins>
+
+            </p>
+        </blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="623"></a>623. <code>pubimbue</code> forbidden to call <code>imbue</code></h3>
+<p><b>Section:</b> 27.1.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+        <p>
+
+27.1.1 [iostream.limits.imbue]  specifies  that  "no  function  described  in
+clause 27 except  for <code>ios_base::imbue</code> causes any instance
+of                   <code>basic_ios::imbue</code>                  or
+<code>basic_streambuf::imbue</code> to be called."
+
+        </p>
+        <p>
+
+That      contradicts      the      <i>Effects</i>     clause      for
+<code>basic_streambuf::pubimbue()</code>  which requires  the function
+to do just that: call <code>basic_streambuf::imbue()</code>.
+
+        </p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>
-Change "3.9.1 Additions to <code>&lt;cwchar&gt;</code> synopsis" to:
-</p>
-<pre>       namespace std {
-       namespace decimal {
-         // 3.9.2 wcstod functions:
-         decimal32  wcstod32  (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
-         decimal64  wcstod64  (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
-         decimal128 wcstod128 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
-       }
-       }
-</pre>
+        <p>
+
+To    fix   this,    rephrase    the   sentence    above   to    allow
+<code>pubimbue</code> to do what  it was designed to do. Specifically.
+change 27.1.1 [iostream.limits.imbue], p1 to read:
+
+        </p>
+        <blockquote><p>
+
+No     function    described     in    clause     27     except    for
+<code>ios_base::imbue</code>  <ins>and <code>basic_filebuf::pubimbue</code></ins>
+causes    any    instance    of    <code>basic_ios::imbue</code>    or
+<code>basic_streambuf::imbue</code> to be called. ...
+
+        </p></blockquote>
+
 
 
 
 
 <hr>
-<h3><a name="601"></a>601. Decimal: numeric_limits typos</h3>
-<p><b>Section:</b> TRDecimal 3.3 [trdec.types.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<h3><a name="624"></a>624. <code>valarray</code> assignment and arrays of unequal length</h3>
+<p><b>Section:</b> 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
+        <p>
+
+The behavior of the  <code>valarray</code> copy assignment operator is
+defined only when both sides have  the same number of elements and the
+spec is explicit about assignments of arrays of unequal lengths having
+undefined behavior.
+
+        </p>
+        <p>
+
+However, the generalized  subscripting assignment operators overloaded
+on <code>slice_array</code>  et al (26.5.2.2 [valarray.assign])  don't have any
+such restriction, leading  the reader to believe that  the behavior of
+these  overloads is  well defined  regardless  of the  lengths of  the
+arguments.
+
+        </p>
+        <p>
+
+For example,  based on  the reading  of the spec  the behavior  of the
+snippet below can be expected to be well-defined:
+
+        </p>
+        <pre>    const std::slice from_0_to_3 (0, 3, 1);   // refers to elements 0, 1, 2
+    const std::valarray&lt;int&gt; a (1, 3);        // a = { 1, 1, 1 }
+    std::valarray&lt;int&gt;       b (2, 4);        // b = { 2, 2, 2, 2 }
+
+    b = a [from_0_to_3];
+        </pre>
+        <p>
+
+In practice, <code>b</code> may end up being <code>{ 1, 1, 1 }</code>,
+<code>{  1,  1, 1,  2  }</code>,  or  anything else,  indicating  that
+existing implementations vary.
+
+        </p>
+
 <p>
-Daniel writes in a private email:
+Quoting from Section 3.4, Assignment operators, of Al Vermeulen's
+Proposal for Standard C++ Array Classes (see c++std-lib-704;
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>):
 </p>
+<blockquote><p>
+  ...if the size of the array on the right hand side of the equal
+  sign differs from the size of the array on the left, a run time
+  error occurs. How this error is handled is implementation
+  dependent; for compilers which support it, throwing an exception
+  would be reasonable.
+</p></blockquote>
 
-<blockquote>
 <p>
-- 3.3 'Additions to header &lt;limits&gt;' contains two 
-errors in the specialisation of numeric_limits&lt;decimal::decimal128&gt;:
+And see more history in
+<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1993/N0280.pdf">N0280</a>.
 </p>
-<ol>
-<li>The static member max() returns DEC128_MIN, this should be DEC128_MAX.</li>
-<li>The static member digits is assigned to 384,
-this should be 34 (Probably mixed up with the
-max. exponent for decimal::decimal64).</li>
-</ol>
-</blockquote>
 
+        <p>
 
-<p><b>Proposed resolution:</b></p>
-<p>
-In "3.3 Additions to header <code>&lt;limits&gt;</code>" change numeric_limits&lt;decimal::decimal128&gt; as follows:
-</p>
-<pre>        template&lt;&gt; class numeric_limits&lt;decimal::decimal128&gt; {
-          public:
-            static const bool is_specialized = true;
+It has  been argued in  discussions on the committee's  reflector that
+the semantics of all <code>valarray</code> assignment operators should
+be permitted to be undefined unless  the  length  of the arrays  being
+assigned is the same as the length of the one being assigned from. See
+the thread starting at c++std-lib-17786.
 
-            static decimal::decimal128 min() throw() { return DEC128_MIN; }
-            static decimal::decimal128 max() throw() { return <del>DEC128_MIN;</del> <ins>DEC128_MAX;</ins> }
+        </p>
+        <p>
 
-            static const int digits       = <del>384</del> <ins>34</ins>;
-            /* ... */
-</pre>
+In order  to reflect  such views, the  standard must specify  that the
+size of the  array referred to by the argument  of the assignment must
+match the size of the array  under assignment, for example by adding a
+<i>Requires</i> clause to 26.5.2.2 [valarray.assign] as follows:
+
+        </p>
+        <blockquote><p>
 
+<i>Requires</i>: The length of the  array to which the argument refers
+equals <code>size()</code>.
 
+        </p></blockquote>
 
+        <p>
 
-<hr>
-<h3><a name="602"></a>602. Decimal: "generic floating type" not defined.</h3>
-<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The document uses the term "generic floating types," but defines it nowhere.
-</p>
+Note that it's  far from clear that such leeway  is necessary in order
+to implement <code>valarray</code> efficiently.
+
+        </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change the first paragraph of "3 Decimal floating-point types" as follows:
+Insert new paragraph into 26.5.2.2 [valarray.assign]:
 </p>
-<blockquote><p>
-This Technical Report introduces three decimal floating-point types, named
-decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
-subset of the set of values of type decimal64; the set of values of the type
-decimal64 is a subset of the set of values of the type decimal128. Support for
-decimal128 is optional.  <ins>These types supplement the Standard C++ types
-<code>float</code>, <code>double</code>, and <code>long double</code>, which are
-collectively described as the <i>basic floating types</i></ins>.
-</p></blockquote>
+
+<blockquote>
+<pre>valarray&lt;T&gt;&amp; operator=(const slice_array&lt;T&gt;&amp;); 
+valarray&lt;T&gt;&amp; operator=(const gslice_array&lt;T&gt;&amp;); 
+valarray&lt;T&gt;&amp; operator=(const mask_array&lt;T&gt;&amp;); 
+valarray&lt;T&gt;&amp; operator=(const indirect_array&lt;T&gt;&amp;);
+</pre>
+<blockquote>
+<p><ins>
+<i>Requires</i>: The length of the  array to which the argument refers
+equals <code>size()</code>.
+</ins></p>
+<p>
+These operators allow the results of a generalized subscripting operation to be assigned directly to a <tt>valarray</tt>.
+</p>
+</blockquote>
+</blockquote>
+
 
 
 
 
 <hr>
-<h3><a name="603"></a>603. Decimal: Trivially simplifying decimal classes.</h3>
-<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<h3><a name="628"></a>628. Inconsistent definition of basic_regex constructor</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#WP">WP</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-01-23</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#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>In c++std-lib-17198, Martin writes:</p>
-
-<blockquote><p>
-Each of the three classes proposed in the paper (decimal32, decimal64,
-and decimal128) explicitly declares and specifies the semantics of its
-copy constructor, copy assignment operator, and destructor. Since the
-semantics of all three functions are identical to the trivial versions
-implicitly generated by the compiler in the absence of any declarations
-it is safe to drop them from the spec. This change would make the
-proposed classes consistent with other similar classes already in the
-standard (e.g., std::complex).
-</p></blockquote>
+<p>
+Section 28.8 [re.regex] lists a constructor
+</p>
 
+<blockquote><pre>template&lt;class InputIterator&gt;
+basic_regex(InputIterator first, InputIterator last,
+                       flag_type f = regex_constants::ECMAScript);
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change "3.2.2 Class <code>decimal32</code>" as follows:
+However, in section 28.8.2 [re.regex.construct], this constructor takes a 
+pair of <tt>ForwardIterator</tt>.
 </p>
-<pre>      namespace std {
-      namespace decimal {
-        class decimal32 {
-          public:
-            // 3.2.2.1 construct/copy/destroy:
-            decimal32();
-            <del>decimal32(const decimal32 &amp; d32);</del>
-            <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
-            <del>~decimal32();</del>
-            /* ... */
-</pre>
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-Change "3.2.2.1 construct/copy/destroy" as follows:
+Change 28.8.2 [re.regex.construct]:
 </p>
-<pre>        decimal32();
 
-    Effects: Constructs an object of type decimal32 with the value 0;
+<blockquote><pre>template &lt;class <del>ForwardIterator</del> <ins>InputIterator</ins>&gt;
+  basic_regex(<del>ForwardIterator</del> <ins>InputIterator</ins> first, <del>ForwardIterator</del> <ins>InputIterator</ins> last, 
+              flag_type f = regex_constants::ECMAScript);
+</pre></blockquote>
 
-        <del>decimal32(const decimal32 &amp; d32);</del>
-        <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
 
-    <del>Effects: Copies an object of type decimal32.</del>
 
-        <del>~decimal32();</del>
 
-    <del>Effects: Destroys an object of type decimal32.</del>
 
-</pre>
+
+<hr>
+<h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&amp;</tt></h3>
+<p><b>Section:</b> 20.6.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-07</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a></p>
+<p><b>Discussion:</b></p>
+
 <p>
-Change "3.2.3 Class <code>decimal64</code>" as follows:
+20.6.5.1 [allocator.members] says:
 </p>
-<pre>      namespace std {
-      namespace decimal {
-        class decimal64 {
-          public:
-            // 3.2.3.1 construct/copy/destroy:
-            decimal64();
-            <del>decimal64(const decimal64 &amp; d64);</del>
-            <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
-            <del>~decimal64();</del>
-            /* ... */
-</pre>
+<blockquote>
+<pre>pointer address(reference <i>x</i>) const;</pre>
+<blockquote>
 <p>
-Change "3.2.3.1 construct/copy/destroy" as follows:
+-1- <i>Returns:</i> <tt>&amp;<i>x</i></tt>.
 </p>
-<pre>        decimal64();
+</blockquote>
+</blockquote>
 
-    Effects: Constructs an object of type decimal64 with the value 0;
+<p>
+20.6.5.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
+only defines the semantics of copy construction, but also restricts what an overloaded
+<tt>operator&amp;</tt> may do.  I believe proposals are in the works (such as concepts
+and rvalue reference) to decouple these two requirements.  Indeed it is not evident
+that we should disallow overloading <tt>operator&amp;</tt> to return something other
+than the address of <tt>*this</tt>.
+</p>
 
-        <del>decimal64(const decimal64 &amp; d64);</del>
-        <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
+<p>
+An example of when you want to overload <tt>operator&amp;</tt> to return something
+other than the object's address is proxy references such as <tt>vector&lt;bool&gt;</tt>
+(or its replacement, currently code-named <tt>bit_vector</tt>).  Taking the address of
+such a proxy reference should logically yield a proxy pointer, which when dereferenced,
+yields a copy of the original proxy reference again.
+</p>
 
-    <del>Effects: Copies an object of type decimal64.</del>
+<p>
+On the other hand, some code truly needs the address of an object, and not a proxy
+(typically for determining the identity of an object compared to a reference object).
+<a href="http://www.boost.org/">boost</a> has long recognized this dilemma and solved it with 
+<a href="http://www.boost.org/libs/utility/utility.htm#addressof"><tt>boost::addressof</tt></a>.
+It appears to me that this would be useful functionality for the default allocator.  Adopting
+this definition for <tt>allocator::address</tt> would free the standard of requiring
+anything special from types which overload <tt>operator&amp;</tt>.  Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>
+is expected to make use of <tt>allocator::address</tt> mandatory for containers.
+</p>
 
-        <del>~decimal64();</del>
 
-    <del>Effects: Destroys an object of type decimal64.</del>
 
-</pre>
+<p><b>Proposed resolution:</b></p>
 <p>
-Change "3.2.4 Class <code>decimal128</code>" as follows:
+Change 20.6.5.1 [allocator.members]:
 </p>
-<pre>      namespace std {
-      namespace decimal {
-        class decimal128 {
-          public:
-            // 3.2.4.1 construct/copy/destroy:
-            decimal128();
-            <del>decimal128(const decimal128 &amp; d128);</del>
-            <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
-            <del>~decimal128();</del>
-            /* ... */
-</pre>
+
+<blockquote>
+<pre>pointer address(reference <i>x</i>) const;</pre>
+<blockquote>
+<p>
+-1- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
+even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
+</p>
+</blockquote>
+
+<pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
+<blockquote>
 <p>
-Change "3.2.4.1 construct/copy/destroy" as follows:
+-2- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
+even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
 </p>
-<pre>        decimal128();
+</blockquote>
+</blockquote>
 
-    Effects: Constructs an object of type decimal128 with the value 0;
+<p><i>[
+post Oxford:  This would be rendered NAD Editorial by acceptance of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
+]</i></p>
 
-        <del>decimal128(const decimal128 &amp; d128);</del>
-        <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
 
-    <del>Effects: Copies an object of type decimal128.</del>
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
+was subsequently split out into a separate paper N2436 for the purposes of voting.
+The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
+issue to Ready status to be voted into the WP at Kona.
+]</i></p>
 
-        <del>~decimal128();</del>
 
-    <del>Effects: Destroys an object of type decimal128.</del>
 
-</pre>
 
 
 
 
 <hr>
-<h3><a name="604"></a>604. Decimal: Storing a reference to a facet unsafe.</h3>
-<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3>
+<p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-In c++std-lib-17197, Martin writes:
+The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic].
+Although the section starts with a listing of the inserters including
+the new ones:
 </p>
-<blockquote><p>
-The extended_num_get and extended_num_put facets are designed
-to store a reference to a num_get or num_put facet which the
-extended facets delegate the parsing and formatting of types
-other than decimal. One form of the extended facet's ctor (the
-default ctor and the size_t overload) obtains the reference
-from the global C++ locale while the other form takes this
-reference as an argument.
-</p></blockquote>
-<blockquote><p>
-The problem with storing a reference to a facet in another
-object (as opposed to storing the locale object in which the
-facet is installed) is that doing so bypasses the reference
-counting mechanism designed to prevent a facet that is still
-being referenced (i.e., one that is still installed in some
-locale) from being destroyed when another locale that contains
-it is destroyed. Separating a facet reference from the locale
-it comes from van make it cumbersome (and in some cases might
-even make it impossible) for programs to prevent invalidating
-the reference. (The danger of this design is highlighted in
-the paper.)
-</p></blockquote>
-<blockquote><p>
-This problem could be easily avoided by having the extended
-facets store a copy of the locale from which they would extract
-the base facet either at construction time or when needed. To
-make it possible, the forms of ctors of the extended facets that
-take a reference to the base facet would need to be changed to
-take a locale argument instead.
-</p></blockquote>
 
+<blockquote><pre>operator&lt;&lt;(long long val );
+operator&lt;&lt;(unsigned long long val );
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-1. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows:
+the text in paragraph 1, which describes the corresponding effects
+of the inserters, depending on the actual type of val, does not
+handle the types <tt>long long</tt> and <tt>unsigned long long</tt>.
 </p>
-<pre>            extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
 
-            /* ... */
+<p><i>[
+Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
+misses any reference to extended integral types supplied by the
+implementation - one of the additions by core a couple of working papers
+back.
+]</i></p>
 
-            <del>// <i>const std::num_get&lt;charT, InputIterator&gt; &amp; <b>base</b></i>;        <i><b>exposition only</b></i></del>
-            <ins>// <i>std::locale <b>baseloc</b></i>;                                    <i><b>exposition only</b></i></ins>
-</pre>
+
+
+
+<p><b>Proposed resolution:</b></p>
 <p>
-2. Change the description of the above constructor in 3.10.2.1:
+In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
 </p>
-<pre>            extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
 
-</pre>
 <blockquote>
+When val is of type <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
+long</tt>, <ins>long long, unsigned long long,</ins> <tt>double</tt>,
+<tt>long double</tt>, or <tt>const void*</tt>, the formatting conversion
+occurs as if it performed the following code fragment:
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="643"></a>643. Impossible "as if" clauses</h3>
+<p><b>Section:</b> 27.8.1.1 [filebuf], 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-<b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by:
+The current standard 14882:2003(E) as well as N2134 have the
+following
+defects:
 </p>
-<pre>       extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
-                : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
-                { /* ... */ }
 
-</pre>
 <p>
-<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_get</code> facet.</del>
+27.8.1.1 [filebuf]/5 says:
+</p>
+
+<blockquote>
+<p>
+In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a 
+facet, referred to as <tt><i>a_codecvt</i></tt> in following sections, obtained "as if" by
 </p>
+<blockquote><pre>codecvt&lt;charT,char,typename traits::state_type&gt; <i>a_codecvt</i> =
+  use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
+</pre></blockquote>
 </blockquote>
+
 <p>
-3. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &amp;, ios_base::iostate &amp;, bool &amp;) const</code>, <i>et al</i> to
+<tt>use_facet</tt> returns a <tt>const facet</tt> reference and no facet is
+copyconstructible, so the codecvt construction should fail to compile.
 </p>
-<blockquote><p>
-<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_get&lt;charT, InputIterator&gt; &gt;(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>. 
-</p></blockquote>
+
 <p>
-4. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows:
+A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>.
 </p>
-<pre>            extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
 
-            /* ... */
 
-            <del>// <i>const std::num_put&lt;charT, OutputIterator&gt; &amp; <b>base</b></i>;       <i><b>exposition only</b></i></del>
-            <ins>// <i>std::locale <b>baseloc</b></i>;                                    <i><b>exposition only</b></i></ins>
-</pre>
+<p><b>Proposed resolution:</b></p>
 <p>
-5. Change the description of the above constructor in 3.10.3.1:
+In 27.8.1.1 [filebuf]/5 change the "as if" code
 </p>
-<pre>            extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
-</pre>
-<blockquote>
+
+<blockquote><pre><ins>const </ins>codecvt&lt;charT,char,typename traits::state_type&gt;<ins>&amp;</ins> <i>a_codecvt</i> =
+  use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
+</pre></blockquote>
+
 <p>
-<b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by:
+In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
 </p>
-<pre>       extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
-                : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
-                { /* ... */ }
 
-</pre>
+<blockquote>
 <p>
-<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_put</code> facet.</del>
+A local variable <tt><i>punct</i></tt> is initialized via
 </p>
+<blockquote><pre><ins>const </ins>numpunct&lt;charT&gt;<ins>&amp;</ins> <i>punct</i> = use_facet&lt; numpunct&lt;charT&gt; &gt;(<i>str</i>.getloc() )<ins>;</ins>
+</pre></blockquote>
 </blockquote>
+
 <p>
-6. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &amp;, char_type, bool &amp;) const</code>, <i>et al</i> to
+(Please note also the additional provided trailing semicolon)
 </p>
-<blockquote><p>
-<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_put&lt;charT, OutputIterator&gt; &gt;(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>. 
-</p></blockquote>
-
-<p><i>[
-Redmond:  We would prefer to rename "extended" to "decimal".
-]</i></p>
 
 
 
@@ -22727,105 +24586,115 @@ Redmond:  We would prefer to rename "extended" to "decimal".
 
 
 <hr>
-<h3><a name="605"></a>605. Decimal: &lt;decfloat.h&gt; doesn't live here anymore.</h3>
-<p><b>Section:</b> TRDecimal 3.4 [trdec.types.cdecfloat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Robert Klarer <b>Date:</b> 2006-10-17</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<h3><a name="644"></a>644. Possible typos in 'function' description</h3>
+<p><b>Section:</b> X [func.wrap.func.undef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-25</p>
 <p><b>Discussion:</b></p>
 <p>
-In Berlin, WG14 decided to drop the &lt;decfloat.h&gt; header. The
-contents of that header have been moved into &lt;float.h&gt;. For the
-sake of C compatibility, we should make corresponding changes.
+X [func.wrap.func.undef]
+</p>
+<p>
+The note in paragraph 2 refers to 'undefined void operators', while the 
+section declares a pair of operators returning bool.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-1. Change the heading of subclause 3.4, "Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code>" to "Additions to headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code>."
-</p>
-<p>
-2. Change the text of subclause 3.4 as follows:
-</p>
-<blockquote>
-<p>
-<del>The standard C++ headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>.  Their contents remain unchanged by this Technical Report.</del>
-</p>
-<p>
-<del>Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;decfloat.h&gt;</code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
-</p>
-<p>
-<ins>The header <code>&lt;cfloat&gt;</code> is described in [tr.c99.cfloat].  The header <code>&lt;float.h&gt;</code>
-is described in [tr.c99.floath]. These headers are extended by this
-Technical Report to define characteristics of the decimal
-floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;float.h&gt;</code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins>
-</p>
-</blockquote>
-<p>
-3. Change the heading of subclause 3.4.1, "Header <code>&lt;cdecfloat&gt;</code> synopsis"  to "Additions to header <code>&lt;cfloat&gt;</code> synopsis."
-</p>
-<p>
-4. Change the heading of subclause 3.4.2, "Header <code>&lt;decfloat.h&gt;</code> synopsis" to "Additions to header <code>&lt;float.h&gt;</code> synopsis."
+Change 20.5.15.2 [func.wrap.func]
 </p>
+
+<blockquote><pre>...
+private:
+   // X [func.wrap.func.undef], undefined operators:
+   template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
+   template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
+};
+</pre></blockquote>
+
 <p>
-5. Change the contents of 3.4.2 as follows:
+Change X [func.wrap.func.undef]
 </p>
-<pre>      <del>#include &lt;cdecfloat&gt;</del>
 
-      // <i>C-compatibility convenience typedefs:</i>
+<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>
 
-      typedef std::decimal::decimal32  _Decimal32;
-      typedef std::decimal::decimal64  _Decimal64;
-      typedef std::decimal::decimal128 _Decimal128;
-</pre>
+
+
+
+
+<hr>
+<h3><a name="646"></a>646. const incorrect match_result members</h3>
+<p><b>Section:</b> 28.10.4 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+28.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template
+members format as non-const functions, although they are declared
+as const in 28.10 [re.results]/3.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the missing <tt>const</tt> specifier to both <tt>format</tt> overloads described
+in section 28.10.4 [re.results.form].
+</p>
 
 
 
 
 
 <hr>
-<h3><a name="607"></a>607. Concern about short seed vectors</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
+<h3><a name="650"></a>650. regex_token_iterator and const correctness</h3>
+<p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Short seed vectors of 32-bit quantities all result in different states. However
-this is not true of seed vectors of 16-bit (or smaller) quantities.  For example
-these two seeds
+Both the class definition of regex_token_iterator (28.12.2
+[re.tokiter]/6) and the latter member specifications (28.12.2.2
+[re.tokiter.comp]/1+2) declare both comparison operators as
+non-const functions. Furtheron, both dereference operators are
+unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6
+as well as in (28.12.2.3 [re.tokiter.deref]/1+2).
 </p>
 
-<blockquote><pre>unsigned short seed = {1, 2, 3};
-unsigned short seed = {1, 2, 3, 0};
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-both pack to
+1) In (28.12.2 [re.tokiter]/6) change the current declarations
 </p>
 
-<blockquote><pre>unsigned seed = {0x20001, 0x3};
+<blockquote><pre>bool operator==(const regex_token_iterator&amp;) <ins>const</ins>;
+bool operator!=(const regex_token_iterator&amp;) <ins>const</ins>;
+const value_type&amp; operator*() <ins>const</ins>;
+const value_type* operator-&gt;() <ins>const</ins>;
 </pre></blockquote>
 
 <p>
-yielding the same state.
-</p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
+2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
 </p>
 
+<blockquote><pre>bool operator==(const regex_token_iterator&amp; right) <ins>const</ins>;
+bool operator!=(const regex_token_iterator&amp; right) <ins>const</ins>;
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
 </p>
 
+<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
+const value_type* operator-&gt;() <ins>const</ins>;
+</pre></blockquote>
+
 
 <p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
+is to adopt the proposed wording in this issue).
 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
 ]</i></p>
 
@@ -22834,33 +24703,47 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 <hr>
-<h3><a name="608"></a>608. Unclear seed_seq construction details</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
+<h3><a name="651"></a>651. Missing preconditions for regex_token_iterator c'tors</h3>
+<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
-treatment of signed quantities is unclear. Better to spell it out.
+The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
+the effects of the three non-default constructors of class
+template regex_token_iterator but is does not clarify which values
+are legal values for submatch/submatches. This becomes
+an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
+the notion of a "current match" by saying:
 </p>
 
+<blockquote><p>
+The <i>current match</i> is <tt>(*position).prefix()</tt> if <tt>subs[N]
+== -1</tt>, or <tt>(*position)[subs[N]]</tt> for any other value of
+<tt>subs[N]</tt>.
+</p></blockquote>
+
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
+It's not clear to me, whether other negative values except -1
+are legal arguments or not - it seems they are not.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+Add the following precondition paragraph just before the current
+28.12.2.1 [re.tokiter.cnstr]/2:
 </p>
 
+<blockquote><p>
+<i>Requires:</i> Each of the initialization values of <tt>subs</tt> must be <tt>&gt;= -1</tt>.
+</p></blockquote>
+
 
 <p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
+is to adopt the proposed wording in this issue).
 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
 ]</i></p>
 
@@ -22869,819 +24752,1035 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 <hr>
-<h3><a name="609"></a>609. missing static const</h3>
-<p><b>Section:</b> 26.4.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Walter E. Brown <b>Date:</b> 2006-11-02</p>
+<h3><a name="652"></a>652. regex_iterator and const correctness</h3>
+<p><b>Section:</b> 28.12.1 [re.regiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-In preparing N2111, an error on my part resulted in the omission of the
-following line from the template synopsis in the cited section:
+<p>Both the class definition of regex_iterator (28.12.1 [re.regiter]/1)
+and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2)
+declare both comparison operators as
+non-const functions. Furtheron, both dereference operators are
+unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
+as well as in (28.12.1.3 [re.regiter.deref]/1+2).
 </p>
 
-<blockquote><pre>static const size_t word_size = w;
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
+1) In (28.12.1 [re.regiter]/1) change the current declarations
 </p>
 
+<blockquote><pre>bool operator==(const regex_iterator&amp;) <ins>const</ins>;
+bool operator!=(const regex_iterator&amp;) <ins>const</ins>;
+const value_type&amp; operator*() <ins>const</ins>;
+const value_type* operator-&gt;() <ins>const</ins>;
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
+2) In 28.12.1.3 [re.regiter.deref] change the following declarations
 </p>
 
-<blockquote><pre>// engine characteristics
-<ins>static const size_t word_size = w;</ins>
+<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
+const value_type* operator-&gt;() <ins>const</ins>;
 </pre></blockquote>
 
 <p>
-and accept my apologies for the oversight.
+3) In 28.12.1.2 [re.regiter.comp] change the following declarations
 </p>
 
+<blockquote><pre>bool operator==(const regex_iterator&amp; right) <ins>const</ins>;
+bool operator!=(const regex_iterator&amp; right) <ins>const</ins>;
+</pre></blockquote>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
+is to adopt the proposed wording in this issue).
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
 
 
 
 
 <hr>
-<h3><a name="610"></a>610. Suggested non-normative note for C++0x</h3>
-<p><b>Section:</b> 20.5.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Scott Meyers <b>Date:</b> 2006-11-02</p>
+<h3><a name="654"></a>654. Missing IO roundtrip for random number engines</h3>
+<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-My suggestion is that implementers of both tr1::function and its 
-official C++0x successor be explicitly encouraged (but not required) to 
-optimize for the cases mentioned above, i.e., function pointers and 
-small function objects.  They could do this by using a small internal 
-buffer akin to the buffer used by implementations of the small string 
-optimization.  (That would make this the small functor optimization -- 
-SFO :-})  The form of this encouragement could be a note in the standard 
-akin to footnote 214 of the current standard.
+Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify
+the IO insertion and extraction semantic of random
+number engines. It can be shown, v.i., that the specification
+of the extractor cannot guarantee to fulfill the requirement
+from para 5:
 </p>
 
-<p>
-Dave Abrahams notes:
-</p>
+<blockquote><p>
+If a textual representation written via os &lt;&lt; x was
+subsequently read via is &gt;&gt; v, then x == v provided that
+there have been no intervening invocations of x or of v.
+</p></blockquote>
 
 <p>
-"shall not throw exceptions" should really be "nothing," both to be more
-grammatical and to be consistent with existing wording in the standard.
+The problem is, that the extraction process described in
+table 98 misses to specify that it will initially set the
+if.fmtflags to ios_base::dec, see table 104:
 </p>
 
+<blockquote><p>
+dec: converts integer input or generates integer output
+in decimal base
+</p></blockquote>
+
 <p>
-Doug Gregor comments: I think this is a good idea. Currently, implementations of
-tr1::function are required to have non-throwing constructors and assignment
-operators when the target function object is a function pointer or a
-reference_wrapper. The common case, however, is for a tr1::function to store
-either an empty function object or a member pointer + an object pointer.
+Proof: The following small program demonstrates the violation
+of requirements (exception safety not fulfilled):
 </p>
+
+<blockquote><pre>#include &lt;cassert&gt;
+#include &lt;ostream&gt;
+#include &lt;iostream&gt;
+#include &lt;iomanip&gt;
+#include &lt;sstream&gt;
+
+class RanNumEngine {
+  int state;
+public:
+  RanNumEngine() : state(42) {}
+
+  bool operator==(RanNumEngine other) const {
+	  return state == other.state;
+  }
+
+  template &lt;typename Ch, typename Tr&gt;
+  friend std::basic_ostream&lt;Ch, Tr&gt;&amp; operator&lt;&lt;(std::basic_ostream&lt;Ch, Tr&gt;&amp; os, RanNumEngine engine) {
+	Ch old = os.fill(os.widen(' ')); // Sets space character
+	std::ios_base::fmtflags f = os.flags();
+	os &lt;&lt; std::dec &lt;&lt; std::left &lt;&lt; engine.state; // Adds ios_base::dec|ios_base::left
+	os.fill(old); // Undo
+	os.flags(f);
+	return os;
+  }
+
+  template &lt;typename Ch, typename Tr&gt;
+  friend std::basic_istream&lt;Ch, Tr&gt;&amp; operator&gt;&gt;(std::basic_istream&lt;Ch, Tr&gt;&amp; is, RanNumEngine&amp; engine) {
+       // Uncomment only for the fix.
+
+	//std::ios_base::fmtflags f = is.flags();
+	//is &gt;&gt; std::dec;
+	is &gt;&gt; engine.state;
+	//is.flags(f);
+	return is;
+  }
+};
+
+int main() {
+	std::stringstream s;
+	s &lt;&lt; std::setfill('#'); // No problem
+        s &lt;&lt; std::oct; // Yikes!
+        // Here starts para 5 requirements:
+	RanNumEngine x;
+	s &lt;&lt; x;
+	RanNumEngine v;
+	s &gt;&gt; v;
+	assert(x == v); // Fails: 42 == 34
+}
+</pre></blockquote>
+
 <p>
-The function implementation in the upcoming Boost 1.34.0 uses the
-"SFO", so that the function objects for typical bind expressions like
+A second, minor issue seems to be, that the insertion
+description from table 98 unnecessarily requires the
+addition of ios_base::fixed (which only influences floating-point
+numbers). Its not entirely clear to me whether the proposed
+standard does require that the state of random number engines
+is stored in integral types or not, but I have the impression
+that this is the indent, see e.g. p. 3
 </p>
-<blockquote><pre>bind(&amp;X::f, this, _1, _2, _3)
-</pre></blockquote>
+
+<blockquote><p>
+The specification of each random number engine defines the
+size of its state in multiples of the size of its result_type.
+</p></blockquote>
 
 <p>
-do not require heap allocation when stored in a boost::function. I
-believe Dinkumware's implementation also performs this optimization.
+If other types than integrals are supported, then I wonder why
+no requirements are specified for the precision of the stream.
 </p>
 
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
 </p>
 
-<blockquote>
-<p>
-<i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a function
-pointer or a function object passed via <tt>reference_wrapper</tt>. Otherwise,
-may throw <tt>bad_alloc</tt> or any exception thrown by the copy constructor of
-the stored function object.
-</p>
-<p>
-<ins><i>Note:</i> Implementations are encouraged to avoid the use of dynamically
-allocated memory for "small" function objects, e.g., where <tt>f</tt>'s target
-is an object holding only a pointer or reference to an object and a member
-function pointer (a "bound member function").</ins>
-</p>
-</blockquote>
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="611"></a>611. Standard library templates and incomplete types</h3>
-<p><b>Section:</b> 17.4.3.6 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Nicola Musatti <b>Date:</b> 2006-11-13</p>
+<h3><a name="655"></a>655. Signature of generate_canonical not useful</h3>
+<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-In the latest available draft standard 
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
-§ 17.4.3.6 [res.on.functions] states:
-</p>
-
-<blockquote>
-<p>
--1- In certain cases (replacement functions, handler functions, operations on
-types used to instantiate standard library template components), the C++
-Standard Library depends on components supplied by a C++ program. If these
-components do not meet their requirements, the Standard places no requirements
-on the implementation.
-</p>
-
-<p>
--2- In particular, the effects are undefined in the following cases:
-</p>
-<p>
-[...]
+In 26.4.2 [rand.synopsis] we have the declaration
 </p>
-<ul>
-<li>if an incomplete type (3.9) is used as a template argument when
-instantiating a template component. </li>
-</ul>
-</blockquote>
 
-<p>
-This is contradicted by § 20.6.6.2/2 [util.smartptr.shared] which
-states:
-</p>
+<blockquote><pre>template&lt;class RealType, class UniformRandomNumberGenerator,
+  size_t bits&gt;
+result_type generate_canonical(UniformRandomNumberGenerator&amp; g);
+</pre></blockquote>
 
-<blockquote>
 <p>
-[...]
+Besides the "result_type" issue (already recognized by Bo Persson
+at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
+the template parameter order is not reasonably choosen: Obviously
+one always needs to specify all three parameters, although usually
+only two are required, namely the result type RealType and the
+wanted bits, because UniformRandomNumberGenerator can usually
+be deduced.
 </p>
 
 <p>
-The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
 </p>
-</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Modify the last bullet of § 17.4.3.6/2 [res.on.functions] to allow for
-exceptions:
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
 </p>
 
-<blockquote>
-<ul>
-<li>if an incomplete type (3.9) is used as a template argument when
-instantiating a template component<ins>, unless specifically allowed for the
-component</ins>. </li>
-</ul>
-</blockquote>
 
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="613"></a>613. max_digits10 missing from numeric_limits</h3>
-<p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-11-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p>
+<h3><a name="660"></a>660. Missing Bitwise Operations</h3>
+<p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-04-02</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>
-Section 18.2.1.5 [numeric.special] starts out by saying that "All members shall be provided 
-for all specializations."
-</p>
-<p>
-Then it goes on to show specializations for float and bool, where one member 
-is missing (max_digits10).
-</p>
+<p>Section 20.5 [function.objects] provides <span id="st" name="st" class="st">function</span>
+<span id="st" name="st" class="st">objects</span> for some unary and binary 
+operations, but others are missing. In a LWG reflector discussion, beginning 
+with c++std-lib-18078, pros and cons of adding some of the missing operations 
+were discussed. Bjarne Stroustrup commented "Why standardize what isn't used? 
+Yes, I see the chicken and egg problems here, but it would be nice to see a 
+couple of genuine uses before making additions."</p>
+<p>A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have 
+already added these functions, either publicly or for internal use. For example, 
+Doug Gregor commented: "Boost will also add ... (|, &amp;, ^) in 1.35.0, because we 
+need those <span id="st" name="st" class="st">function</span>
+<span id="st" name="st" class="st">objects</span> to represent various parallel 
+collective operations (reductions, prefix reductions, etc.) in the new Message 
+Passing Interface (MPI) library."</p>
+<p>Because the bitwise operators have the strongest use cases, the proposed 
+resolution is limited to them.</p>
 
-<p>
-Maarten Kronenburg adds:
-</p>
 
-<p>
-I agree, just adding the comment that the exact number of decimal digits
-is digits * ln(radix) / ln(10), where probably this real number is
-rounded downward for digits10, and rounded upward for max_digits10
-(when radix=10, then digits10=max_digits10).
-Why not add this exact definition also to the standard, so the user
-knows what these numbers exactly mean.
-</p>
+<p><b>Proposed resolution:</b></p>
+<p>To 20.5 [function.objects], Function objects, paragraph 2, add to the header 
+&lt;functional&gt; synopsis:</p>
+<blockquote>
+  <pre>template &lt;class T&gt; struct bit_and;
+template &lt;class T&gt; struct bit_or;
+template &lt;class T&gt; struct bit_xor;</pre>
+</blockquote>
+<p>At a location in clause 20 to be determined by the Project Editor, add:</p>
+<blockquote>
+  <p>The library provides basic function object classes for all of the bitwise 
+  operators in the language ([expr.bit.and], [expr.or], [exp.xor]).</p>
+  <pre>template &lt;class T&gt; struct bit_and : binary_function&lt;T,T,T&gt; {
+  T operator()(const T&amp; x , const T&amp; y ) const;
+};</pre>
+  <blockquote>
+    <p><code>operator()</code> returns<code> x &amp; y</code> .</p>
+  </blockquote>
+  <pre>template &lt;class T&gt; struct bit_or : binary_function&lt;T,T,T&gt; {
+  T operator()(const T&amp; x , const T&amp; y ) const;
+};</pre>
+  <blockquote>
+    <p><code>operator()</code> returns <code>x | y</code> .</p>
+  </blockquote>
+  <pre>template &lt;class T&gt; struct bit_xor : binary_function&lt;T,T,T&gt; {
+  T operator()(const T&amp; x , const T&amp; y ) const;
+};</pre>
+  <blockquote>
+    <p><code>operator()</code> returns <code>x ^ y</code> .</p>
+  </blockquote>
+</blockquote>
 
-<p>
-Howard adds:
-</p>
 
-<p>
-For reference, here are the correct formulas from
-<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1822.pdf">N1822</a>:
-</p>
 
-<blockquote><pre>digits10 = floor((digits-1) * log10(2))
-max_digits10 = ceil((1 + digits) * log10(2))
-</pre></blockquote>
 
+
+<hr>
+<h3><a name="661"></a>661. New 27.6.1.2.2 changes make special extractions useless</h3>
+<p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-04-01</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-We are also missing a statement regarding for what specializations this member has meaning.
+To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
+the explicit description of the extraction of the types short and int in
+terms of as-if code fragments.
 </p>
 
+<ol>
+<li>
+The corresponding as-if extractions in paragraph 2 and 3 will never
+result in a change of the operator&gt;&gt; argument val, because the
+contents of the local variable lval is in no case written into val.
+Furtheron both fragments need a currently missing parentheses in the
+beginning of the if-statement to be valid C++.
+</li>
+<li>I would like to ask whether the omission of a similar explicit
+extraction of unsigned short and unsigned int in terms of long -
+compared to their corresponding new insertions, as described in
+27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or
+an
+oversight.
+</li>
+</ol>
 
 
 <p><b>Proposed resolution:</b></p>
+<ol>
+<li>
 <p>
-Change and add after 18.2.1.2 [numeric.limits.members], p11:
-</p>
-
-<blockquote>
-<pre>static const int max_digits10;</pre>
-<blockquote>
-<p>
--11- Number of base 10 digits required to ensure that values which
-differ <del>by only one epsilon</del> are always differentiated.
-</p>
-<p><ins>
--12- Meaningful for all floating point types.
-</ins></p>
-</blockquote>
-</blockquote>
-
-<p>
-Change 18.2.1.5 [numeric.special], p2:
-</p>
-
-<blockquote><pre>template&lt;&gt; class numeric_limits&lt;float&gt; { 
-public: 
-  static const bool is_specialized = true; 
-  ...
-  static const int digits10 = 6;
-  <ins>static const int max_digits10 = 9</ins>;
-  ...
+In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
+</p>
+<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
+iostate err = 0;
+long lval;
+use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
+if (err == 0) <ins>{</ins>
+  <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval)<del>)</del>
+      err = ios_base::failbit;
+  <ins>else
+    val = static_cast&lt;short&gt;(lval);
+}</ins>
+setstate(err);
 </pre></blockquote>
 
 <p>
-Change 18.2.1.5 [numeric.special], p3:
+Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
 </p>
 
-<blockquote><pre>template&lt;&gt; class numeric_limits&lt;bool&gt; { 
-public: 
-  static const bool is_specialized = true; 
-  ...
-  static const int digits10 = 0;
-  <ins>static const int max_digits10 = 0</ins>;
-  ...
+<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
+iostate err = 0;
+long lval;
+use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
+if (err == 0) <ins>{</ins>
+  <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval)<del>)</del>
+      err = ios_base::failbit;
+  <ins>else
+    val = static_cast&lt;int&gt;(lval);
+}</ins>
+setstate(err);
 </pre></blockquote>
+</li>
+<li>
+---
+</li>
+</ol>
 
 
+<p><i>[
+Kona (2007): Note to the editor: the name lval in the call to <tt>use_facet</tt>
+is incorrectly italicized in the code fragments corresponding to
+<tt>operator&gt;&gt;(short &amp;)</tt> and <tt>operator &gt;&gt;(int &amp;)</tt>. Also, val -- which appears
+twice on the line with the <tt>static_cast</tt> in the proposed resolution --
+should be italicized. Also, in response to part two of the issue: this
+is deliberate.
+]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="616"></a>616. missing 'typename' in ctype_byname</h3>
-<p><b>Section:</b> 22.2.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.byname">issues</a> in [locale.ctype.byname].</p>
+<h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt&lt;char, char, mbstate_t&gt;</tt></h3>
+<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Section 22.2.1.2 defines the ctype_byname class template. It contains the 
-line
+22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>):
 </p>
 
-<blockquote><pre>typedef ctype&lt;charT&gt;::mask   mask;
-</pre></blockquote>
+<blockquote><p>
+<i>Effects:</i> Places characters starting at to that should be appended to
+terminate a sequence when the current <tt>stateT</tt> is given by
+<tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> -
+<i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt>
+pointer pointing one beyond the last element successfully stored.
+<em><tt>codecvt&lt;char, char, mbstate_t&gt;</tt> stores no characters.</em>
+</p></blockquote>
+
+<p>
+The following objection has been raised:
+</p>
+
+<blockquote><p>
+Since the C++ Standard permits a nontrivial conversion for the required
+instantiations of <tt>codecvt</tt>, it is overly restrictive to say that
+<tt>do_unshift</tt> must store no characters and return <tt>noconv</tt>.
+</p></blockquote>
 
+<p>
+[Plum ref _222152Y50]
+</p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-as this is a dependent type, it should obviously be
+Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
 </p>
 
-<blockquote><pre>typedef <ins>typename</ins> ctype&lt;charT&gt;::mask   mask;
-</pre></blockquote>
+<blockquote>
+<p>
+<i>Effects:</i> Places characters starting at <i>to</i> that should be
+appended to terminate a sequence when the current <tt>stateT</tt> is
+given by state.<sup>237)</sup> Stores no more than (<i>to_limit -to</i>)
+destination elements, and leaves the <i>to_next</i> pointer pointing one
+beyond the last element successfully stored. <del><tt>codecvt&lt;char, char,
+mbstate_t&gt;</tt> stores no characters.</del>
+</p>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="619"></a>619. Longjmp wording problem</h3>
-<p><b>Section:</b> 18.8 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2007-01-12</p>
+<h3><a name="665"></a>665. <tt>do_unshift</tt> return value</h3>
+<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The wording for <tt>longjmp</tt> is confusing.
-</p>
-<p>
-18.8 [support.runtime] -4- Other runtime support
+22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
 </p>
+
 <blockquote><p>
-The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted
-behavior in this International Standard.  If any automatic objects would
-be destroyed by a thrown exception transferring control to another
-(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> that
-the throw point that transfers control to the same (destination) point has
-undefined behavior.
+<tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.
 </p></blockquote>
+
 <p>
-Someone at Google thinks that should say "then a call to <tt>longjmp(jbuf, val)</tt>
-*at* the throw point that transfers control".
+The following objection has been raised:
 </p>
+
+<blockquote><p>
+Despite what the C++ Standard 
+says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since 
+they can be nontrivial. At least one implementation does whatever the 
+C functions do.
+</p></blockquote>
+
 <p>
-Bill Gibbons thinks it should say something like "If any automatic objects
-would be destroyed by an exception thrown at the point of the longjmp and
-caught only at the point of the setjmp, the behavior is undefined."
+[Plum ref _222152Y62]
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In general, accept Bill Gibbons' recommendation,
-but add "call" to indicate that the undefined behavior
-comes from the dynamic call, not from its presence in the code.
-In 18.8 [support.runtime] paragraph 4, change
+Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
 </p>
 
-<blockquote><p>
-The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
-restricted behavior in this International Standard.  <del>If any automatic
-objects would be destroyed by a thrown exception transferring control to another
-(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt>
-that the throw point that transfers control to the same (destination) point has
-undefined behavior.</del> <ins>A <tt>setjmp</tt>/<tt>longjmp</tt> call pair has
-undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by
-<tt>catch</tt> and <tt>throw</tt> would destroy any automatic objects.</ins>
-</p></blockquote>
+<blockquote>
+<p><i>Returns:</i> An enumeration value, as summarized in Table 76:</p>
+<p>...</p>
+<p>
+<del><tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.</del>
+</p>
+</blockquote>
+
 
 
 
 
 
 <hr>
-<h3><a name="628"></a>628. Inconsistent definition of basic_regex constructor</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#WP">WP</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-01-23</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>
+<h3><a name="666"></a>666. <tt>moneypunct::do_curr_symbol()</tt></h3>
+<p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Section 28.8 [re.regex] lists a constructor
+22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
 </p>
 
-<blockquote><pre>template&lt;class InputIterator&gt;
-basic_regex(InputIterator first, InputIterator last,
-                       flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
+<blockquote><p>
+<sup>257)</sup> For international 
+specializations (second template parameter <tt>true</tt>) this is always four 
+characters long, usually three letters and a space.
+</p></blockquote>
 
 <p>
-However, in section 28.8.2 [re.regex.construct], this constructor takes a 
-pair of <tt>ForwardIterator</tt>.
+The following objection has been raised:
+</p>
+
+<blockquote><p>
+The international currency 
+symbol is whatever the underlying locale says it is, not necessarily 
+four characters long.
+</p></blockquote>
+
+<p>
+[Plum ref _222632Y41]
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Change 28.8.2 [re.regex.construct]:
+Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
 </p>
 
-<blockquote><pre>template &lt;class <del>ForwardIterator</del> <ins>InputIterator</ins>&gt;
-  basic_regex(<del>ForwardIterator</del> <ins>InputIterator</ins> first, <del>ForwardIterator</del> <ins>InputIterator</ins> last, 
-              flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
-
+<blockquote>
+<p>
+<sup>253)</sup> For international specializations (second template
+parameter <tt>true</tt>) this is <del>always</del> <ins>typically</ins>
+four characters long, usually three letters and a space.
+</p>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&amp;</tt></h3>
-<p><b>Section:</b> 20.6.1.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
+<h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3>
+<p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-05</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a></p>
 <p><b>Discussion:</b></p>
-
 <p>
-20.6.1.1 [allocator.members] says:
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose
+any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate
+and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>.
 </p>
-<blockquote>
-<pre>pointer address(reference <i>x</i>) const;</pre>
-<blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
 <p>
--1- <i>Returns:</i> <tt>&amp;<i>x</i></tt>.
+Change 20.6.12.2 [util.smartptr.shared] as follows:
 </p>
-</blockquote>
+
+<blockquote>
+<pre>template&lt;class Y&gt; explicit shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
+<ins>template&lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
+template&lt;class Y, class D&gt; explicit shared_ptr(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins>
+...
+template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
+<ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
+template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
 </blockquote>
 
 <p>
-20.6.1.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
-only defines the semantics of copy construction, but also restricts what an overloaded
-<tt>operator&amp;</tt> may do.  I believe proposals are in the works (such as concepts
-and rvalue reference) to decouple these two requirements.  Indeed it is not evident
-that we should disallow overloading <tt>operator&amp;</tt> to return something other
-than the address of <tt>*this</tt>.
+Change 20.6.12.2.1 [util.smartptr.shared.const] as follows:
 </p>
 
-<p>
-An example of when you want to overload <tt>operator&amp;</tt> to return something
-other than the object's address is proxy references such as <tt>vector&lt;bool&gt;</tt>
-(or its replacement, currently code-named <tt>bit_vector</tt>).  Taking the address of
-such a proxy reference should logically yield a proxy pointer, which when dereferenced,
-yields a copy of the original proxy reference again.
-</p>
+<blockquote>
+<pre><ins>template&lt;class Y&gt; shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</ins></pre>
+</blockquote>
 
 <p>
-On the other hand, some code truly needs the address of an object, and not a proxy
-(typically for determining the identity of an object compared to a reference object).
-<a href="http://www.boost.org/">boost</a> has long recognized this dilemma and solved it with 
-<a href="http://www.boost.org/libs/utility/utility.htm#addressof"><tt>boost::addressof</tt></a>.
-It appears to me that this would be useful functionality for the default allocator.  Adopting
-this definition for <tt>allocator::address</tt> would free the standard of requiring
-anything special from types which overload <tt>operator&amp;</tt>.  Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>
-is expected to make use of <tt>allocator::address</tt> mandatory for containers.
+Add to 20.6.12.2.1 [util.smartptr.shared.const]:
 </p>
 
+<blockquote>
+<pre><ins>template&lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);</ins></pre>
+<blockquote>
+
+<p><ins>
+<i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is
+          not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt>
+          otherwise.
+</ins></p>
 
+<p><ins>
+<i>Exception safety:</i> If an exception is thrown, the constructor has no effect.
+</ins></p>
+</blockquote>
+
+</blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 20.6.1.1 [allocator.members]:
+Change 20.6.12.2.3 [util.smartptr.shared.assign] as follows:
 </p>
 
 <blockquote>
-<pre>pointer address(reference <i>x</i>) const;</pre>
-<blockquote>
-<p>
--1- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
-even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
-</p>
+<pre>template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</pre>
 </blockquote>
 
-<pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
-<blockquote>
 <p>
--2- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
-even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
+Add to 20.6.12.2.3 [util.smartptr.shared.assign]:
 </p>
+
+<blockquote>
+<pre><ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
+
+<blockquote>
+<p><ins>
+-4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>.
+</ins></p>
+<p><ins>
+-5- <i>Returns:</i> <tt>*this</tt>.
+</ins></p>
 </blockquote>
+
 </blockquote>
 
-<p><i>[
-post Oxford:  This would be rendered NAD Editorial by acceptance of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
-]</i></p>
 
 
 <p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
-was subsequently split out into a separate paper N2436 for the purposes of voting.
-The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
-issue to Ready status to be voted into the WP at Kona.
+Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>) to deal with the question of
+whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
 ]</i></p>
 
 
 
 
 
-
-
 <hr>
-<h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3>
-<p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p>
+<h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
+<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic].
-Although the section starts with a listing of the inserters including
-the new ones:
+<tt>seed_seq::randomize</tt> provides a mechanism for initializing random number
+engines which ideally would yield "distant" states when given "close"
+seeds.  The algorithm for <tt>seed_seq::randomize</tt> given in the current
+Working Draft for C++,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
+(2007-05-08), has 3 weaknesses
 </p>
 
-<blockquote><pre>operator&lt;&lt;(long long val );
-operator&lt;&lt;(unsigned long long val );
-</pre></blockquote>
+<ol>
+<li>
+<p> Collisions in state.  Because of the way the state is initialized,
+    seeds of different lengths may result in the same state.  The
+    current version of seed_seq has the following properties:</p>
+<ul>
+<li>  For a given <tt>s &lt;= n</tt>, each of the 2^(32s) seed vectors results in a
+      distinct state.</li>
+</ul>
+<p>
+    The proposed algorithm (below) has the considerably stronger
+    properties:</p>
+<ul>
+<li>   All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s &lt; n</tt>
+      result in distinct states.
+</li>
+<li>  All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in
+      distinct states.
+</li>
+</ul>
+</li>
+<li>
+<p> Poor mixing of <tt>v'</tt>s entropy into the state.  Consider <tt>v.size() == n</tt>
+    and hold <tt>v[n/2]</tt> thru <tt>v[n-1]</tt> fixed while varying <tt>v[0]</tt> thru <tt>v[n/2-1]</tt>,
+    a total of <tt>2^(16n)</tt> possibilities.  Because of the simple recursion
+    used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64
+    possible states.</p>
 
+<p> The proposed algorithm uses a more complex recursion which results
+    in much better mixing.</p>
+</li>
+<li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>.  The proposed
+    algorithm remedies this.
+</li>
+</ol>
 <p>
-the text in paragraph 1, which describes the corresponding effects
-of the inserters, depending on the actual type of val, does not
-handle the types <tt>long long</tt> and <tt>unsigned long long</tt>.
+The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the
+initialization procedure for the Mersenne Twister by Makoto Matsumoto
+and Takuji Nishimura.  The weakness (2) given above was communicated to
+me by Matsumoto last year.
+</p>
+<p>
+The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito,
+a student of Matsumoto, and is given in the implementation of the
+SIMD-oriented Fast Mersenne Twister random number generator SFMT.
+<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a>
+<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/SFMT-src-1.2.tar.gz">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz</a>
+</p>
+<p>
+See
+Mutsuo Saito,
+An Application of Finite Field: Design and Implementation of 128-bit
+Instruction-Based Fast Pseudorandom Number Generator,
+Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
+<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a>
+</p>
+<p>
+One change has been made here, namely to treat the case of small <tt>n</tt>
+(setting <tt>t = (n-1)/2</tt> for <tt>n &lt; 7</tt>).
+</p>
+<p>
+Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
+in making this incompatible improvement to it.
 </p>
 
-<p><i>[
-Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
-misses any reference to extended integral types supplied by the
-implementation - one of the additions by core a couple of working papers
-back.
-]</i></p>
-
-
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
 </p>
 
-<blockquote>
-When val is of type <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
-long</tt>, <ins>long long, unsigned long long,</ins> <tt>double</tt>,
-<tt>long double</tt>, or <tt>const void*</tt>, the formatting conversion
-occurs as if it performed the following code fragment:
-</blockquote>
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="643"></a>643. Impossible "as if" clauses</h3>
-<p><b>Section:</b> 27.8.1.1 [filebuf], 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</p>
+<h3><a name="678"></a>678. Changes for [rand.req.eng]</h3>
+<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The current standard 14882:2003(E) as well as N2134 have the
-following
-defects:
+Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
 </p>
 
 <p>
-27.8.1.1 [filebuf]/5 says:
+This change follows naturally from the proposed change to
+<tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>.
 </p>
 
-<blockquote>
 <p>
-In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a 
-facet, referred to as <tt><i>a_codecvt</i></tt> in following sections, obtained "as if" by
+In table 104 the description of <tt>X(q)</tt> contains a special treatment of
+the case <tt>q.size() == 0</tt>.  This is undesirable for 4 reasons:
 </p>
-<blockquote><pre>codecvt&lt;charT,char,typename traits::state_type&gt; <i>a_codecvt</i> =
-  use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
-</pre></blockquote>
-</blockquote>
+
+<ol>
+<li>It replicates the functionality provided by <tt>X()</tt>.</li>
+<li>It leads to the possibility of a collision in the state provided
+    by some other <tt>X(q)</tt> with <tt>q.size() &gt; 0</tt>.</li>
+<li>It is inconsistent with the description of the <tt>X(q)</tt> in
+paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where
+there is no special treatment of <tt>q.size() == 0</tt>.</li>
+<li>The proposed replacement for <tt>seed_seq::randomize</tt> given above
+    allows for the case <tt>q.size() == 0</tt>.</li>
+</ol>
 
 <p>
-<tt>use_facet</tt> returns a <tt>const facet</tt> reference and no facet is
-copyconstructible, so the codecvt construction should fail to compile.
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
 </p>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>.
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
 </p>
 
 
-<p><b>Proposed resolution:</b></p>
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="679"></a>679. resize parameter by value</h3>
+<p><b>Section:</b> 23.2 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-In 27.8.1.1 [filebuf]/5 change the "as if" code
+The C++98 standard specifies that one member function alone of the containers
+passes its parameter (<tt>T</tt>) by value instead of by const reference:
 </p>
 
-<blockquote><pre><ins>const </ins>codecvt&lt;charT,char,typename traits::state_type&gt;<ins>&amp;</ins> <i>a_codecvt</i> =
-  use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
+<blockquote><pre>void resize(size_type sz, T c = T());
 </pre></blockquote>
 
 <p>
-In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
+This fact has been discussed / debated repeatedly over the years, the first time
+being even before C++98 was ratified.  The rationale for passing this parameter by
+value has been:
 </p>
 
 <blockquote>
 <p>
-A local variable <tt><i>punct</i></tt> is initialized via
+So that self referencing statements are guaranteed to work, for example:
 </p>
-<blockquote><pre><ins>const </ins>numpunct&lt;charT&gt;<ins>&amp;</ins> <i>punct</i> = use_facet&lt; numpunct&lt;charT&gt; &gt;(<i>str</i>.getloc() )<ins>;</ins>
+<blockquote><pre>v.resize(v.size() + 1, v[0]);
 </pre></blockquote>
 </blockquote>
 
 <p>
-(Please note also the additional provided trailing semicolon)
+However this rationale is not convincing as the signature for <tt>push_back</tt> is:
 </p>
 
+<blockquote><pre>void push_back(const T&amp; x);
+</pre></blockquote>
 
-
-
-
-
-<hr>
-<h3><a name="644"></a>644. Possible typos in 'function' description</h3>
-<p><b>Section:</b> X [func.wrap.func.undef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-25</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-X [func.wrap.func.undef]
-</p>
-<p>
-The note in paragraph 2 refers to 'undefined void operators', while the 
-section declares a pair of operators returning bool.
+And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append).
+And <tt>push_back</tt> must also work in the self referencing case:
 </p>
 
+<blockquote><pre>v.push_back(v[0]);  // must work
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Change 20.5.15.2 [func.wrap.func]
+The problem with passing <tt>T</tt> by value is that it can be significantly more
+expensive than passing by reference.  The converse is also true, however when it is
+true it is usually far less dramatic (e.g. for scalar types).
 </p>
 
-<blockquote><pre>...
-private:
-   // X [func.wrap.func.undef], undefined operators:
-   template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
-   template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
-};
-</pre></blockquote>
-
 <p>
-Change X [func.wrap.func.undef]
+Even with move semantics available, passing this parameter by value can be expensive.
+Consider for example <tt>vector&lt;vector&lt;int&gt;&gt;</tt>:
 </p>
 
-<blockquote><pre>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;);
+<blockquote><pre>std::vector&lt;int&gt; x(1000);
+std::vector&lt;std::vector&lt;int&gt;&gt; v;
+...
+v.resize(v.size()+1, x);
 </pre></blockquote>
 
+<p>
+In the pass-by-value case, <tt>x</tt> is copied once to the parameter of
+<tt>resize</tt>.  And then internally, since the code can not know at compile
+time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is
+usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place
+within the <tt>vector</tt>.
+</p>
 
+<p>
+With pass-by-const-reference, the <tt>x</tt> in the above example need be copied
+only once.  In this case, <tt>x</tt> has an expensive copy constructor and so any
+copies that can be saved represents a significant savings.
+</p>
 
-
-
-<hr>
-<h3><a name="646"></a>646. const incorrect match_result members</h3>
-<p><b>Section:</b> 28.10.4 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-28.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template
-members format as non-const functions, although they are declared
-as const in 28.10 [re.results]/3.
+If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt>
+as well.  The resize taking a reference parameter has been coded and shipped in the
+CodeWarrior library with no reports of problems which I am aware of.
 </p>
 
 
+
 <p><b>Proposed resolution:</b></p>
 <p>
-Add the missing <tt>const</tt> specifier to both <tt>format</tt> overloads described
-in section 28.10.4 [re.results.form].
+Change 23.2.2 [deque], p2:
 </p>
 
+<blockquote><pre>class deque {
+   ...
+   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
+</pre></blockquote>
 
+<p>
+Change 23.2.2.2 [deque.capacity], p3:
+</p>
 
+<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
+</pre></blockquote>
 
-
-<hr>
-<h3><a name="650"></a>650. regex_token_iterator and const correctness</h3>
-<p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
 <p>
-Both the class definition of regex_token_iterator (28.12.2
-[re.tokiter]/6) and the latter member specifications (28.12.2.2
-[re.tokiter.comp]/1+2) declare both comparison operators as
-non-const functions. Furtheron, both dereference operators are
-unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6
-as well as in (28.12.2.3 [re.tokiter.deref]/1+2).
+Change 23.2.4 [list], p2:
 </p>
 
+<blockquote><pre>class list {
+   ...
+   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-1) In (28.12.2 [re.tokiter]/6) change the current declarations
+Change 23.2.4.2 [list.capacity], p3:
 </p>
 
-<blockquote><pre>bool operator==(const regex_token_iterator&amp;) <ins>const</ins>;
-bool operator!=(const regex_token_iterator&amp;) <ins>const</ins>;
-const value_type&amp; operator*() <ins>const</ins>;
-const value_type* operator-&gt;() <ins>const</ins>;
+<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
 </pre></blockquote>
 
 <p>
-2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
+Change 23.2.6 [vector], p2:
 </p>
 
-<blockquote><pre>bool operator==(const regex_token_iterator&amp; right) <ins>const</ins>;
-bool operator!=(const regex_token_iterator&amp; right) <ins>const</ins>;
+<blockquote><pre>class vector {
+   ...
+   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
 </pre></blockquote>
 
 <p>
-3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
+Change 23.2.6.2 [vector.capacity], p11:
 </p>
 
-<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
-const value_type* operator-&gt;() <ins>const</ins>;
+<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
 </pre></blockquote>
 
 
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
-is to adopt the proposed wording in this issue).
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
 
 
 
 
 <hr>
-<h3><a name="651"></a>651. Missing preconditions for regex_token_iterator c'tors</h3>
-<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p>
+<h3><a name="680"></a>680. move_iterator operator-&gt; return</h3>
+<p><b>Section:</b> 24.4.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
-the effects of the three non-default constructors of class
-template regex_token_iterator but is does not clarify which values
-are legal values for submatch/submatches. This becomes
-an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
-the notion of a "current match" by saying:
+<tt>move_iterator</tt>'s <tt>operator-&gt;</tt> return type <tt>pointer</tt>
+does not consistently match the type which is returned in the description
+in 24.4.3.3.5 [move.iter.op.ref].
 </p>
 
-<blockquote><p>
-The <i>current match</i> is <tt>(*position).prefix()</tt> if <tt>subs[N]
-== -1</tt>, or <tt>(*position)[subs[N]]</tt> for any other value of
-<tt>subs[N]</tt>.
-</p></blockquote>
+<blockquote><pre>template &lt;class Iterator&gt;
+class move_iterator {
+public:
+    ...
+    typedef typename iterator_traits&lt;Iterator&gt;::pointer pointer;
+    ...
+    pointer operator-&gt;() const {return current;}
+    ...
+private: 
+    Iterator current; // exposition only
+};
+</pre></blockquote>
+
 
 <p>
-It's not clear to me, whether other negative values except -1
-are legal arguments or not - it seems they are not.
+There are two possible fixes.
 </p>
 
+<ol>
+<li><tt>pointer operator-&gt;() const {return &amp;*current;}</tt></li>
+<li><tt>typedef Iterator pointer;</tt></li>
+</ol>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Add the following precondition paragraph just before the current
-28.12.2.1 [re.tokiter.cnstr]/2:
+The first solution is the one chosen by <tt>reverse_iterator</tt>.  A potential
+disadvantage of this is it may not work well with iterators which return a
+proxy on dereference and that proxy has overloaded <tt>operator&amp;()</tt>.  Proxy
+references often need to overloaad <tt>operator&amp;()</tt> to return a proxy
+pointer.  That proxy pointer may or may not be the same type as the iterator's
+<tt>pointer</tt> type.
 </p>
 
-<blockquote><p>
-<i>Requires:</i> Each of the initialization values of <tt>subs</tt> must be <tt>&gt;= -1</tt>.
-</p></blockquote>
+<p>
+By simply returning the <tt>Iterator</tt> and taking advantage of the fact that
+the language forwards calls to <tt>operator-&gt;</tt> automatically until it
+finds a non-class type, the second solution avoids the issue of an overloaded
+<tt>operator&amp;()</tt> entirely.
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 24.4.3.1 [move.iterator]:
+</p>
 
+<blockquote><pre>typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
+</pre></blockquote>
 
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
-is to adopt the proposed wording in this issue).
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="652"></a>652. regex_iterator and const correctness</h3>
-<p><b>Section:</b> 28.12.1 [re.regiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
+<h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3>
+<p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>Both the class definition of regex_iterator (28.12.1 [re.regiter]/1)
-and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2)
-declare both comparison operators as
-non-const functions. Furtheron, both dereference operators are
-unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
-as well as in (28.12.1.3 [re.regiter.deref]/1+2).
+<p>
+In 28.9.2 [re.submatch.op] of N2284, 
+operator functions numbered 31-42 seem impossible to compare. &nbsp;E.g.: 
 </p>
 
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+<pre>template &lt;class BiIter&gt;
+&nbsp; &nbsp; bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const sub_match&lt;BiIter&gt;&amp; rhs);
+</pre>
+<blockquote>
 <p>
-1) In (28.12.1 [re.regiter]/1) change the current declarations
+-31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
 </p>
-
-<blockquote><pre>bool operator==(const regex_iterator&amp;) <ins>const</ins>;
-bool operator!=(const regex_iterator&amp;) <ins>const</ins>;
-const value_type&amp; operator*() <ins>const</ins>;
-const value_type* operator-&gt;() <ins>const</ins>;
-</pre></blockquote>
+</blockquote>
+</blockquote>
 
 <p>
-2) In 28.12.1.3 [re.regiter.deref] change the following declarations
+When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits&lt;BiIter&gt;::value_type</tt> would be 
+<tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object 
+of <tt>std::basic_string&lt;char&gt;</tt>. &nbsp;However, the behaviour of comparison between 
+these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
+&nbsp;This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>. 
 </p>
 
-<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
-const value_type* operator-&gt;() <ins>const</ins>;
-</pre></blockquote>
 
+<p><b>Proposed resolution:</b></p>
 <p>
-3) In 28.12.1.2 [re.regiter.comp] change the following declarations
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
 </p>
 
-<blockquote><pre>bool operator==(const regex_iterator&amp; right) <ins>const</ins>;
-bool operator!=(const regex_iterator&amp; right) <ins>const</ins>;
-</pre></blockquote>
-
 
 <p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
-is to adopt the proposed wording in this issue).
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
 ]</i></p>
 
@@ -23690,128 +25789,59 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 <hr>
-<h3><a name="654"></a>654. Missing IO roundtrip for random number engines</h3>
-<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
+<h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
+<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-03</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify
-the IO insertion and extraction semantic of random
-number engines. It can be shown, v.i., that the specification
-of the extractor cannot guarantee to fulfill the requirement
-from para 5:
-</p>
-
-<blockquote><p>
-If a textual representation written via os &lt;&lt; x was
-subsequently read via is &gt;&gt; v, then x == v provided that
-there have been no intervening invocations of x or of v.
-</p></blockquote>
-
-<p>
-The problem is, that the extraction process described in
-table 98 misses to specify that it will initially set the
-if.fmtflags to ios_base::dec, see table 104:
+Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this 
+constructor: 
 </p>
-
-<blockquote><p>
-dec: converts integer input or generates integer output
-in decimal base
-</p></blockquote>
+<blockquote><pre>template &lt;class InputIterator&gt;
+&nbsp; &nbsp; &nbsp;basic_regex(InputIterator first, InputIterator last, 
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
+</pre></blockquote>
 
 <p>
-Proof: The following small program demonstrates the violation
-of requirements (exception safety not fulfilled):
+In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
 </p>
 
-<blockquote><pre>#include &lt;cassert&gt;
-#include &lt;ostream&gt;
-#include &lt;iostream&gt;
-#include &lt;iomanip&gt;
-#include &lt;sstream&gt;
-
-class RanNumEngine {
-  int state;
-public:
-  RanNumEngine() : state(42) {}
-
-  bool operator==(RanNumEngine other) const {
-	  return state == other.state;
-  }
-
-  template &lt;typename Ch, typename Tr&gt;
-  friend std::basic_ostream&lt;Ch, Tr&gt;&amp; operator&lt;&lt;(std::basic_ostream&lt;Ch, Tr&gt;&amp; os, RanNumEngine engine) {
-	Ch old = os.fill(os.widen(' ')); // Sets space character
-	std::ios_base::fmtflags f = os.flags();
-	os &lt;&lt; std::dec &lt;&lt; std::left &lt;&lt; engine.state; // Adds ios_base::dec|ios_base::left
-	os.fill(old); // Undo
-	os.flags(f);
-	return os;
-  }
-
-  template &lt;typename Ch, typename Tr&gt;
-  friend std::basic_istream&lt;Ch, Tr&gt;&amp; operator&gt;&gt;(std::basic_istream&lt;Ch, Tr&gt;&amp; is, RanNumEngine&amp; engine) {
-       // Uncomment only for the fix.
-
-	//std::ios_base::fmtflags f = is.flags();
-	//is &gt;&gt; std::dec;
-	is &gt;&gt; engine.state;
-	//is.flags(f);
-	return is;
-  }
-};
-
-int main() {
-	std::stringstream s;
-	s &lt;&lt; std::setfill('#'); // No problem
-        s &lt;&lt; std::oct; // Yikes!
-        // Here starts para 5 requirements:
-	RanNumEngine x;
-	s &lt;&lt; x;
-	RanNumEngine v;
-	s &gt;&gt; v;
-	assert(x == v); // Fails: 42 == 34
-}
+<blockquote><pre>template &lt;class ForwardIterator&gt;
+&nbsp; &nbsp; &nbsp;basic_regex(ForwardIterator first, ForwardIterator last, 
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
 </pre></blockquote>
 
 <p>
-A second, minor issue seems to be, that the insertion
-description from table 98 unnecessarily requires the
-addition of ios_base::fixed (which only influences floating-point
-numbers). Its not entirely clear to me whether the proposed
-standard does require that the state of random number engines
-is stored in integral types or not, but I have the impression
-that this is the indent, see e.g. p. 3
+<tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong.
 </p>
 
-<blockquote><p>
-The specification of each random number engine defines the
-size of its state in multiples of the size of its result_type.
-</p></blockquote>
+<p><i>[
+John adds:
+]</i></p>
 
+
+<blockquote>
 <p>
-If other types than integrals are supported, then I wonder why
-no requirements are specified for the precision of the stream.
+I think either could be implemented? &nbsp;Although an input iterator would 
+probably require an internal copy of the string being made.
 </p>
-
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
+I have no strong feelings either way, although I think my original intent 
+was <tt>InputIterator</tt>. 
 </p>
+</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
 Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
 </p>
 
 
 <p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
 ]</i></p>
 
@@ -23820,250 +25850,355 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 <hr>
-<h3><a name="655"></a>655. Signature of generate_canonical not useful</h3>
-<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
+<h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3>
+<p><b>Section:</b> 20.6.12.2.1 [util.smartptr.shared.const], 20.6.12.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-In 26.4.2 [rand.synopsis] we have the declaration
+Since all conversions from <tt>shared_ptr&lt;T&gt;</tt> to <tt>shared_ptr&lt;U&gt;</tt> have the same
+rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user
+code that works with raw pointers fails with <tt>shared_ptr</tt>:
 </p>
 
-<blockquote><pre>template&lt;class RealType, class UniformRandomNumberGenerator,
-  size_t bits&gt;
-result_type generate_canonical(UniformRandomNumberGenerator&amp; g);
+<blockquote><pre>void f( shared_ptr&lt;void&gt; );
+void f( shared_ptr&lt;int&gt; );
+
+int main()
+{
+&nbsp;&nbsp;f( shared_ptr&lt;double&gt;() ); // ambiguous
+}
 </pre></blockquote>
 
 <p>
-Besides the "result_type" issue (already recognized by Bo Persson
-at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
-the template parameter order is not reasonably choosen: Obviously
-one always needs to specify all three parameters, although usually
-only two are required, namely the result type RealType and the
-wanted bits, because UniformRandomNumberGenerator can usually
-be deduced.
+Now that we officially have <tt>enable_if</tt>, we can constrain the constructor
+and the corresponding assignment operator to only participate in the
+overload resolution when the pointer types are compatible.
 </p>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
+In 20.6.12.2.1 [util.smartptr.shared.const], change:
 </p>
 
+<blockquote><p>
+-14- <i>Requires:</i> <del>For the second constructor</del> <ins>The
+second constructor shall not participate in the overload resolution
+unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible
+to <tt>T*</tt>.
+</p></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+In 20.6.12.3.1 [util.smartptr.weak.const], change:
 </p>
 
+<blockquote>
+<pre><del>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</del>
+<del>weak_ptr(weak_ptr const&amp; r);</del>
+<del>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</del>
+<ins>weak_ptr(weak_ptr const&amp; r);</ins>
+<ins>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</ins>
+<ins>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</ins>
+</pre>
+<blockquote><p>
+-4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and
+third constructors<del>,</del> <ins>shall not participate in the
+overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del>
+<ins>is implicitly</ins> convertible to <tt>T*</tt>.
+</p></blockquote>
+</blockquote>
 
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="660"></a>660. Missing Bitwise Operations</h3>
-<p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-04-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
+<h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3>
+<p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
-<p>Section 20.5 [function.objects] provides <span id="st" name="st" class="st">function</span>
-<span id="st" name="st" class="st">objects</span> for some unary and binary 
-operations, but others are missing. In a LWG reflector discussion, beginning 
-with c++std-lib-18078, pros and cons of adding some of the missing operations 
-were discussed. Bjarne Stroustrup commented "Why standardize what isn't used? 
-Yes, I see the chicken and egg problems here, but it would be nice to see a 
-couple of genuine uses before making additions."</p>
-<p>A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have 
-already added these functions, either publicly or for internal use. For example, 
-Doug Gregor commented: "Boost will also add ... (|, &amp;, ^) in 1.35.0, because we 
-need those <span id="st" name="st" class="st">function</span>
-<span id="st" name="st" class="st">objects</span> to represent various parallel 
-collective operations (reductions, prefix reductions, etc.) in the new Message 
-Passing Interface (MPI) library."</p>
-<p>Because the bitwise operators have the strongest use cases, the proposed 
-resolution is limited to them.</p>
+<p>
+The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
+motivation behind this is the safety problem with respect to rvalues,
+which is addressed by the proposed resolution of the previous issue.
+Therefore we should consider relaxing the requirements on the
+constructor since requests for the implicit conversion keep resurfacing.
+</p>
+<p>
+Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+</p>
 
 
 <p><b>Proposed resolution:</b></p>
-<p>To 20.5 [function.objects], Function objects, paragraph 2, add to the header 
-&lt;functional&gt; synopsis:</p>
-<blockquote>
-  <pre>template &lt;class T&gt; struct bit_and;
-template &lt;class T&gt; struct bit_or;
-template &lt;class T&gt; struct bit_xor;</pre>
-</blockquote>
-<p>At a location in clause 20 to be determined by the Project Editor, add:</p>
-<blockquote>
-  <p>The library provides basic function object classes for all of the bitwise 
-  operators in the language ([expr.bit.and], [expr.or], [exp.xor]).</p>
-  <pre>template &lt;class T&gt; struct bit_and : binary_function&lt;T,T,T&gt; {
-  T operator()(const T&amp; x , const T&amp; y ) const;
-};</pre>
-  <blockquote>
-    <p><code>operator()</code> returns<code> x &amp; y</code> .</p>
-  </blockquote>
-  <pre>template &lt;class T&gt; struct bit_or : binary_function&lt;T,T,T&gt; {
-  T operator()(const T&amp; x , const T&amp; y ) const;
-};</pre>
-  <blockquote>
-    <p><code>operator()</code> returns <code>x | y</code> .</p>
-  </blockquote>
-  <pre>template &lt;class T&gt; struct bit_xor : binary_function&lt;T,T,T&gt; {
-  T operator()(const T&amp; x , const T&amp; y ) const;
-};</pre>
-  <blockquote>
-    <p><code>operator()</code> returns <code>x ^ y</code> .</p>
-  </blockquote>
-</blockquote>
+<p>
+Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the
+proposed resolution of the previous issue is accepted, remove the
+<tt>explicit</tt> from the <tt>T&amp;&amp;</tt> constructor as well to keep them in sync.
+</p>
 
 
 
 
 
 <hr>
-<h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.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#Pending%20WP">Pending WP</a> status.</p>
+<h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3>
+<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-<tt>seed_seq::randomize</tt> provides a mechanism for initializing random number
-engines which ideally would yield "distant" states when given "close"
-seeds.  The algorithm for <tt>seed_seq::randomize</tt> given in the current
-Working Draft for C++,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
-(2007-05-08), has 3 weaknesses
+The  <code>bitset</code> class template  provides the  member function
+<code>any()</code> to determine whether an  object of the type has any
+bits  set, and  the member  function <code>none()</code>  to determine
+whether all of an object's  bits are clear. However, the template does
+not   provide  a   corresponding  function   to  discover   whether  a
+<code>bitset</code>  object  has  all  its  bits  set.   While  it  is
+possible,  even easy,  to  obtain this  information  by comparing  the
+result of <code>count()</code>  with the result of <code>size()</code>
+for  equality  (i.e.,  via  <code>b.count()  ==  b.size()</code>)  the
+operation  is   less  efficient   than  a  member   function  designed
+specifically  for that purpose  could be.   (<code>count()</code> must
+count  all non-zero bits  in a  <code>bitset</code> a  word at  a time
+while <code>all()</code> could stop counting as soon as it encountered
+the first word with a zero bit).
 </p>
 
-<ol>
-<li>
-<p> Collisions in state.  Because of the way the state is initialized,
-    seeds of different lengths may result in the same state.  The
-    current version of seed_seq has the following properties:</p>
-<ul>
-<li>  For a given <tt>s &lt;= n</tt>, each of the 2^(32s) seed vectors results in a
-      distinct state.</li>
-</ul>
-<p>
-    The proposed algorithm (below) has the considerably stronger
-    properties:</p>
-<ul>
-<li>   All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s &lt; n</tt>
-      result in distinct states.
-</li>
-<li>  All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in
-      distinct states.
-</li>
-</ul>
-</li>
-<li>
-<p> Poor mixing of <tt>v'</tt>s entropy into the state.  Consider <tt>v.size() == n</tt>
-    and hold <tt>v[n/2]</tt> thru <tt>v[n-1]</tt> fixed while varying <tt>v[0]</tt> thru <tt>v[n/2-1]</tt>,
-    a total of <tt>2^(16n)</tt> possibilities.  Because of the simple recursion
-    used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64
-    possible states.</p>
 
-<p> The proposed algorithm uses a more complex recursion which results
-    in much better mixing.</p>
-</li>
-<li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>.  The proposed
-    algorithm remedies this.
-</li>
-</ol>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add  a declaration of the new  member function <code>all()</code> to the
+defintion of the <code>bitset</code> template in 23.3.5 [template.bitset], p1,
+right above the declaration of <code>any()</code> as shown below:
+</p>
+
+<blockquote><pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
+bool test(size_t pos) const;
+<ins>bool all() const;</ins>
+bool any() const;
+bool none() const;
+</pre></blockquote>
+
 <p>
-The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the
-initialization procedure for the Mersenne Twister by Makoto Matsumoto
-and Takuji Nishimura.  The weakness (2) given above was communicated to
-me by Matsumoto last year.
+Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
 </p>
+<blockquote><p>
+<code>bool all() const;</code>
+</p>
+<blockquote>
+<i>Returns</i>: <code>count() == size()</code>.
+</blockquote>
+</blockquote>
+
 <p>
-The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito,
-a student of Matsumoto, and is given in the implementation of the
-SIMD-oriented Fast Mersenne Twister random number generator SFMT.
-<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a>
-<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/SFMT-src-1.2.tar.gz">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz</a>
+In  addition,   change  the  description   of  <code>any()</code>  and
+<code>none()</code>   for  consistency   with   <code>all()</code>  as
+follows:
+</p>
+<blockquote><p>
+<code>bool any() const;</code>
 </p>
+<blockquote>
 <p>
-See
-Mutsuo Saito,
-An Application of Finite Field: Design and Implementation of 128-bit
-Instruction-Based Fast Pseudorandom Number Generator,
-Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
-<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a>
+<i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code>
+is one</del><ins><code>count() != 0</code></ins>.
 </p>
+</blockquote>
 <p>
-One change has been made here, namely to treat the case of small <tt>n</tt>
-(setting <tt>t = (n-1)/2</tt> for <tt>n &lt; 7</tt>).
+<code>bool none() const;</code>
 </p>
+<blockquote>
 <p>
-Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
-in making this incompatible improvement to it.
+<i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code>
+is one</del><ins><code>count() == 0</code></ins>.
 </p>
+</blockquote>
+</blockquote>
+
+
+
+
 
+<hr>
+<h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></h3>
+<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
+Objects of the  <code>bitset</code> class template specializations can
+be constructed from  and explicitly converted to values  of the widest
+C++ integer  type, <code>unsigned long</code>.   With the introduction
+of  <code>long long</code> into  the language  the template  should be
+enhanced to make it possible  to interoperate with values of this type
+as well, or  perhaps <code>uintmax_t</code>.  See c++std-lib-18274 for
+a brief discussion in support of this change.
 </p>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+For simplicity,  instead of  adding overloads for  <code>unsigned long
+long</code> and dealing with possible ambiguities in the spec, replace
+the <code>bitset</code> ctor  that takes an <code>unsigned long</code>
+argument  with  one  taking  <code>unsigned long  long</code>  in  the
+definition  of the  template as  shown below.   (The  standard permits
+implementations  to add  overloads on  other integer  types  or employ
+template tricks to  achieve the same effect provided  they don't cause
+ambiguities or changes in behavior.)
 </p>
+<blockquote>
+<pre>// [bitset.cons] constructors:
+bitset();
+bitset(unsigned <ins>long</ins> long val);
+template&lt;class charT, class traits, class Allocator&gt;
+explicit bitset(
+                const basic_string&lt;charT,traits,Allocator&gt;&amp; str,
+                typename basic_string&lt;charT,traits,Allocator&gt;::size_type pos = 0,
+                typename basic_string&lt;charT,traits,Allocator&gt;::size_type n =
+                    basic_string&lt;charT,traits,Allocator&gt;::npos);
+</pre>
+</blockquote>
+<p>
+Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+</p>
+<blockquote>
+<p>
+<code>bitset(unsigned <ins>long</ins> long val);</code>
+</p>
+<blockquote>
+<i>Effects</i>:  Constructs   an  object  of   class  bitset&lt;N&gt;,
+initializing  the  first <code><i>M</i></code>  bit  positions to  the
+corresponding      bit     values      in     <code><i>val</i></code>.
+<code><i>M</i></code> is the  smaller of <code><i>N</i></code> and the
+number of bits in  the value representation (section [basic.types]) of
+<code>unsigned  <ins> long</ins> long</code>.   If  <code><i>M</i> &lt;
+<i>N</i></code>  <ins>is  <code>true</code></ins>,  the remaining  bit
+positions are initialized to zero.
+</blockquote>
+</blockquote>
 
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
+<p>
+Additionally, introduce a new member function <code>to_ullong()</code>
+to make  it possible to  convert <code>bitset</code> to values  of the
+new  type. Add  the following  declaration  to the  definition of  the
+template, immediate  after the declaration  of <code>to_ulong()</code>
+in 23.3.5 [template.bitset], p1, as shown below:
+</p>
+<blockquote>
+<pre>// element access:
+bool operator[](size_t pos) const; // for b[i];
+reference operator[](size_t pos); // for b[i];
+unsigned long to_ulong() const;
+<ins>unsigned long long to_ullong() const;</ins>
+template &lt;class charT, class traits, class Allocator&gt;
+basic_string&lt;charT, traits, Allocator&gt; to_string() const;
+</pre>
+</blockquote>
+<p>
+And add a description of  the new member function to 23.3.5.2 [bitset.members],
+below  the  description of  the  existing <code>to_ulong()</code>  (if
+possible), with the following text:
+</p>
+<blockquote>
+<p>
+<code>unsigned long long to_ullong() const;</code>
+</p>
+<blockquote>
+<i>Throws</i>:  <code>overflow_error</code>   if  the  integral  value
+<code><i>x</i></code> corresponding to  the bits in <code>*this</code>
+cannot be represented as type <code>unsigned long long</code>.
+</blockquote>
+<blockquote>
+<i>Returns:</i> <code><i>x</i></code>.
+</blockquote>
+</blockquote>
 
 
 
 
 
 <hr>
-<h3><a name="678"></a>678. Changes for [rand.req.eng]</h3>
-<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
+<h3><a name="695"></a>695. ctype&lt;char&gt;::classic_table() not accessible</h3>
+<p><b>Section:</b> 22.2.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
+The   <code>ctype&lt;char&gt;::classic_table()</code>   static  member
+function    returns    a    pointer    to   an    array    of    const
+<code>ctype_base::mask</code>    objects    (enums)   that    contains
+<code>ctype&lt;char&gt;::table_size</code>    elements.    The   table
+describes the properties of the character set in the "C" locale (i.e.,
+whether a  character at an index  given by its value  is alpha, digit,
+punct,   etc.),   and   is    typically   used   to   initialize   the
+<code>ctype&lt;char&gt;</code>  facet in the  classic "C"  locale (the
+protected      <code>ctype&lt;char&gt;</code>      member     function
+<code>table()</code>    then    returns     the    same    value    as
+<code>classic_table()</code>).
 </p>
-
 <p>
-This change follows naturally from the proposed change to
-<tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>.
+However, while <code>ctype&lt;char&gt;::table_size</code> (the size of
+the   table)    is   a   public    static   const   member    of   the
+<code>ctype&lt;char&gt;</code>           specialization,           the
+<code>classic_table()</code> static member function is protected. That
+makes getting at the classic  data less than convenient (i.e., one has
+to create  a whole derived class just  to get at the  masks array). It
+makes  little sense  to expose  the size  of the  table in  the public
+interface while making the table itself protected, especially when the
+table is a constant object.
+</p>
+<p>
+The  same argument  can be  made for  the non-static  protected member
+function <code>table()</code>.
 </p>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-In table 104 the description of <tt>X(q)</tt> contains a special treatment of
-the case <tt>q.size() == 0</tt>.  This is undesirable for 4 reasons:
+Make     the    <code>ctype&lt;char&gt;::classic_table()</code>    and
+<code>ctype&lt;char&gt;::table()</code>  member  functions  public  by
+moving their declarations into the public section of the definition of
+specialization in 22.2.1.3 [facet.ctype.special] as shown below:
 </p>
+<blockquote>
+<pre>  static locale::id id;
+  static const size_t table_size = IMPLEMENTATION_DEFINED;
+<del>protected:</del>
+  const mask* table() const throw();
+  static const mask* classic_table() throw();
+<ins>protected:</ins>
 
-<ol>
-<li>It replicates the functionality provided by <tt>X()</tt>.</li>
-<li>It leads to the possibility of a collision in the state provided
-    by some other <tt>X(q)</tt> with <tt>q.size() &gt; 0</tt>.</li>
-<li>It is inconsistent with the description of the <tt>X(q)</tt> in
-paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where
-there is no special treatment of <tt>q.size() == 0</tt>.</li>
-<li>The proposed replacement for <tt>seed_seq::randomize</tt> given above
-    allows for the case <tt>q.size() == 0</tt>.</li>
-</ol>
+~ctype(); // virtual
+virtual char do_toupper(char c) const;
+</pre>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="699"></a>699. N2111 changes min/max</h3>
+<p><b>Section:</b> 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
+changes <tt>min/max</tt> in several places in random from member
+functions to static data members. I believe this introduces
+a needless backward compatibility problem between C++0X and
+TR1. I'd like us to find new names for the static data members,
+or perhaps change <tt>min/max</tt> to <tt>constexpr</tt>s in C++0X.
+</p>
 
 <p>
 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
@@ -24089,149 +26224,171 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 <hr>
-<h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3>
-<p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
+<h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3>
+<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-In 28.9.2 [re.submatch.op] of N2284, 
-operator functions numbered 31-42 seem impossible to compare. &nbsp;E.g.: 
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
+defines struct <tt>identity</tt> in <tt>&lt;utility&gt;</tt> which clashes with
+the traditional definition of struct <tt>identity</tt> in <tt>&lt;functional&gt;</tt>
+(not standard, but a common extension from old STL). Be nice
+if we could avoid this name clash for backward compatibility.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.2.2 [forward]:
 </p>
 
 <blockquote>
-<pre>
-template &lt;class BiIter&gt;
-&nbsp; &nbsp; bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const sub_match&lt;BiIter&gt;&amp; rhs);
+<pre>template &lt;class T&gt; struct identity
+{
+    typedef T type;
+    <ins>const T&amp; operator()(const T&amp; x) const;</ins>
+};
+</pre>
+<blockquote>
+<pre><ins>const T&amp; operator()(const T&amp; x) const;</ins>
 </pre>
 <blockquote>
 <p>
--31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
+<ins><i>Returns:</i> <tt>x</tt>.</ins>
 </p>
 </blockquote>
 </blockquote>
 
-<p>
-When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits&lt;BiIter&gt;::value_type</tt> would be 
-<tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object 
-of <tt>std::basic_string&lt;char&gt;</tt>. &nbsp;However, the behaviour of comparison between 
-these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
-&nbsp;This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>. 
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
-</p>
-
+</blockquote>
 
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
-<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
- <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
+<h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3>
+<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-07-03</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this 
-constructor: 
+<tt>map::at()</tt> need a complexity specification.
 </p>
-<blockquote><pre>template &lt;class InputIterator&gt;
-&nbsp; &nbsp; &nbsp;basic_regex(InputIterator first, InputIterator last, 
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
+Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]:
 </p>
-
-<blockquote><pre>template &lt;class ForwardIterator&gt;
-&nbsp; &nbsp; &nbsp;basic_regex(ForwardIterator first, ForwardIterator last, 
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
-
+<blockquote>
 <p>
-<tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong.
+<i>Complexity:</i> logarithmic.
 </p>
+</blockquote>
 
-<p><i>[
-John adds:
-]</i></p>
 
 
-<blockquote>
+
+
+<hr>
+<h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3>
+<p><b>Section:</b> 20.4.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
 <p>
-I think either could be implemented? &nbsp;Although an input iterator would 
-probably require an internal copy of the string being made.
+The current working draft has a type-trait <tt>decay</tt> in 20.4.7 [meta.trans.other].
 </p>
+
 <p>
-I have no strong feelings either way, although I think my original intent 
-was <tt>InputIterator</tt>. 
+Its use is to turn C++03 pass-by-value parameters into efficient C++0x
+pass-by-rvalue-reference parameters. However, the current definition
+introduces an incompatible change where the cv-qualification of the
+parameter type is retained. The deduced type should loose such
+cv-qualification, as pass-by-value does.
 </p>
-</blockquote>
 
 
 <p><b>Proposed resolution:</b></p>
 <p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
+In 20.4.7 [meta.trans.other] change the last sentence:
 </p>
 
+<blockquote><p>
+Otherwise the  member typedef <tt>type</tt> equals <tt><ins>remove_cv&lt;</ins>U<ins>&gt;::type</ins></tt>.
+</p></blockquote>
+
+<p>
+In 20.3.1.3 [tuple.creation]/1 change:
+</p>
+
+<blockquote><p>
+<del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&amp;</tt> if, for the
+corresponding type <tt>Ti</tt> in <tt>Types</tt>,
+<tt>remove_cv&lt;remove_reference&lt;Ti&gt;::type&gt;::type</tt> equals
+<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
+<tt>decay&lt;Ti&gt;::type</tt>.</del>
+<ins>Let <tt>Ui</tt> be <tt>decay&lt;Ti&gt;::type</tt> for each
+<tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt>
+is <tt>X&amp;</tt> if <tt>Ui</tt> equals
+<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
+<tt>Ui</tt>.</ins>
+</p></blockquote>
 
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
 
 
 
 
 
 <hr>
-<h3><a name="699"></a>699. N2111 changes min/max</h3>
-<p><b>Section:</b> 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
+<h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3>
+<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
 <p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
-changes <tt>min/max</tt> in several places in random from member
-functions to static data members. I believe this introduces
-a needless backward compatibility problem between C++0X and
-TR1. I'd like us to find new names for the static data members,
-or perhaps change <tt>min/max</tt> to <tt>constexpr</tt>s in C++0X.
+The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16
+and <tt>make_tuple()</tt> in 20.3.1.3 [tuple.creation].
+<tt>make_tuple()</tt> detects the presence of
+<tt>reference_wrapper&lt;X&gt;</tt> arguments and "unwraps" the reference in
+such cases. <tt>make_pair()</tt> would OTOH create a
+<tt>reference_wrapper&lt;X&gt;</tt> member. I suggest that the two
+functions are made to behave similar in this respect to minimize
+confusion.
 </p>
 
+
+<p><b>Proposed resolution:</b></p>
 <p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
+In 20.2 [utility] change the synopsis for make_pair() to read
 </p>
 
+<blockquote><pre>template &lt;class T1, class T2&gt;
+  pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>, <del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt; make_pair(T1&amp;&amp;, T2&amp;&amp;);
+</pre></blockquote>
 
-<p><b>Proposed resolution:</b></p>
 <p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
+Then change the 20.2.3 [pairs]/17 to:
 </p>
 
+<blockquote>
+<p>
+<i>Returns:</i> <tt>pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>,<del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt;(forward&lt;T1&gt;(x),forward&lt;T2&gt;(y))</tt> <ins>where <tt>V1</tt> and
+<tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be
+<tt>decay&lt;Ti&gt;::type</tt> for each <tt>Ti</tt>. Then each
+<tt>Vi</tt> is <tt>X&amp;</tt> if <tt>Ui</tt> equals
+<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
+<tt>Ui</tt>.</ins>
+</p>
+</blockquote>
 
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
 
 
 
@@ -24241,6 +26398,7 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 <h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</h3>
 <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
  <b>Submitter:</b> Marc Paterno <b>Date:</b> 2007-08-25</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
 <p><b>Discussion:</b></p>
@@ -24280,5 +26438,4 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
-
 </body></html>
\ No newline at end of file