<table>
<tbody><tr>
<td align="left">Doc. no.</td>
-<td align="left">N2727=08-0237</td>
+<td align="left">N2894=09-0084</td>
</tr>
<tr>
<td align="left">Date:</td>
-<td align="left">2008-08-24</td>
+<td align="left">2009-06-21</td>
</tr>
<tr>
<td align="left">Project:</td>
<td align="left">Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>></td>
</tr>
</tbody></table>
-<h1>C++ Standard Library Active Issues List (Revision R59)</h1>
+<h1>C++ Standard Library Active Issues List (Revision R65)</h1>
- <p>Reference ISO/IEC IS 14882:1998(E)</p>
+ <p>Reference ISO/IEC IS 14882:2003(E)</p>
<p>Also see:</p>
<ul>
<li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
<p>The purpose of this document is to record the status of issues
which have come before the Library Working Group (LWG) of the ANSI
(J16) and ISO (WG21) C++ Standards Committee. Issues represent
- potential defects in the ISO/IEC IS 14882:1998(E) document. Issues
- are not to be used to request new features. </p>
+ potential defects in the ISO/IEC IS 14882:2003(E) document.
+ </p>
<p>This document contains only library issues which are actively being
considered by the Library Working Group. That is, issues which have a
official Defect Report status, other issues will be disposed of in
other ways. See <a href="#Status">Issue Status</a>.</p>
- <p>This document is in an experimental format designed for both
- viewing via a world-wide web browser and hard-copy printing. It
- is available as an HTML file for browsing or PDF file for
- printing.</p>
-
<p>Prior to Revision 14, library issues lists existed in two slightly
different versions; a Committee Version and a Public
Version. Beginning with Revision 14 the two versions were combined
<p>For the most current official version of this document see
<a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
Requests for further information about this document should include
- the document number above, reference ISO/IEC 14882:1998(E), and be
+ the document number above, reference ISO/IEC 14882:2003(E), and be
submitted to Information Technology Industry Council (ITI), 1250 Eye
Street NW, Washington, DC 20005.</p>
<p>Public information as to how to obtain a copy of the C++ Standard,
join the standards committee, submit an issue, or comment on an issue
can be found in the comp.std.c++ FAQ.
- Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c++">news:comp.std.c++</a>.
</p>
- <p>For committee members, files available on the committee's private
- web site include the HTML version of the Standard itself. HTML
- hyperlinks from this issues list to those files will only work for
- committee members who have downloaded them into the same disk
- directory as the issues list files. </p>
<h2>Revision History</h2>
<ul>
+<li>R65:
+2009-06-19 pre-Frankfurt mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>378 open issues, up by 32.</li>
+<li>765 closed issues, up by 0.</li>
+<li>1143 issues total, up by 32.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1143">1143</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1112">1112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>.</li>
+<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</a>.</li>
+<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>.</li>
+<li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#568">568</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#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</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>.</li>
+<li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>.</li>
+<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#988">988</a>.</li>
+<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#884">884</a>.</li>
+<li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.</li>
+<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>.</li>
+<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>.</li>
+<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R64:
+2009-05-01 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>346 open issues, up by 19.</li>
+<li>765 closed issues, up by 0.</li>
+<li>1111 issues total, up by 19.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</a>.</li>
+<li>Changed the following issues from DR to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#406">406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#434">434</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438">438</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#444">444</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#455">455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#469">469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>.</li>
+<li>Changed the following issues from Review to New: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R63:
+2009-03-20 post-Summit mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>327 open issues, up by 96.</li>
+<li>765 closed issues, up by 14.</li>
+<li>1092 issues total, up by 110.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1022">1022</a>.</li>
+<li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1089">1089</a>.</li>
+<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li>
+<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#988">988</a>.</li>
+<li>Changed the following issues from New to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>.</li>
+<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>.</li>
+<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>.</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#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</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#683">683</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
+<li>Changed the following issues from Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
+<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#466">466</a>.</li>
+<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#219">219</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>.</li>
+<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>.</li>
+<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>.</li>
+<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>.</li>
+<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>.</li>
+<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>.</li>
+<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</a>.</li>
+<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R62:
+2009-02-06 pre-Summit mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>231 open issues, up by 44.</li>
+<li>751 closed issues, up by 0.</li>
+<li>982 issues total, up by 44.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R61:
+2008-12-05 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>187 open issues, up by 20.</li>
+<li>751 closed issues, up by 0.</li>
+<li>938 issues total, up by 20.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R60:
+2008-10-03 post-San Francisco mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>167 open issues, down by 25.</li>
+<li>751 closed issues, up by 65.</li>
+<li>918 issues total, up by 40.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#896">896</a>.</li>
+<li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
+<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
+<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</a>.</li>
+<li>Changed the following issues from New to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>.</li>
+<li>Changed the following issues from Ready to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
+<li>Changed the following issues from Review to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>.</li>
+<li>Changed the following issues from WP to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#44">44</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#167">167</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#231">231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#239">239</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#240">240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#282">282</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#291">291</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#300">300</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#305">305</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#310">310</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#315">315</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#316">316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#318">318</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#319">319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#320">320</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#321">321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#324">324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#325">325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#328">328</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#331">331</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#333">333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#337">337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#338">338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#340">340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#341">341</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#345">345</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#346">346</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#349">349</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#352">352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#354">354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#355">355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#358">358</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#359">359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#360">360</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#363">363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#364">364</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#365">365</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#370">370</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#373">373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#375">375</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#379">379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#380">380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#381">381</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#391">391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#395">395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#400">400</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#403">403</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#405">405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#410">410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#411">411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#414">414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#415">415</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#420">420</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#425">425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#426">426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#428">428</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#435">435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#436">436</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#442">442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#443">443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#448">448</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#449">449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
+<li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>.</li>
+<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</a>.</li>
+<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
+<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#872">872</a>.</li>
+<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#742">742</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</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#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
+<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>.</li>
+<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
+<li>Changed the following issues from TC to TC1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1">1</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#7">7</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#11">11</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#13">13</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#14">14</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#15">15</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#16">16</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#18">18</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#20">20</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#21">21</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#27">27</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#30">30</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#32">32</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#34">34</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#35">35</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#36">36</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#37">37</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#39">39</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#40">40</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#42">42</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#46">46</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#47">47</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#48">48</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50">50</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#51">51</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#52">52</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#53">53</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#54">54</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#56">56</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#57">57</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#59">59</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#62">62</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#66">66</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#68">68</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#71">71</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#74">74</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#78">78</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#79">79</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#80">80</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#90">90</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#106">106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#124">124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#125">125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#141">141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#148">148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#150">150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#151">151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#152">152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#154">154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#155">155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#156">156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#158">158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#161">161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#168">168</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#169">169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#174">174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#175">175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#176">176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.</li>
+</ul></li>
+</ul>
+</li>
<li>R59:
2008-08-22 pre-San Francisco mailing.
<ul>
<li>878 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
</ul></li>
</ul>
</li>
<li>869 issues total, up by 8.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
-<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li>
+<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>.</li>
</ul></li>
</ul>
</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li>
+<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li>
-<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
-<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>.</li>
+<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
+<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
+<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>.</li>
+<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
</ul></li>
</ul>
</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-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li>
+<li>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-
defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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><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 New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li>
<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 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-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
-<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
-<li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
+<li>Changed the following issues from 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-
defects.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-
defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
+<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-
defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
+<li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
<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-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>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-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li>
<li>Changed the following issues from 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>
<li>754 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.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-defects.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-closed.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-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
<li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
<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-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
</ul></li>
</ul>
</li>
<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-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>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-
defects.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-closed.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-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 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-
closed.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-active.html#644">644</a>.</li>
<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
<li>696 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
<li>Added the following 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>
<li>676 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
+<li>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-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>.</li>
<li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li>
-<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.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-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 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-
active.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-active.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
<li>656 issues total, up by 37.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
+<li>Changed the following issues from 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-
active.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>
<li>619 issues total, up by 10.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
</ul></li>
</ul>
</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#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-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#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-
closed.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>
+<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-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</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#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li>
</ul></li>
</ul>
</li>
<li>592 issues total, up by 5.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
</ul></li>
</ul>
</li>
<li>587 issues total, up by 13.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li>
<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.</li>
</ul></li>
<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-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-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>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-active.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-
defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
<li>566 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a> ,<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
<li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
</ul></li>
<li>535 issues total.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
</ul></li>
</ul>
</li>
</li>
<li>R38:
2005-07-03 pre-Mont Tremblant mailing.
-Merged open TR1 issues in <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-active.html#522">522</a>.
+Merged open TR1 issues in <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-defects.html#522">522</a>.
Added new issues <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-active.html#523">523</a>
</li>
<li>R37:
</li>
<li>R36:
2005-04 post-Lillehammer mailing. All issues in "ready" status except
-for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues
+for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> were moved to "DR" status, and all issues
previously in "DR" status were moved to "WP".
</li>
<li>R35:
<li>R24:
Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
meeting. All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
-moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
+moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
at the meeting.) Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
</li>
to Ready.
Closed issues
-<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#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
as NAD.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>. Reopened
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>. Reopened
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.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-active.html#128">128</a>,
</li>
<li>R4:
post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
issues corrected. (22 Oct 98)
</li>
<li>R3:
<b>Proposed Resolution</b> is now available for review on an issue
for which the LWG previously reached informal consensus.</p>
- <p><b><a name="Tentatively Ready">Tentatively Ready</a></b> - The issue has
- been reviewed online, but not in a meeting, and some support has been formed
- for the proposed resolution. Tentatively Ready issues may be moved to Ready
- and forwarded to full committee within the same meeting. Unlike Ready issues
- they will be reviewed in subcommittee prior to forwarding to full committee.</p>
-
<p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
that the issue is a defect in the Standard, the <b>Proposed
Resolution</b> is correct, and the issue is ready to forward to the
accords the status of DR to all these Defect Reports regardless of
where they are in that process.</p>
- <p><b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full
+ <p><b><a name="TC1">TC1</a></b> - (Technical Corrigenda 1) - The full
WG21 committee has voted to accept the Defect Report's Proposed
Resolution as a Technical Corrigenda. Action on this issue is thus
complete and no further action is possible under ISO rules.</p>
+ <p><b><a name="CD1">CD1</a></b> - (Committee Draft 2008) - The full
+ WG21 committee has voted to accept the Defect Report's Proposed
+ Resolution into the Fall 2008 Committee Draft.</p>
+
<p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The
LWG has voted to accept the Defect Report's Proposed
Resolution into the Decimal TR. Action on this issue is thus
the full WG21 committee has voted to apply the Defect Report's Proposed
Resolution to the working paper.</p>
+ <p><b>Tentatively</b> - This is a <i>status qualifier</i>. The issue has
+ been reviewed online, or at an unofficial meeting, but not in an official meeting, and some support has been formed
+ for the qualified status. Tentatively qualified issues may be moved to the unqualified status
+ and forwarded to full committee (if Ready) within the same meeting. Unlike Ready issues, Tentatively Ready issues
+ will be reviewed in subcommittee prior to forwarding to full committee. When a status is
+ qualified with Tentatively, the issue is still considered active.</p>
+
<p><b>Pending</b> - This is a <i>status qualifier</i>. When prepended to
a status this indicates the issue has been
processed by the committee, and a decision has been made to move the issue to
<h2>Active Issues</h2>
<hr>
-<h3><a name="23"></a>23. Num_get overflow result</h3>
-<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The current description of numeric input does not account for the
-possibility of overflow. This is an implicit result of changing the
-description to rely on the definition of scanf() (which fails to
-report overflow), and conflicts with the documented behavior of
-traditional and current implementations. </p>
-
-<p>Users expect, when reading a character sequence that results in a
-value unrepresentable in the specified type, to have an error
-reported. The standard as written does not permit this. </p>
-
-<p><b>Further comments from Dietmar:</b></p>
-
-<p>
-I don't feel comfortable with the proposed resolution to issue 23: It
-kind of simplifies the issue to much. Here is what is going on:
-</p>
-
-<p>
-Currently, the behavior of numeric overflow is rather counter intuitive
-and hard to trace, so I will describe it briefly:
-</p>
-
-<ul>
- <li>
- According to 22.2.2.1.2 [facet.num.get.virtuals]
- paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
- return an input error; otherwise a value is converted to the rules
- of <tt>scanf</tt>.
- </li>
- <li>
- <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>.
- </li>
- <li>
- <tt>fscanf()</tt> returns an input failure if during conversion no
- character matching the conversion specification could be extracted
- before reaching EOF. This is the only reason for <tt>fscanf()</tt>
- to fail due to an input error and clearly does not apply to the case
- of overflow.
- </li>
- <li>
- Thus, the conversion is performed according to the rules of
- <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
- <tt>strtol()</tt>, etc. are to be used for the conversion.
- </li>
- <li>
- The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
- many matching characters as there are and on overflow continue to
- consume matching characters but also return a value identical to
- the maximum (or minimum for signed types if there was a leading minus)
- value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
- </li>
- <li>
- Thus, according to the current wording in the standard, overflows
- can be detected! All what is to be done is to check <tt>errno</tt>
- after reading an element and, of course, clearing <tt>errno</tt>
- before trying a conversion. With the current wording, it can be
- detected whether the overflow was due to a positive or negative
- number for signed types.
- </li>
-</ul>
-
-<p><b>Further discussion from Redmond:</b></p>
-
-<p>The basic problem is that we've defined our behavior,
-including our error-reporting behavior, in terms of C90. However,
-C90's method of reporting overflow in scanf is not technically an
-"input error". The <tt>strto_*</tt> functions are more precise.</p>
-
-<p>There was general consensus that <tt>failbit</tt> should be set
-upon overflow. We considered three options based on this:</p>
-<ol>
-<li>Set failbit upon conversion error (including overflow), and
- don't store any value.</li>
-<li>Set failbit upon conversion error, and also set <tt>errno</tt> to
- indicated the precise nature of the error.</li>
-<li>Set failbit upon conversion error. If the error was due to
- overflow, store +-numeric_limits<T>::max() as an
- overflow indication.</li>
-</ol>
-
-<p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
-
-
-<p>Discussed at Lillehammer. General outline of what we want the
- solution to look like: we want to say that overflow is an error, and
- provide a way to distinguish overflow from other kinds of errors.
- Choose candidate field the same way scanf does, but don't describe
- the rest of the process in terms of format. If a finite input field
- is too large (positive or negative) to be represented as a finite
- value, then set failbit and assign the nearest representable value.
- Bill will provide wording.</p>
-
-<p>
-Discussed at Toronto:
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
-is in alignment with the direction we wanted to go with in Lillehammer. Bill
-to work on.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 22.2.2.1.2 [facet.num.get.virtuals], end of p3:
-</p>
-
-<blockquote>
-<p>
-<b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del>
-<ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is
-converted to a numeric value by the rules of one of the functions declared
-in the header <tt><cstdlib></tt>:</ins>
-</p>
-<ul>
-<li>
-<del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is
-converted (according to the rules of <tt>scanf</tt>) to a value of the
-type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is
-stored in <i>err</i>.</del>
-<ins>For a signed integer value, the function <tt>strtoll</tt>.</ins>
-</li>
-<li>
-<del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused
-<tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is
-assigned to <i>err</i>.</del>
-<ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins>
-</li>
-<li>
-<ins>For a floating-point value, the function <tt>strtold</tt>.</ins>
-</li>
-</ul>
-<p>
-<ins>The numeric value to be stored can be one of:</ins>
-</p>
-<ul>
-<li><ins>zero, if the conversion function fails to convert the entire field.
-<tt>ios_base::failbit</tt> is assigned to err.</ins></li>
-<li><ins>the most positive representable value, if the field represents a value
-too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned
-to <i>err</i>.</ins></li>
-<li><ins>the most negative representable value (zero for unsigned integer), if
-the field represents a value too large negative to be represented in <i>val</i>.
-<tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li>
-<li><ins>the converted value, otherwise.</ins></li>
-</ul>
-
-<p><ins>
-The resultant numeric value is stored in <i>val</i>.
-</ins></p>
-</blockquote>
-
-<p>
-Change 22.2.2.1.2 [facet.num.get.virtuals], p6-p7:
-</p>
-
-<blockquote>
-<pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base& <i>str</i>,
- ios_base::iostate& <i>err</i>, bool& <i>val</i>) const;
-</pre>
-<blockquote>
-<p>
--6- <i>Effects:</i> If
-<tt>(<i>str</i>.flags()&ios_base::boolalpha)==0</tt> then input
-proceeds as it would for a <tt>long</tt> except that if a value is being
-stored into <i>val</i>, the value is determined according to the
-following: If the value to be stored is 0 then <tt>false</tt> is stored.
-If the value is 1 then <tt>true</tt> is stored. Otherwise
-<del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is
-stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins>
-</p>
-<p>
--7- Otherwise target sequences are determined "as if" by calling the
-members <tt>falsename()</tt> and <tt>truename()</tt> of the facet
-obtained by <tt>use_facet<numpunct<charT>
->(<i>str</i>.getloc())</tt>. Successive characters in the range
-<tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched
-against corresponding positions in the target sequences only as
-necessary to identify a unique match. The input iterator <i>in</i> is
-compared to <i>end</i> only when necessary to obtain a character. If <del>and
-only if</del> a target sequence is uniquely matched, <i>val</i> is set to the
-corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt>
-is assigned to <i>err</i>.</ins>
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
<h3><a name="96"></a>96. Vector<bool> is not a container</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#Open">Open</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
+<p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">Tentatively NAD Future</a>
+ <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2009-05-25</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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>
<p><b>Discussion:</b></p>
<p><tt>vector<bool></tt> is not a container as its reference and
pointer types are not references and pointers. </p>
<p>We need a paper for the new bit_vector class.</p>
+<p><i>[
+Batavia:
+]</i></p>
+
+<blockquote>
+The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
+from <tt>vector<bool></tt>. Although some of the funcitonality from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
+could well be used in such a template. The concern is easing the API migration for those
+users who want to continue using a bit-packed container. Alan and Beman to work.
+</blockquote>
+
+<p><i>[
+Post Summit Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+<tt>vector<bool></tt> is now a conforming container under the revised terms of C++0x,
+which supports containers of proxies.
+</p>
+<p>
+Recommend NAD.
+</p>
+<p>
+Two issues remain:
+</p>
+<p>
+i/ premature optimization in the specification.
+There is still some sentiment that deprecation is the correct way to go,
+although it is still not clear what it would mean to deprecate a single
+specialization of a template.
+</p>
+<p>
+Recommend: Create a new issue for the discussion, leave as Open.
+</p>
+<p>
+ii/ Request for a new bitvector class to guarantee the optimization, perhaps
+with a better tuned interface.
+</p>
+<p>
+This is a clear extension request that may be handled via a future TR.
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+<blockquote>
+We note that most of this issue has become moot over time,
+and agree with Alisdair's recommendations.
+Move to NAD Future for reconsideration of part (ii).
+</blockquote>
<p><b>Proposed resolution:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
</p>
+
+
+
+
+
+<hr>
+<h3><a name="111"></a>111. istreambuf_iterator::equal overspecified, inefficient</h3>
+<p><b>Section:</b> 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-10-15 <b>Last modified:</b> 2009-03-13</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istreambuf.iterator::equal">active issues</a> in [istreambuf.iterator::equal].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator::equal">issues</a> in [istreambuf.iterator::equal].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>The member istreambuf_iterator<>::equal is specified to be
+unnecessarily inefficient. While this does not affect the efficiency
+of conforming implementations of iostreams, because they can
+"reach into" the iterators and bypass this function, it does
+affect users who use istreambuf_iterators. </p>
+
+<p>The inefficiency results from a too-scrupulous definition, which
+requires a "true" result if neither iterator is at eof. In
+practice these iterators can only usefully be compared with the
+"eof" value, so the extra test implied provides no benefit,
+but slows down users' code. </p>
+
+<p>The solution is to weaken the requirement on the function to return
+true only if both iterators are at eof. </p>
+
<p><i>[
-Batavia: The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
-from <tt>vector<bool></tt>. Although some of the funcitonality from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
-could well be used in such a template. The concern is easing the API migration for those
-users who want to continue using a bit-packed container. Alan and Beman to work.
+Summit:
+]</i></p>
+
+
+<blockquote>
+Reopened by Alisdair.
+</blockquote>
+
+<p><i>[
+Post Summit Daniel adds:
]</i></p>
+<blockquote>
+<p>
+Recommend NAD. The proposed wording would violate the axioms of
+concept requirement <tt>EqualityComparable</tt> axioms as part of concept <tt>InputIterator</tt>
+and more specifically it would violate the explicit wording of
+24.2.2 [input.iterators]/7:
+</p>
+
+<blockquote>
+If two iterators <tt>a</tt> and <tt>b</tt> of the same type are equal, then either <tt>a</tt>
+and <tt>b</tt> are both
+dereferenceable or else neither is dereferenceable.
+</blockquote>
+
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>Replace 24.6.3.5 [istreambuf.iterator::equal],
+paragraph 1, </p>
+
+<blockquote>
+ <p>-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at
+ end-of-stream, regardless of what streambuf object they use. </p>
+</blockquote>
+
+<p>with</p>
+
+<blockquote>
+ <p>-1- Returns: true if and only if both iterators are at
+ end-of-stream, regardless of what streambuf object they use. </p>
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>It is not clear that this is a genuine defect. Additionally, the
+LWG was reluctant to make a change that would result in
+operator== not being a equivalence relation. One consequence of
+this change is that an algorithm that's passed the range [i, i)
+would no longer treat it as an empty range.</p>
+
<hr>
<h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string 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>Section:</b> 27.
8 [string.streams], 27.9 [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>Opened:</b> 1999-02-22 <b>Last modified:</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#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><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>
+qualified as const to 27.6.2 [streambuf]:</p>
<p> <tt>openmode mode() const</tt>;</p>
<hr>
-<h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</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#Ready">Ready</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1999-07-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="138"></a>138. Class ctype_byname<char> redundant and misleading</h3>
+<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <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>Opened:</b> 1999-03-18 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
+<p><b>View all 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>Section 22.4.1.4 [locale.codecvt] specifies that
+ctype_byname<char> must be a specialization of the ctype_byname
+template.</p>
+
+<p>It is common practice in the standard that specializations of class templates are only
+mentioned where the interface of the specialization deviates from the interface of the
+template that it is a specialization of. Otherwise, the fact whether or not a required
+instantiation is an actual instantiation or a specialization is left open as an
+implementation detail. </p>
+
+<p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The
+fact, that ctype_byname<char> is specified as a specialization suggests that there
+must be something "special" about it, but it has the exact same interface as the
+ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best
+redundant, at worst misleading - unless I am missing anything. </p>
+
+<p>Naturally, an implementation will most likely implement ctype_byname<char> as a
+specialization, because the base class ctype<char> is a specialization with an
+interface different from the ctype template, but that's an implementation detail and need
+not be mentioned in the standard. </p>
<p><i>[
-post Bellevue, Alisdair adds:
+Summit:
]</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>
+Reopened by Alisdair.
</blockquote>
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-<blockquote>
-<p>
-This was a fix that was intended for all standard library containers,
-and has been done for other containers, but string was missed.
-</p>
-<p>
-The wording updated.
-</p>
-<p>
-We did not make the change in <tt>replace</tt>, because this change would affect
-the implementation because the string may be written into. This is an
-issue that should be taken up by concepts.
-</p>
-<p>
-We note that the supplied wording addresses the initializer list provided in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2679.pdf">N2679</a>.
-</p>
-</blockquote>
+<p><b>Rationale:</b></p>
+<p> The standard as written is mildly misleading, but the correct fix
+is to deal with the underlying problem in the ctype_byname base class,
+not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Update the following signature in the <tt>basic_string</tt> class template definition in
-21.3 [basic.string], p5:
-</p>
-<blockquote><pre>namespace std {
- template<class charT, class traits = char_traits<charT>,
- class Allocator = allocator<charT> >
- class basic_string {
- ...
+<hr>
+<h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-06-28 <b>Last modified:</b> 2009-05-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>Suppose that c and c1 are sequential containers and i is an
+iterator that refers to an element of c. Then I can insert a copy of
+c1's elements into c ahead of element i by executing </p>
- iterator insert(<ins>const_</ins>iterator p, charT c);
- void insert(<ins>const_</ins>iterator p, size_type n, charT c);
- template<class InputIterator>
- void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
- void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list<charT>);
+<blockquote>
- ...
+<pre>c.insert(i, c1.begin(), c1.end());</pre>
- iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
- iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
+</blockquote>
- ...
+<p>If c is a vector, it is fairly easy for me to find out where the
+newly inserted elements are, even though i is now invalid: </p>
- };
-}
-</pre></blockquote>
+<blockquote>
-<p>
-Update the following signatures in 21.3.6.4 [string::insert]:
-</p>
+<pre>size_t i_loc = i - c.begin();
+c.insert(i, c1.begin(), c1.end());</pre>
-<blockquote><pre>iterator insert(<ins>const_</ins>iterator p, charT c);
-void insert(<ins>const_</ins>iterator p, size_type n, charT c);
-template<class InputIterator>
- void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
-void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list<charT>);
-</pre></blockquote>
+</blockquote>
-<p>
-Update the following signatures in 21.3.6.5 [string::erase]:
-</p>
+<p>and now the first inserted element is at c.begin()+i_loc and one
+past the last is at c.begin()+i_loc+c1.size().<br>
+<br>
+But what if c is a list? I can still find the location of one past the
+last inserted element, because i is still valid. To find the location
+of the first inserted element, though, I must execute something like </p>
-<blockquote><pre>iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
-iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
-</pre></blockquote>
+<blockquote>
+<pre>for (size_t n = c1.size(); n; --n)
+ --i;</pre>
+</blockquote>
-<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>
+<p>because i is now no longer a random-access iterator.<br>
+<br>
+Alternatively, I might write something like </p>
+<blockquote>
+<pre>bool first = i == c.begin();
+list<T>::iterator j = i;
+if (!first) --j;
+c.insert(i, c1.begin(), c1.end());
+if (first)
+ j = c.begin();
+else
+ ++j;</pre>
+</blockquote>
-<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 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>
+<p>which, although wretched, requires less overhead.<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>
+But I think the right solution is to change the definition of insert
+so that instead of returning void, it returns an iterator that refers
+to the first element inserted, if any, and otherwise is a copy of its
+first argument. </p>
<p><i>[
-post Bellevue: Alisdair requested to re-Open.
+Summit:
]</i></p>
+<blockquote>
+Reopened by Alisdair.
+</blockquote>
-
-<p><b>Rationale:</b></p>
-<p>Although perhaps an unfortunate design decision, the omission is not a defect
-in the current standard. A future standard may wish to consider additional
-function objects.</p>
-
+<p><i>[
+Post Summit Alisdair adds:
+]</i></p>
+<blockquote>
+<p>
+In addition to the original rationale for C++03, this change also gives a
+consistent interface for all container insert operations i.e. they all
+return an iterator to the (first) inserted item.
+</p>
-<hr>
-<h3><a name="255"></a>255. Why do <tt>basic_streambuf<>::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>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
-<p><b>View all 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 basic_streambuf members gbump() and pbump() are specified to take an
-int argument. This requirement prevents the functions from effectively
-manipulating buffers larger than std::numeric_limits<int>::max()
-characters. It also makes the common use case for these functions
-somewhat difficult as many compilers will issue a warning when an
-argument of type larger than int (such as ptrdiff_t on LLP64
-architectures) is passed to either of the function. Since it's often the
-result of the subtraction of two pointers that is passed to the
-functions, a cast is necessary to silence such warnings. Finally, the
-usage of a native type in the functions signatures is inconsistent with
-other member functions (such as sgetn() and sputn()) that manipulate the
-underlying character buffer. Those functions take a streamsize argument.
+Proposed wording provided.
</p>
+</blockquote>
+
<p><b>Proposed resolution:</b></p>
<p>
-Change the signatures of these functions in the synopsis of template
-class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
-and 27.5.2.3.2, p4) to take a streamsize argument.
-</p>
+<sef ref="[sequence.reqmts]"> Table 83
+change return type from <tt>void</tt> to <tt>iterator</tt> for the following rows:
+</sef></p>
+
+<blockquote>
+<table border="1">
+<caption>Table 83 -- Sequence container requirements (in addition to container)</caption>
+<tbody><tr>
+<th>Expression</th>
+<th>Return type</th>
+<th>Assertion/note pre-/post-condition</th>
+</tr>
+<tr>
+<td>
+<tt>a.insert(p,n,t)</tt>
+</td>
+<td>
+<tt><del>void</del> <ins>iterator</ins></tt>
+</td>
+<td>
+Inserts <tt>n</tt> copies of <tt>t</tt> before <tt>p</tt>.
+</td>
+</tr>
+
+<tr>
+<td>
+<tt>a.insert(p,i,j)</tt>
+</td>
+<td>
+<tt><del>void</del> <ins>iterator</ins></tt>
+</td>
+<td>
+Each iterator in the range <tt>[i,j)</tt> shall be
+dereferenced exactly once.
+pre: <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>.
+Inserts copies of elements in <tt>[i, j)</tt> before <tt>p</tt>
+</td>
+</tr>
+
+<tr>
+<td>
+<tt>a.insert(p,il)</tt>
+</td>
+<td>
+<tt><del>void</del> <ins>iterator</ins></tt>
+</td>
+<td>
+<tt>a.insert(p, il.begin(), il.end())</tt>.
+</td>
+</tr>
+</tbody></table>
+</blockquote>
<p>
-Although this change has the potential of changing the ABI of the
-library, the change will affect only platforms where int is different
-than the definition of streamsize. However, since both functions are
-typically inline (they are on all known implementations), even on such
-platforms the change will not affect any user code unless it explicitly
-relies on the existing type of the functions (e.g., by taking their
-address). Such a possibility is IMO quite remote.
+Add after p6 23.2.3 [sequence.reqmts]:
</p>
+<blockquote>
+<p>-6- ...</p>
+
+<p><ins>
+The iterator returned from <tt>a.insert(p,n,t)</tt> points to the copy of the
+first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>n == 0</tt>.
+</ins></p>
+
+<p><ins>
+The iterator returned from <tt>a.insert(p,i,j)</tt> points to the copy of the
+first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>i == j</tt>.
+</ins></p>
+
+<p><ins>
+The iterator returned from <tt>a.insert(p,il)</tt> points to the copy of the
+first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>il</tt> is empty.
+</ins></p>
+
+</blockquote>
+
<p>
-Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
+p9 23.2.6.1 [container.concepts.free] change return type from
+<tt>void</tt> to <tt>iterator</tt>:
</p>
+<blockquote><pre>concept RangeInsertionContainer<typename C, typename Iter> : InsertionContainer<C> {
+ requires InputIterator<Iter>;
+ <del>void</del> <ins>iterator</ins> insert(C&, const_iterator position, Iter first, Iter last);
+}
+</pre></blockquote>
+
<p>
-This is something of a nit, but I'm wondering if streamoff wouldn't be a
-better choice than streamsize. The argument to pbump and gbump MUST be
-signed. But the standard has this to say about streamsize
-(27.4.1/2/Footnote):
+p9 23.2.6.2 [container.concepts.member] change return type from
+<tt>void</tt> to <tt>iterator</tt>:
</p>
-<blockquote><p>
- [Footnote: streamsize is used in most places where ISO C would use
- size_t. Most of the uses of streamsize could use size_t, except for
- the strstreambuf constructors, which require negative values. It
- should probably be the signed type corresponding to size_t (which is
- what Posix.2 calls ssize_t). --- end footnote]
-</p></blockquote>
+<blockquote><pre>auto concept MemberRangeInsertionContainer<typename C, typename Iter> : MemberInsertionContainer<C> {
+ requires InputIterator<Iter>;
+ <del>void</del> <ins>iterator</ins> C::insert(const_iterator position, Iter first, Iter last);
+}
+</pre></blockquote>
<p>
-This seems a little weak for the argument to pbump and gbump. Should we
-ever really get rid of strstream, this footnote might go with it, along
-with the reason to make streamsize signed.
+p8 23.2.6.3 [container.concepts.maps] change return type from
+<tt>void</tt> to <tt>iterator</tt>, add return statement:
</p>
+<blockquote><pre>template <MemberRangeInsertionContainer C, InputIterator Iter>
+concept_map RangeInsertionContainer<C, Iter> {
+ <del>void</del> <ins>iterator</ins> insert(C& c, Container<C>::const_iterator i, Iter first, Iter last)
+ { <ins>return</ins> c.insert(i, first, last); }
+}
+</pre></blockquote>
-<p><b>Rationale:</b></p>
-<p>The LWG believes this change is too big for now. We may wish to
-reconsider this for a future revision of the standard. One
-possibility is overloading pbump, rather than changing the
-signature.</p>
-<p><i>[
-[2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
-]</i></p>
-
+<p>
+p2 23.3.2 [deque] Update class definition, change return type
+from <tt>void</tt> to <tt>iterator</tt>:
+</p>
+<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x);
+template <InputIterator Iter>
+ requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
+requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list<T>);
+</pre></blockquote>
+<p>
+23.3.2.3 [deque.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
+</p>
+<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x);
+template <InputIterator Iter>
+ requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
+</pre></blockquote>
-<hr>
-<h3><a name="290"></a>290. Requirements to for_each and its function object</h3>
-<p><b>Section:</b> 25.1.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The specification of the for_each algorithm does not have a
-"Requires" section, which means that there are no
-restrictions imposed on the function object whatsoever. In essence it
-means that I can provide any function object with arbitrary side
-effects and I can still expect a predictable result. In particular I
-can expect that the function object is applied exactly last - first
-times, which is promised in the "Complexity" section.
+<p>
+Add the following (missing) declaration
</p>
-<p>I don't see how any implementation can give such a guarantee
-without imposing requirements on the function object.
-</p>
+<blockquote><pre><ins>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+ iterator insert(const_iterator position, initializer_list<T>);</ins>
+</pre></blockquote>
-<p>Just as an example: consider a function object that removes
-elements from the input sequence. In that case, what does the
-complexity guarantee (applies f exactly last - first times) mean?
+<p>
+23.3.3 [forwardlist] Update class definition, change return type
+from <tt>void</tt> to <tt>iterator</tt>:
</p>
-<p>One can argue that this is obviously a nonsensical application and
-a theoretical case, which unfortunately it isn't. I have seen
-programmers shooting themselves in the foot this way, and they did not
-understand that there are restrictions even if the description of the
-algorithm does not say so.
-</p>
-<p><i>[Lillehammer: This is more general than for_each. We don't want
- the function object in transform invalidiating iterators
- either. There should be a note somewhere in clause 17 (17, not 25)
- saying that user code operating on a range may not invalidate
- iterators unless otherwise specified. Bill will provide wording.]</i></p>
+<blockquote><pre>requires AllocatableElement<Alloc, T, const T&>
+ <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list<T> il);
+requires AllocatableElement<Alloc, T, const T&>
+ <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T& x);
+template <InputIterator Iter>
+ requires AllocatableElement<Alloc, T, Iter::reference>
+ <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, Iter first, Iter last);
+</pre></blockquote>
+<p>
+p8 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
+</p>
+<blockquote><pre>requires AllocatableElement<Alloc, T, const T&>
+ <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T& x);
+</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
+<p>
+Add paragraph:
+</p>
+<blockquote>
+Returns: position.
+</blockquote>
+<p>
+p10 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
+</p>
+<blockquote><pre>template <InputIterator Iter>
+ requires AllocatableElement<Alloc, T, Iter::reference>
+ <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, Iter first, Iter last);
+</pre></blockquote>
+<p>
+Add paragraph:
+</p>
+<blockquote>
+Returns: position.
+</blockquote>
-<hr>
-<h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
-<p><b>Section:</b> 24.1.4 [bidirectional.iterators], 24.1.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> John Potter <b>Date:</b> 2001-01-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-In section 24.1.4 [bidirectional.iterators],
-Table 75 gives the return type of *r-- as convertible to T. This is
-not consistent with Table 74 which gives the return type of *r++ as
-T&. *r++ = t is valid while *r-- = t is invalid.
+p12 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
</p>
+<blockquote><pre>requires AllocatableElement<Alloc, T, const T&>
+ <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list<T> il);
+</pre></blockquote>
+
<p>
-In section 24.1.5 [random.access.iterators],
-Table 76 gives the return type of a[n] as convertible to T. This is
-not consistent with the semantics of *(a + n) which returns T& by
-Table 74. *(a + n) = t is valid while a[n] = t is invalid.
+change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
</p>
<p>
-Discussion from the Copenhagen meeting: the first part is
-uncontroversial. The second part, operator[] for Random Access
-Iterators, requires more thought. There are reasonable arguments on
-both sides. Return by value from operator[] enables some potentially
-useful iterators, e.g. a random access "iota iterator" (a.k.a
-"counting iterator" or "int iterator"). There isn't any obvious way
-to do this with return-by-reference, since the reference would be to a
-temporary. On the other hand, <tt>reverse_iterator</tt> takes an
-arbitrary Random Access Iterator as template argument, and its
-operator[] returns by reference. If we decided that the return type
-in Table 76 was correct, we would have to change
-<tt>reverse_iterator</tt>. This change would probably affect user
-code.
+p2 23.3.4 [list] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>
+<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x);
+
+template <InputIterator Iter>
+ requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
+
+requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list<T>);
+</pre></blockquote>
+
+
<p>
-History: the contradiction between <tt>reverse_iterator</tt> and the
-Random Access Iterator requirements has been present from an early
-stage. In both the STL proposal adopted by the committee
-(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
-Stepanov and Lee), the Random Access Iterator requirements say that
-operator[]'s return value is "convertible to T". In N0527
-reverse_iterator's operator[] returns by value, but in HPL-95-11
-(R.1), and in the STL implementation that HP released to the public,
-reverse_iterator's operator[] returns by reference. In 1995, the
-standard was amended to reflect the contents of HPL-95-11 (R.1). The
-original intent for operator[] is unclear.
+23.3.4.3 [list.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
</p>
+<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x);
+
+template <InputIterator Iter>
+ requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
+</pre></blockquote>
+
<p>
-In the long term it may be desirable to add more fine-grained
-iterator requirements, so that access method and traversal strategy
-can be decoupled. (See "Improved Iterator Categories and
-Requirements", N1297 = 01-0011, by Jeremy Siek.) Any decisions
-about issue 299 should keep this possibility in mind.
+Add the following (missing) declaration
</p>
-<p>Further discussion: I propose a compromise between John Potter's
-resolution, which requires <tt>T&</tt> as the return type of
-<tt>a[n]</tt>, and the current wording, which requires convertible to
-<tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
-for the return type of the expression <tt>a[n]</tt>, but to also add
-<tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
-common case uses of random access iterators, while at the same time
-allowing iterators such as counting iterator and caching file
-iterators to remain random access iterators (iterators where the
-lifetime of the object returned by <tt>operator*()</tt> is tied to the
-lifetime of the iterator).
-</p>
+<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+ iterator insert(const_iterator position, initializer_list<T>);
+</pre></blockquote>
<p>
-Note that the compromise resolution necessitates a change to
-<tt>reverse_iterator</tt>. It would need to use a proxy to support
-<tt>a[n] = t</tt>.
+p2 23.3.6 [vector]
</p>
<p>
-Note also there is one kind of mutable random access iterator that
-will no longer meet the new requirements. Currently, iterators that
-return an r-value from <tt>operator[]</tt> meet the requirements for a
-mutable random access iterartor, even though the expression <tt>a[n] =
-t</tt> will only modify a temporary that goes away. With this proposed
-resolution, <tt>a[n] = t</tt> will be required to have the same
-operational semantics as <tt>*(a + n) = t</tt>.
+Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>
+<blockquote><pre>requires AllocatableElement<Alloc, T, T&&> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, T&& x);
+requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x);
-<p><b>Proposed resolution:</b></p>
+template <InputIterator Iter>
+ requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
+
+requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list<T>);
+</pre></blockquote>
<p>
-In section 24.1.4 [lib.bidirectdional.iterators], change the return
-type in table 75 from "convertible to <tt>T</tt>" to
-<tt>T&</tt>.
+23.3.6.4 [vector.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
</p>
+<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x);
+
+template <InputIterator Iter>
+ requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
+</pre></blockquote>
+
<p>
-In section 24.1.5 [lib.random.access.iterators], change the
-operational semantics for <tt>a[n]</tt> to " the r-value of
-<tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
-n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
-with a return type of convertible to <tt>T</tt> and operational semantics of
-<tt>*(a + n) = t</tt>.
+Add the following (missing) declaration
</p>
-<p><i>[Lillehammer: Real problem, but should be addressed as part of
- iterator redesign]</i></p>
+<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
+ iterator insert(const_iterator position, initializer_list<T>);
+</pre></blockquote>
+<p>
+p1 23.3.7 [vector.bool] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
+</p>
+<blockquote><pre><del>void</del> <ins>iterator</ins> insert (const_iterator position, size_type n, const bool& x);
+template <InputIterator Iter>
+ requires Convertible<Iter::reference, bool>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
+ <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list<bool> il);
+</pre></blockquote>
+<p>
+p5 21.4 [basic.string] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
+</p>
+<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
+
+template<class InputIterator>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
+
+<del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list<charT>);
+</pre></blockquote>
-<hr>
-<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 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>
<p>
-The descriptions of the constructors of basic_istream<>::sentry
-(27.6.1.1.3 [istream::sentry]) and basic_ostream<>::sentry
-(27.6.2.4 [ostream::sentry]) do not explain what the functions do in
-case an exception is thrown while they execute. Some current
-implementations allow all exceptions to propagate, others catch them
-and set ios_base::badbit instead, still others catch some but let
-others propagate.
+p13 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>
+<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
+</pre></blockquote>
+
<p>
-The text also mentions that the functions may call setstate(failbit)
-(without actually saying on what object, but presumably the stream
-argument is meant). That may have been fine for
-basic_istream<>::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, since
-the function performs an input operation which may fail. However,
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a> amends 27.6.1.1.3 [istream::sentry], p2 to
-clarify that the function should actually call setstate(failbit |
-eofbit), so the sentence in p3 is redundant or even somewhat
-contradictory.
+Add paragraph:
</p>
+<blockquote>
+<i>Returns:</i> an iterator which refers to the copy of the first inserted
+character, or <tt>p</tt> if <tt>n == 0</tt>.
+</blockquote>
+
<p>
-The same sentence that appears in 27.6.2.4 [ostream::sentry], p3
-doesn't seem to be very meaningful for basic_istream<>::sentry
-which performs no input. It is actually rather misleading since it
-would appear to guide library implementers to calling
-setstate(failbit) when os.tie()->flush(), the only called function,
-throws an exception (typically, it's badbit that's set in response to
-such an event).
+p15 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>
-<p><b>Additional comments from Martin, who isn't comfortable with the
- current proposed resolution</b> (see c++std-lib-11530)</p>
+<blockquote><pre>template<class InputIterator>
+ <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
+</pre></blockquote>
+
+<p>
+Add paragraph:
+</p>
+
+<blockquote>
+<i>Returns:</i> an iterator which refers to the copy of the first inserted
+character, or <tt>p</tt> if <tt>first == last</tt>.
+</blockquote>
+
+<p>
+p17 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
+</p>
+
+<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list<charT> il);
+</pre></blockquote>
+
+<p>
+Add paragraph:
+</p>
+
+<blockquote>
+<i>Returns:</i> an iterator which refers to the copy of the first inserted
+character, or <tt>p</tt> if <tt>il</tt> is empty.
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+
+<p><i>[
+The following was the C++98/03 rationale and does not necessarily apply to the
+proposed resolution in the C++0X time frame:
+]</i></p>
+
+
+<blockquote>
+<p>The LWG believes this was an intentional design decision and so is
+not a defect. It may be worth revisiting for the next standard.</p>
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3>
+<p><b>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Mark Rintoul <b>Opened:</b> 1999-08-26 <b>Last modified:</b> 2008-03-14</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. A future standard may wish to consider additional
+function objects.</p>
+
+
+
+
+<hr>
+<h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3>
+<p><b>Section:</b> 25.3.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2000-03-06 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>The find function always searches for a value using operator== to compare the
+value argument to each element in the input iterator range. This is inconsistent
+with other find-related functions such as find_end and find_first_of, which
+allow the caller to specify a binary predicate object to be used for determining
+equality. The fact that this can be accomplished using a combination of find_if
+and bind_1st or bind_2nd does not negate the desirability of a consistent,
+simple, alternative interface to find.</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Reopened by Alisdair.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<blockquote>
+<p>In section 25.3.5 [alg.find], add a second prototype for find
+(between the existing prototype and the prototype for find_if), as
+follows:</p>
+<pre> template<class InputIterator, class T, class BinaryPredicate>
+ InputIterator find(InputIterator first, InputIterator last,
+ const T& value, BinaryPredicate bin_pred);</pre>
+<p>Change the description of the return from:</p>
+<blockquote>
+ <p>Returns: The first iterator i in the range [first, last) for which the following corresponding
+ conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p>
+</blockquote>
+<p> to:</p>
+<blockquote>
+ <p>Returns: The first iterator i in the range [first, last) for which the following
+ corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
+ != false. Return last if no such iterator is found.</p>
+</blockquote>
+</blockquote>
+
+
+<p><b>Rationale:</b></p>
+<p>This is request for a pure extension, so it is not a defect in the
+current standard. As the submitter pointed out, "this can
+be accomplished using a combination of find_if and bind_1st or
+bind_2nd".</p>
+
+
+
+
+<hr>
+<h3><a name="255"></a>255. Why do <tt>basic_streambuf<>::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
+<p><b>Section:</b> 27.6.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-12 <b>Last modified:</b> 2007-01-15</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
+<p><b>View all 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 basic_streambuf members gbump() and pbump() are specified to take an
+int argument. This requirement prevents the functions from effectively
+manipulating buffers larger than std::numeric_limits<int>::max()
+characters. It also makes the common use case for these functions
+somewhat difficult as many compilers will issue a warning when an
+argument of type larger than int (such as ptrdiff_t on LLP64
+architectures) is passed to either of the function. Since it's often the
+result of the subtraction of two pointers that is passed to the
+functions, a cast is necessary to silence such warnings. Finally, the
+usage of a native type in the functions signatures is inconsistent with
+other member functions (such as sgetn() and sputn()) that manipulate the
+underlying character buffer. Those functions take a streamsize argument.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the signatures of these functions in the synopsis of template
+class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
+and 27.5.2.3.2, p4) to take a streamsize argument.
+</p>
+
+<p>
+Although this change has the potential of changing the ABI of the
+library, the change will affect only platforms where int is different
+than the definition of streamsize. However, since both functions are
+typically inline (they are on all known implementations), even on such
+platforms the change will not affect any user code unless it explicitly
+relies on the existing type of the functions (e.g., by taking their
+address). Such a possibility is IMO quite remote.
+</p>
+
+<p>
+Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
+</p>
+
+<p>
+This is something of a nit, but I'm wondering if streamoff wouldn't be a
+better choice than streamsize. The argument to pbump and gbump MUST be
+signed. But the standard has this to say about streamsize
+(27.4.1/2/Footnote):
+</p>
+
+<blockquote><p>
+ [Footnote: streamsize is used in most places where ISO C would use
+ size_t. Most of the uses of streamsize could use size_t, except for
+ the strstreambuf constructors, which require negative values. It
+ should probably be the signed type corresponding to size_t (which is
+ what Posix.2 calls ssize_t). --- end footnote]
+</p></blockquote>
+
+<p>
+This seems a little weak for the argument to pbump and gbump. Should we
+ever really get rid of strstream, this footnote might go with it, along
+with the reason to make streamsize signed.
+</p>
+
+
+<p><b>Rationale:</b></p>
+<p>The LWG believes this change is too big for now. We may wish to
+reconsider this for a future revision of the standard. One
+possibility is overloading pbump, rather than changing the
+signature.</p>
+<p><i>[
+[2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="290"></a>290. Requirements to for_each and its function object</h3>
+<p><b>Section:</b> 25.3.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2001-01-03 <b>Last modified:</b> 2006-12-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.foreach">active issues</a> in [alg.foreach].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>The specification of the for_each algorithm does not have a
+"Requires" section, which means that there are no
+restrictions imposed on the function object whatsoever. In essence it
+means that I can provide any function object with arbitrary side
+effects and I can still expect a predictable result. In particular I
+can expect that the function object is applied exactly last - first
+times, which is promised in the "Complexity" section.
+</p>
+
+<p>I don't see how any implementation can give such a guarantee
+without imposing requirements on the function object.
+</p>
+
+<p>Just as an example: consider a function object that removes
+elements from the input sequence. In that case, what does the
+complexity guarantee (applies f exactly last - first times) mean?
+</p>
+
+<p>One can argue that this is obviously a nonsensical application and
+a theoretical case, which unfortunately it isn't. I have seen
+programmers shooting themselves in the foot this way, and they did not
+understand that there are restrictions even if the description of the
+algorithm does not say so.
+</p>
+<p><i>[Lillehammer: This is more general than for_each. We don't want
+ the function object in transform invalidiating iterators
+ either. There should be a note somewhere in clause 17 (17, not 25)
+ saying that user code operating on a range may not invalidate
+ iterators unless otherwise specified. Bill will provide wording.]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="309"></a>309. Does sentry catch exceptions?</h3>
+<p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-19 <b>Last modified:</b> 2006-12-27</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>
+<p>
+The descriptions of the constructors of basic_istream<>::sentry
+(27.7.1.1.3 [istream::sentry]) and basic_ostream<>::sentry
+(27.7.2.4 [ostream::sentry]) do not explain what the functions do in
+case an exception is thrown while they execute. Some current
+implementations allow all exceptions to propagate, others catch them
+and set ios_base::badbit instead, still others catch some but let
+others propagate.
+</p>
+
+<p>
+The text also mentions that the functions may call setstate(failbit)
+(without actually saying on what object, but presumably the stream
+argument is meant). That may have been fine for
+basic_istream<>::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, since
+the function performs an input operation which may fail. However,
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a> amends 27.7.1.1.3 [istream::sentry], p2 to
+clarify that the function should actually call setstate(failbit |
+eofbit), so the sentence in p3 is redundant or even somewhat
+contradictory.
+</p>
+
+<p>
+The same sentence that appears in 27.7.2.4 [ostream::sentry], p3
+doesn't seem to be very meaningful for basic_istream<>::sentry
+which performs no input. It is actually rather misleading since it
+would appear to guide library implementers to calling
+setstate(failbit) when os.tie()->flush(), the only called function,
+throws an exception (typically, it's badbit that's set in response to
+such an event).
+</p>
+
+<p><b>Additional comments from Martin, who isn't comfortable with the
+ current proposed resolution</b> (see c++std-lib-11530)</p>
<p>
The istream::sentry ctor says nothing about how the function
<hr>
<h3><a name="342"></a>342. seek and eofbit</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#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-10-09</p>
+<p><b>Section:</b> 27.
7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-10-09 <b>Last modified:</b> 2007-01-15</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>I think we have a defect.</p>
<p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the
-description of seekg in 27.6.1.3 [istream.unformatted] paragraph 38 now looks
+description of seekg in 27.7.1.3 [istream.unformatted] paragraph 38 now looks
like:</p>
<blockquote><p>
<p><b>Proposed resolution:</b></p>
-<p>Change 27.6.1.3 [istream.unformatted] to:</p>
+<p>Change 27.7.1.3 [istream.unformatted] to:</p>
<blockquote><p>
Behaves as an unformatted input function (as described in 27.6.1.3,
paragraph 1), except that it does not count the number of characters
<hr>
<h3><a name="343"></a>343. Unspecified library header dependencies</h3>
-<p><b>Section:</b> 21 [strings], 23 [containers], 27 [input.output] <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-10-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-10-09 <b>Last modified:</b> 2009-03-11</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="382"></a>382. codecvt do_in/out result</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <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> 2002-08-30</p>
+<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-08-30 <b>Last modified:</b> 2007-01-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
<p><b>View all 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>
- 22.2.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the
+ 22.4.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the
function: ...Stops if it encounters a character it cannot
convert... This assumes that there *is* a character to
convert. What happens when there is a sequence that doesn't form a
</li>
</ol>
<p>
-Finally, the conditions described at the end of 22.2.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
+Finally, the conditions described at the end of 22.4.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
</p>
<blockquote><p>
"A return value of partial, if (from_next == from_end),
==from_end) could ever hold if there isn't enough room
in the destination buffer. In order for (from_next==from_end) to
hold, all characters in that range must have been successfully
-converted (according to 22.2.1.4.2 [locale.codecvt.virtuals], p2) and since there are no
+converted (according to 22.4.1.4.2 [locale.codecvt.virtuals], p2) and since there are no
further source characters to convert, no more room in the
destination buffer can be needed.
</p>
<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#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#Ready">Ready</a> status.</p>
+<h3><a name="394"></a>394. behavior of formatted output on failure</h3>
+<p><b>Section:</b> 27.7.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-12-27 <b>Last modified:</b> 2007-01-15</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The absence of explicit description of std::complex<T> layout
-makes it imposible to reuse existing software developed in traditional
-languages like Fortran or C with unambigous and commonly accepted
-layout assumptions. There ought to be a way for practitioners to
-predict with confidence the layout of std::complex<T> whenever T
-is a numerical datatype. The absence of ways to access individual
-parts of a std::complex<T> object as lvalues unduly promotes
-severe pessimizations. For example, the only way to change,
-independently, the real and imaginary parts is to write something like
+There is a contradiction in Formatted output about what bit is
+supposed to be set if the formatting fails. On sentence says it's
+badbit and another that it's failbit.
</p>
-
-<pre>complex<T> z;
-// ...
-// set the real part to r
-z = complex<T>(r, z.imag());
-// ...
-// set the imaginary part to i
-z = complex<T>(z.real(), i);
-</pre>
-
<p>
-At this point, it seems appropriate to recall that a complex number
-is, in effect, just a pair of numbers with no particular invariant to
-maintain. Existing practice in numerical computations has it that a
-complex number datatype is usually represented by Cartesian
-coordinates. Therefore the over-encapsulation put in the specification
-of std::complex<> is not justified.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add the following requirements to 26.3 [complex.numbers] as 26.3/4:</p>
-<blockquote>
-<p>If z is an lvalue expression of type cv std::complex<T> then</p>
-
-<ul>
-<li>the expression reinterpret_cast<cv T(&)[2]>(z)
-is well-formed; and</li>
-<li>reinterpret_cast<cv T(&)[2]>(z)[0]designates the
-real part of z; and</li>
-<li>reinterpret_cast<cv T(&)[2]>(z)[1]designates the
-imaginary part of z.</li>
-</ul>
-
-<p>
-Moreover, if a is an expression of pointer type cv complex<T>*
-and the expression a[i] is well-defined for an integer expression
-i then:
-</p>
-
-<ul>
-<li>reinterpret_cast<cv T*>(a)[2*i] designates the real
-part of a[i]; and</li>
-<li>reinterpret_cast<cv T*>(a)[2*i+1] designates the
-imaginary part of a[i].</li>
-</ul>
-</blockquote>
-
-<p>
-In 26.3.2 [complex] and 26.3.3 [complex.special] add the following member functions
-(changing <tt>T</tt> to concrete types as appropriate for the specializations).
-</p>
-
-<blockquote><pre>void real(T);
-void imag(T);
-</pre></blockquote>
-
-<p>
-Add to 26.3.4 [complex.members]
-</p>
-
-<blockquote>
-<pre>T real() const;
-</pre>
-<blockquote>
-<i>Returns:</i> the value of the real component
-</blockquote>
-<pre>void real(T val);
-</pre>
-<blockquote>
-Assigns val to the real component.
-</blockquote>
-<pre>T imag() const;
-</pre>
-<blockquote>
-<i>Returns:</i> the value of the imaginary component
-</blockquote>
-<pre>void imag(T val);
-</pre>
-<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
- of this proposal: retrieving elements of the complex number as
- lvalues. An alternative: continue to have real() and imag() return
- rvalues, but add set_real() and set_imag(). Straw poll: return
- lvalues - 2, add setter functions - 5. Related issue: do we want
- reinterpret_cast as the interface for converting a complex to an
- array of two reals, or do we want to provide a more explicit way of
- doing it? Howard will try to resolve this issue for the next
- meeting.]</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><i>[
-Pre-Sophia Antipolis, Howard adds:
-]</i></p>
-
-
-<blockquote>
-Added the members to 26.3.3 [complex.special] and changed from Ready to Review.
-</blockquote>
-
-<p><i>[
-Post-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-Moved from WP back to Ready so that the "and 26.3.3 [complex.special]" in the proposed
-resolution can be officially applied.
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes that C99 compatibility would be enough
-justification for this change even without other considerations. All
-existing implementations already have the layout proposed here.</p>
-
-
-
-
-
-<hr>
-<h3><a name="394"></a>394. behavior of formatted output on failure</h3>
-<p><b>Section:</b> 27.6.2.6.1 [ostream.formatted.reqmts] <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> 2002-12-27</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There is a contradiction in Formatted output about what bit is
-supposed to be set if the formatting fails. On sentence says it's
-badbit and another that it's failbit.
-</p>
-<p>
-27.6.2.5.1, p1 says in the Common Requirements on Formatted output
-functions:
+27.6.2.5.1, p1 says in the Common Requirements on Formatted output
+functions:
</p>
<pre> ... If the generation fails, then the formatted output function
does setstate(ios::failbit), which might throw an exception.
<hr>
-<h3><a name="396"></a>396. what are characters zero and one</h3>
-<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</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>Discussion:</b></p>
- <p>
-23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
-having the value of 0 or 1 but there is no definition of what
-that means for charT other than char and wchar_t. And even for
-those two types, the values 0 and 1 are not actually what is
-intended -- the values '0' and '1' are. This, along with the
-converse problem in the description of to_string() in 23.3.5.2,
-p33, looks like a defect remotely related to DR 303.
- </p>
- <p>
-http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
- </p>
- <pre>23.3.5.1:
- -6- An element of the constructed string has value zero if the
- corresponding character in str, beginning at position pos,
- is 0. Otherwise, the element has the value one.
- </pre>
- <pre>23.3.5.2:
- -33- Effects: Constructs a string object of the appropriate
- type and initializes it to a string of length N characters.
- Each character is determined by the value of its
- corresponding bit position in *this. Character position N
- ?- 1 corresponds to bit position zero. Subsequent decreasing
- character positions correspond to increasing bit positions.
- Bit value zero becomes the character 0, bit value one becomes
- the character 1.
- </pre>
- <p>
-Also note the typo in 23.3.5.1, p6: the object under construction
-is a bitset, not a string.
- </p>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-We note that <tt>bitset</tt> has been moved from section 23 to section 20, by
-another issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>) previously resolved at this meeting.
-</p>
-<p>
-Disposition: move to ready.
-</p>
-<p>
-We request that Howard submit a separate issue regarding the three to_string overloads.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the constructor's function declaration immediately before
-23.3.5.1 [bitset.cons] p3 to:</p>
-<pre> template <class charT, class traits, class Allocator>
- explicit
- bitset(const basic_string<charT, traits, Allocator>& str,
- typename basic_string<charT, traits, Allocator>::size_type pos = 0,
- typename basic_string<charT, traits, Allocator>::size_type n =
- basic_string<charT, traits, Allocator>::npos,
- charT zero = charT('0'), charT one = charT('1'))
-</pre>
-<p>Change the first two sentences of 23.3.5.1 [bitset.cons] p6 to: "An
-element of the constructed string has value 0 if the corresponding
-character in <i>str</i>, beginning at position <i>pos</i>,
-is <i>zero</i>. Otherwise, the element has the value 1.</p>
-
-<p>Change the text of the second sentence in 23.3.5.1, p5 to read:
- "The function then throws invalid_argument if any of the rlen
- characters in str beginning at position pos is other than <i>zero</i>
- or <i>one</i>. The function uses traits::eq() to compare the character
- values."
-</p>
-
-<p>Change the declaration of the <tt>to_string</tt> member function
- immediately before 23.3.5.2 [bitset.members] p33 to:</p>
-<pre> template <class charT, class traits, class Allocator>
- basic_string<charT, traits, Allocator>
- to_string(charT zero = charT('0'), charT one = charT('1')) const;
-</pre>
-<p>Change the last sentence of 23.3.5.2 [bitset.members] p33 to: "Bit
- value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
- character <tt><i>one</i></tt>.</p>
-<p>Change 23.3.5.3 [bitset.operators] p8 to:</p>
-<p><b>Returns</b>:</p>
-<pre> os << x.template to_string<charT,traits,allocator<charT> >(
- use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('0'),
- use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('1'));
-</pre>
-
-
-<p><b>Rationale:</b></p>
-<p>There is a real problem here: we need the character values of '0'
- and '1', and we have no way to get them since strings don't have
- imbued locales. In principle the "right" solution would be to
- provide an extra object, either a ctype facet or a full locale,
- which would be used to widen '0' and '1'. However, there was some
- discomfort about using such a heavyweight mechanism. The proposed
- resolution allows those users who care about this issue to get it
- right.</p>
-<p>We fix the inserter to use the new arguments. Note that we already
- fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>.</p>
-
-
-
-<p><i>[
-post Bellevue:
-]</i></p>
-
-
-<blockquote>
-We are happy with the resolution as proposed, and we move this to Ready.
-</blockquote>
-
-<p><i>[
-Howard adds:
-]</i></p>
-
-
-<blockquote>
-The proposed wording neglects the 3 newer to_string overloads.
-</blockquote>
-
-
-
-
-<hr>
<h3><a name="397"></a>397. ostream::sentry dtor throws exceptions</h3>
-<p><b>Section:</b> 27.
6.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
+<p><b>Section:</b> 27.
7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05 <b>Last modified:</b> 2007-07-25</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<hr>
<h3><a name="398"></a>398. effects of end-of-file on unformatted input functions</h3>
-<p><b>Section:</b> 27.
6.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
+<p><b>Section:</b> 27.
7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05 <b>Last modified:</b> 2007-01-15</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<hr>
<h3><a name="408"></a>408. Is vector<reverse_iterator<char*> > forbidden?</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#Open">Open</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
+<p><b>Section:</b> 24.
2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03 <b>Last modified:</b> 2009-05-10</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
</p>
<p>
-24.1 [iterator.requirements] says that the only operation that can be performed on "singular"
+24.2 [iterator.concepts] says that the only operation that can be performed on "singular"
iterator values is to assign a non-singular value to them. (It
doesn't say they can be destroyed, and that's probably a defect.)
Some implementations have taken this to imply that there is no need
iterator value, singular or not, default-initialized or not.
</p>
-<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a></p>
+<p>Related issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a></p>
<p><i>[
We don't want to require all singular iterators to be copyable,
because that is not the case for pointers. However, default
]</i></p>
+<p><i>[
+2009-05-10 Alisdair provided wording.
+]</i></p>
+
+
+<blockquote>
+The comments regarding destroying singular iterators have already been
+resolved. That just leaves copying (with moving implied).
+</blockquote>
+
<p><b>Proposed resolution:</b></p>
+<p>
+Add to the end of Iterator concepts 24.2 [iterator.concepts] para 6 (the one
+describing singular iterators)
+</p>
+<blockquote>
+Any Iterator that satisfies the <tt>DefaultConstructible</tt> concept shall
+be safely copyable after value-initialization, even if it would otherwise be
+singular. [<i>Note:</i> This guarantee is not offered for default-initialization
+(8.5 [dcl.init]), although the distinction only matters for types with
+trivial default constructors such as pointers. — <i>end note</i>]
+</blockquote>
+
<hr>
<h3><a name="417"></a>417. what does ctype::do_widen() return on failure</h3>
-<p><b>Section:</b> 22.
2.1.1.2 [locale.ctype.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> 2003-09-18</p>
+<p><b>Section:</b> 22.
4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.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>
<hr>
<h3><a name="418"></a>418. exceptions thrown during iostream cleanup</h3>
-<p><b>Section:</b> 27.4.2.1.6 [ios::Init] <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>Section:</b> 27.5.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2007-07-25</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ios::Init">active issues</a> in [ios::Init].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::Init">issues</a> in [ios::Init].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3>
-<p><b>Section:</b> 27.
6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<p><b>Section:</b> 27.
7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2007-01-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-27.6.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
+27.7.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
-true if the stream state is good after any preparation. 27.6.1.2.1 [istream.formatted.reqmts], p1 then
+true if the stream state is good after any preparation. 27.7.1.2.1 [istream.formatted.reqmts], p1 then
says that a formatted input function endeavors to obtain the requested input
if the sentry's operator bool() returns true.
<p><b>Proposed resolution:</b></p>
<p>
-Change 27.6.1.1.3 [istream::sentry], p2 to:
+Change 27.7.1.1.3 [istream::sentry], p2 to:
</p>
<blockquote>
<hr>
<h3><a name="421"></a>421. is basic_streambuf copy-constructible?</h3>
-<p><b>Section:</b> 27.
5.2.1 [streambuf.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-09-18</p>
+<p><b>Section:</b> 27.
6.2.1 [streambuf.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>Opened:</b> 2003-09-18 <b>Last modified:</b> 2007-01-15</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.cons">issues</a> in [streambuf.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>
<hr>
<h3><a name="423"></a>423. effects of negative streamsize in iostreams</h3>
<p><b>Section:</b> 27 [input.output] <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>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2006-12-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
<p><b>View all 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>
<hr>
+<h3><a name="424"></a>424. normative notes</h3>
+<p><b>Section:</b> 17.5.1.2 [structure.summary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively 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.8.6.1 [allocator.members], p3,<br>
+20.8.6.1 [allocator.members], p10,<br>
+21.4.2 [string.cons], p11,<br>
+22.3.1.2 [locale.cons], p11,<br>
+23.3.2.3 [deque.modifiers], p2,<br>
+25.5.7 [alg.min.max], p3,<br>
+26.4.6 [complex.ops], p15,<br>
+27.6.2.4.3 [streambuf.virt.get], p7.<br>
+<br>
+
+List 2 -- Examples of (presumably) informative Notes:
+<br>
+
+18.6.1.3 [new.delete.placement], p3,<br>
+21.4.6.6 [string::replace], p14,<br>
+22.4.1.4.2 [locale.codecvt.virtuals], p3,<br>
+25.3.4 [alg.foreach], p4,<br>
+26.4.5 [complex.member.ops], p1,<br>
+27.5.2.5 [ios.base.storage], p6.<br>
+<br>
+
+List 3 -- Examples of Notes that are not clearly either normative
+or informative:
+<br>
+
+22.3.1.2 [locale.cons], p8,<br>
+22.3.1.5 [locale.statics], p6,<br>
+27.6.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><i>[
+post San Francisco: Howard: reopened, needs attention.
+]</i></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>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+A spot-check of List 2 suggests the issue is still relevant,
+and a review of List 3 still seems called-for.
+</p>
+<p>
+Move to NAD Editorial.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></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>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<p><b>Section:</b> 22.
4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2007-01-15</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<hr>
<h3><a name="430"></a>430. valarray subset operations</h3>
-<p><b>Section:</b> 26.
5.2.4 [valarray.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<p><b>Section:</b> 26.
6.2.4 [valarray.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2009-05-01</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<p><b>Proposed resolution:</b></p>
<p>
-Insert after 26.5.2.4 [valarray.sub], paragraph 1:
+Insert after 26.6.2.4 [valarray.sub], paragraph 1:
</p>
<blockquote>
const size_t dv[] = {7, 2};
const valarray<size_t> len(lv, 2), str(dv, 2);
// v0[gslice(3, len, str)] returns
-// valarray<char>("dfhkmo", 6)
+// valarray<char>("dfhkmo", 6)
</pre></blockquote>
<p>
<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
const bool vb[] = {false, false, true, true, false, true};
// v0[valarray<bool>(vb, 6)] returns
-// valarray<char>("cdf", 3)
+// valarray<char>("cdf", 3)
</pre></blockquote>
<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>Section:</b>
X [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-09-20 <b>Last modified:</b> 2009-05-01</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
+<p>Clause X [allocator.requirements] paragraph 4 says that implementations
are permitted to supply containers that are unable to cope with
allocator instances and that container implementations may assume
that all instances of an allocator type compare equal. We gave
]</i></p>
+<p><i>[
+2009-04-28 Pablo adds:
+]</i></p>
+
+<blockquote>
+Fixed in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>.
+I argued for marking this Tentatively-Ready right after Bellevue,
+but there was a concern that
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
+would break in the presence of the RVO. (That breakage had nothing to do with
+swap, but never-the-less). I addressed that breakage in in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
+(Summit) my means of a non-normative reference:
+
+<blockquote>
+[<i>Note:</i> in situations where the copy constructor for a container is elided,
+this function is not called. The behavior in these cases is as if
+<tt>select_on_container_copy_construction</tt> returned <tt>x</tt> — <i>end note</i>]
+</blockquote>
+
+</blockquote>
+
<p><b>Proposed resolution:</b></p>
<hr>
<h3><a name="446"></a>446. Iterator equality between different containers</h3>
-<p><b>Section:</b> 24.
1 [iterator.requirements], 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> Andy Koenig <b>Date:</b> 2003-12-16</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>Section:</b> 24.
2 [iterator.concepts], 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Andy Koenig <b>Opened:</b> 2003-12-16 <b>Last modified:</b> 2008-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
-<h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3>
-<p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
-<p><b>View 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>
+<h3><a name="458"></a>458. 24.1.5 contains unintented limitation for operator-</h3>
+<p><b>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2004-02-27 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
-<pre> basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
-</pre>
-
-<p>should be supplemented with the overload:</p>
-
-<pre> basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
-</pre>
-
<p>
-Depending on the operating system, one of these forms is fundamental and
-the other requires an implementation-defined mapping to determine the
-actual filename.
+In 24.1.5 [lib.random.access.iterators], table 76 the operational
+semantics for the expression "r -= n" are defined as "return r += -n".
+This means, that the expression -n must be valid, which is not the case
+for unsigned types.
</p>
-<p><i>[Sydney: Yes, we want to allow wchar_t filenames. Bill will
- provide wording.]</i></p>
-
-
<p><i>[
-In Toronto we noted that this is issue 5 from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm">N1569</a>.
+Sydney: Possibly not a real problem, since difference type is required
+to be a signed integer type. However, the wording in the standard may
+be less clear than we would like.
]</i></p>
-<p>
-How does this interact with the newly-defined character types, and how
-do we avoid interface explosion considering <tt>std::string</tt> overloads that
-were added? Propose another solution that is different than the
-suggestion proposed by PJP.
-</p>
-<p>
-Suggestion is to make a member template function for <tt>basic_string</tt> (for
-<tt>char</tt>, <tt>wchar_t</tt>, <tt>u16char</tt>, <tt>u32char</tt> instantiations), and then just keep a
-<tt>const char*</tt> member.
-</p>
-<p>
-Goal is to do implicit conversion between character string literals to
-appropriate <tt>basic_string</tt> type. Not quite sure if this is possible.
-</p>
-<p>
-Implementors are free to add specific overloads for non-char character
-types.
-</p>
<p><i>[
-Martin adds pre-Sophia Antipolis:
+Post Summit Alisdair adds:
]</i></p>
<blockquote>
-Please see <a href="http://wiki.dinkumware.com/twiki/pub/Wg21sophiaAntipolis/LibraryWorkingGroup/issue-454.html">issue 454: problems and solutions</a>.
+<p>
+This issue refers to a requirements table we have removed.
+</p>
+<p>
+The issue might now relate to 24.2.6 [random.access.iterators] p5.
+However, the rationale in the issue already recognises that the
+<tt>difference_type</tt> must be signed, so this really looks NAD.
+</p>
</blockquote>
<p><i>[
-Sophia Antipolis:
+Batavia (2009-05):
]</i></p>
-
<blockquote>
<p>
-Beman is concerned that making these changes to <tt>basic_filebuf</tt> is not
-usefully changed unless <tt>fstream</tt> is also changed; this also only handles
-<tt>wchar_t</tt> and not other character types.
+We agree with Alisdair's observations.
</p>
<p>
-The TR2 filesystem library is a more complete solution, but is not available soon.
+Move to NAD.
</p>
</blockquote>
-<p><i>[
-Martin adds: please reference
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2683.html">N2683</a> for
-problems and solutions.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Change from:</p>
-<blockquote>
-<pre>basic_filebuf<charT,traits>* open(
- const char* s,
- ios_base::openmode mode );
-</pre>
-
-<p>
-Effects: If is_open() != false, returns a null pointer.
-Otherwise, initializes the filebuf as required. It then
-opens a file, if possible, whose name is the NTBS s ("as if"
-by calling std::fopen(s,modstr)).</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-<pre>basic_filebuf<charT,traits>* open(
- const char* s,
- ios_base::openmode mode );
-
-basic_filebuf<charT,traits>* open(
- const wchar_t* ws,
- ios_base::openmode mode );
-</pre>
-
-<p>
-Effects: If is_open() != false, returns a null pointer.
-Otherwise, initializes the filebuf as required. It then
-opens a file, if possible, whose name is the NTBS s ("as if"
-by calling std::fopen(s,modstr)).
-For the second signature, the NTBS s is determined from the
-WCBS ws in an implementation-defined manner.
-</p>
-
-<p>
-(NOTE: For a system that "naturally" represents a filename
-as a WCBS, the NTBS s in the first signature may instead
-be mapped to a WCBS; if so, it follows the same mapping
-rules as the first argument to open.)
-</p>
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
-this to Ready. The controversy was because the mapping between wide
-names and files in a filesystem is implementation defined. The
-counterargument, which most but not all LWG members accepted, is that
-the mapping between narrow files names and files is also
-implemenation defined.</p>
-
-<p><i>[Lillehammer: Moved back to "open" status, at Beman's urging.
-(1) Why just basic_filebuf, instead of also basic_fstream (and
-possibly other things too). (2) Why not also constructors that take
-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>
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="458"></a>458. 24.1.5 contains unintented limitation for operator-</h3>
-<p><b>Section:</b> 24.1.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-02-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 24.1.5 [lib.random.access.iterators], table 76 the operational
-semantics for the expression "r -= n" are defined as "return r += -n".
-This means, that the expression -n must be valid, which is not the case
-for unsigned types.
-</p>
-
-<p><i>[
-Sydney: Possibly not a real problem, since difference type is required
-to be a signed integer type. However, the wording in the standard may
-be less clear than we would like.
-]</i></p>
-
-
-
<p><b>Proposed resolution:</b></p>
<p>
To remove this limitation, I suggest to change the
operational semantics for this column to:
</p>
-<blockquote><pre> { Distance m = n;
- if (m >= 0)
- while (m--) --r;
- else
+<blockquote><pre> { Distance m = n;
+ if (m >= 0)
+ while (m--) --r;
+ else
while (m++) ++r;
return r; }
</pre></blockquote>
<hr>
<h3><a name="459"></a>459. Requirement for widening in stage 2 is overspecification</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>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-03-16</p>
+<p><b>Section:</b> 22.
4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-03-16 <b>Last modified:</b> 2006-12-27</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
their narrow equivalents (i.e., the portable source characters '0'
through '9'), the change does not necessarily imply that these
alternate digits would be treated as ordinary digits and accepted as
-part of numbers during parsing. In fact, the requirement in 22.2.1.1.2
+part of numbers during parsing. In fact, the requirement in 22.4.1.1.2
[locale.ctype.virtuals], p13 forbids narrow() to translate an alternate
digit character, wc, to an ordinary digit in the basic source
character set unless the expression
<hr>
<h3><a name="463"></a>463. auto_ptr usability issues</h3>
<p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p>
+ <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2003-12-07 <b>Last modified:</b> 2007-11-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#auto.ptr">active issues</a> in [auto.ptr].</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>
<hr>
+<h3><a name="466"></a>466. basic_string ctor should prevent null pointer error</h3>
+<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2004-06-10 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.require">active issues</a> in [string.require].</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#Open">Open</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:
+</p>
+
+<pre> #include <string>
+ int main() { std::string( 0 ); }
+</pre>
+
+<p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
+Comeau online) compile the above without errors or warnings! The
+programs (at least for the GCC) resulted in a SEGV.</p>
+
+<p>I know that the standard explicitly states that the ctor of string
+requires a char* which is not zero. STLs could easily detect the above
+case with a private ctor for basic_string which takes a single 'int'
+argument. This would catch the above code at compile time and would not
+ambiguate any other legal ctors.</p>
+
+<p><i>[Redmond: No great enthusiasm for doing this. If we do,
+ however, we want to do it for all places that take <tt>charT*</tt>
+ pointers, not just the single-argument constructor. The other
+ question is whether we want to catch this at compile time (in which
+ case we catch the error of a literal 0, but not an expression whose
+ value is a null pointer), at run time, or both.
+ Recommend NAD. Relegate this functionality to debugging implementations.]</i></p>
+
+
+<p><i>[
+Post Summit: Alisdair requests this be re-opened as several new language facilities are
+designed to solve exactly this kind of problem.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We are unable to achieve consensus on an approach to a resolution.
+There is some sentiment for treating this as a QOI matter.
+It is also possible
+that when <tt>string</tt> is brought into the concepts world,
+this issue might be addressed in that context.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to the synopsis in 21.4 [basic.string]
+</p>
+
+<blockquote><pre><ins>basic_string( nullptr_t ) = delete;</ins>
+</pre></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#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
+<p><b>Section:</b> 18.
7.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>Opened:</b> 2004-06-28 <b>Last modified:</b> 2009-05-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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>
<blockquote>
The issue was pulled from Ready. It needs to make clear that only homogenous copying
-is intended to be supported. Not coping from a dervied to a base.
+is intended to be supported, not coping from a derived to a base.
</blockquote>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+<blockquote>
+<p>
+Howard supplied the following replacement wording
+for paragraph 7 of the proposed resolution:
+</p>
+<blockquote>
+<ins>-7- <i>Postcondition:</i> <tt>what()</tt> shall return the same NTBS
+ as would be obtained by using <tt>static_cast</tt>
+ to cast the rhs to the same types as the lhs
+ and then calling <tt>what()</tt> on that possibly sliced object.</ins>
+</blockquote>
+<p>
+Pete asks what "the same NTBS" means.
+</p>
+</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Change 18.7.1 [exception] to:
+Change 18.8.1 [exception] to:
</p>
<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>Section:</b> 22.
4.1.1 [locale.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-07-01 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
-<h3><a name="484"></a>484. Convertible to T</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#Open">Open</a>
- <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-09-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>From comp.std.c++:</p>
-
-<p>
-I note that given an input iterator a for type T,
-then *a only has to be "convertable to T", not actually of type T.
-</p>
-
-<p>Firstly, I can't seem to find an exact definition of "convertable to T".
-While I assume it is the obvious definition (an implicit conversion), I
-can't find an exact definition. Is there one?</p>
-
-<p>Slightly more worryingly, there doesn't seem to be any restriction on
-the this type, other than it is "convertable to T". Consider two input
-iterators a and b. I would personally assume that most people would
-expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
-the standard requires that, and that whatever type *a is (call it U)
-could have == defined on it with totally different symantics and still
-be a valid inputer iterator.</p>
-
-<p>Is this a correct reading? When using input iterators should I write
-T(*a) all over the place to be sure that the object i'm using is the
-class I expect?</p>
-
-<p>This is especially a nuisance for operations that are defined to be
- "convertible to bool". (This is probably allowed so that
- implementations could return say an int and avoid an unnessary
- conversion. However all implementations I have seen simply return a
- bool anyway. Typical implemtations of STL algorithms just write
- things like <tt>while(a!=b && *a!=0)</tt>. But strictly
- speaking, there are lots of types that are convertible to T but
- that also overload the appropriate operators so this doesn't behave
- as expected.</p>
-
-<p>If we want to make code like this legal (which most people seem to
- expect), then we'll need to tighten up what we mean by "convertible
- to T".</p>
-
-<p><i>[Lillehammer: The first part is NAD, since "convertible" is
- well-defined in core. The second part is basically about pathological
- overloads. It's a minor problem but a real one. So leave open for
- now, hope we solve it as part of iterator redesign.]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
<h3><a name="485"></a>485. output iterator insufficently constrained</h3>
-<p><b>Section:</b> 24.
1.2 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-10-13</p>
+<p><b>Section:</b> 24.
2.3 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-10-13 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<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>Section:</b>
17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12 <b>Last modified:</b> 2009-05-10</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</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>Various clauses other than clause 25 make use of iterator arithmetic not
Keep open and ask Bill to provide wording.
</blockquote>
+<p><i>[
+2009-05-09 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>.
+</blockquote>
+
+
<p><b>Proposed resolution:</b></p>
<hr>
<h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
-<p><b>Section:</b> 25.
2.13 [alg.partitions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Sean Parent, Joe Gottman <b>Date:</b> 2005-05-04</p>
+<p><b>Section:</b> 25.
4.13 [alg.partitions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Sean Parent, Joe Gottman <b>Opened:</b> 2005-05-04 <b>Last modified:</b> 2009-05-01</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
</p>
+<p><i>[
+2009-04-30 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Now we have concepts this is easier to express!
+</p>
+<p>
+Proposed resolution:
+</p>
+<p>
+Add the following signature to:
+</p>
+<p>
+Header <tt><algorithm></tt> synopsis 25.2 [algorithms.syn]<br>
+p3 Partitions 25.4.13 [alg.partitions]
+</p>
+<blockquote><pre> template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred>
+ requires ShuffleIterator<Iter>
+ && CopyConstructible<Pred>
+ Iter partition(Iter first, Iter last, Pred pred);
+</pre></blockquote>
+
+<p>
+Update p3 Partitions 25.4.13 [alg.partitions]:
+</p>
+
+<blockquote>
+<p>
+<i>Complexity:</i> <del>At most <tt>(last - first)/2</tt> swaps. Exactly <tt>last - first</tt>
+applications of the predicate
+are done.</del>
+<ins>
+If <tt>Iter</tt> satisfies <tt>BidirectionalIterator</tt>, at most <tt>(last -
+first)/2</tt> swaps. Exactly <tt>last - first</tt> applications of the predicate
+are done.
+</ins>
+</p>
+<p><ins>
+If <tt>Iter</tt> merely satisfied <tt>ForwardIterator</tt> at most <tt>(last - first)</tt> swaps
+are done. Exactly <tt>(last - first)</tt> applications of the predicate are done.
+</ins></p>
+</blockquote>
+
+<p>
+[Editorial note: I looked for existing precedent in how we might call out
+distinct overloads overloads from a set of constrained templates, but there
+is not much existing practice to lean on. advance/distance were the only
+algorithms I could find, and that wording is no clearer.]
+</p>
+
+</blockquote>
+
+
<p><b>Proposed resolution:</b></p>
<p>
<p>
Partition is a "foundation" algorithm useful in many contexts (like sorting
as just one example) - my motivation for extending it to include forward
-iterators is slist - without this extension you can't partition an slist
+iterators is foward_list - without this extension you can't partition an foward_list
(without writing your own partition). Holes like this in the standard
library weaken the argument for generic programming (ideally I'd be able
to provide a library that would refine std::partition() to other concepts
<hr>
<h3><a name="502"></a>502. Proposition: Clarification of the interaction between a facet and an iterator</h3>
-<p><b>Section:</b> 22.
1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 2005-06-07</p>
+<p><b>Section:</b> 22.
3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Opened:</b> 2005-06-07 <b>Last modified:</b> 2008-03-13</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
<p><b>View all 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>
<hr>
<h3><a name="503"></a>503. more on locales</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> P.J. Plauger <b>Date:</b> 2005-06-20</p>
+<p><b>Section:</b> 22.
4 [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> P.J. Plauger <b>Opened:</b> 2005-06-20 <b>Last modified:</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#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>
<hr>
-<h3><a name="522"></a>522. Tuple doesn't define swap</h3>
-<p><b>Section:</b> 20.4 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Andy Koenig <b>Date:</b> 2005-07-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Tuple doesn't define swap(). It should.
-</p>
-<p><i>[
-Berlin: Doug to provide wording.
-]</i></p>
-
-<p><i>[
-Batavia: Howard to provide wording.
-]</i></p>
-
-<p><i>[
-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.4 [tuple]
-</p>
-
-<blockquote><pre>template <class... Types>
- void swap(tuple<Types...>& x, tuple<Types...>& y);
-template <class... Types>
- void swap(tuple<Types...>&& x, tuple<Types...>& y);
-template <class... Types>
- void swap(tuple<Types...>& x, tuple<Types...>&& y);
-</pre></blockquote>
-
-<p>
-Add this signature to 20.4.1 [tuple.tuple]
-</p>
-
-<blockquote><pre>void swap(tuple&&);
-</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&& 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 <class... Types>
- void swap(tuple<Types...>& x, tuple<Types...>& y);
-template <class... Types>
- void swap(tuple<Types...>&& x, tuple<Types...>& y);
-template <class... Types>
- void swap(tuple<Types...>& x, tuple<Types...>&& y);
-</pre>
-
-<blockquote>
-<p>
-<i>Effects:</i> x.swap(y)
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
<h3><a name="523"></a>523. regex case-insensitive character ranges are unimplementable as specified</h3>
<p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Eric Niebler <b>Date:</b> 2005-07-01</p>
+ <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2005-07-01 <b>Last modified:</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#re">active issues</a> in [re].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
<p><b>View all 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>
<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>Section:</b> 26.
7.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Marc Schoolderman <b>Opened:</b> 2006-02-06 <b>Last modified:</b> 2009-05-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>
should specify it.
</blockquote>
+<p><i>[
+2009-05-09 Alisdair adds:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
+<blockquote>
<p>
-Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences:
+Now that we have the facility, the 'best' accumulator type could probably be
+deduced as:
</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
+<blockquote><pre>std::common_type<InIter::value_type, OutIter::reference>::type
+</pre></blockquote>
+<p>
+This type would then have additional requirements of constructability and
+incrementability/assignability.
+</p>
+<p>
+If this extracting an accumulator type from a pair/set of iterators (with
+additional requirements on that type) is a problem for multiple functions,
+it might be worth extracting into a SharedAccumulator concept or similar.
+</p>
+<p>
+I'll go no further in writing up wording now, until the group gives a
+clearer indication of preferred direction.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to section 26.7.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:
+Add to section 26.7.4 [adjacent.difference] paragraph 2 the following sentence:
</p>
<blockquote>
<hr>
<h3><a name="546"></a>546. _Longlong and _ULonglong are integer types</h3>
<p><b>Section:</b> TR1 5.1.1 [tr.rand.req] <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> 2006-01-10</p>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2007-10-09</p>
<p><b>View all 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>
<hr>
-<h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
-<p><b>Section:</b> 25.3 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 25, p8 we allow BinaryPredicates to return a type that's convertible
-to bool but need not actually be bool. That allows predicates to return
-things like proxies and requires that implementations be careful about
-what kinds of expressions they use the result of the predicate in (e.g.,
-the expression in if (!pred(a, b)) need not be well-formed since the
-negation operator may be inaccessible or return a type that's not
-convertible to bool).
-</p>
-<p>
-Here's the text for reference:
-</p>
-<blockquote><p>
- ...if an algorithm takes BinaryPredicate binary_pred as its argument
- and first1 and first2 as its iterator arguments, it should work
- correctly in the construct if (binary_pred(*first1, first2)){...}.
-</p></blockquote>
-
-<p>
-In 25.3, p2 we require that the Compare function object return true
-of false, which would seem to preclude such proxies. The relevant text
-is here:
-</p>
-<blockquote><p>
- Compare is used as a function object which returns true if the first
- argument is less than the second, and false otherwise...
-</p></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-I think we could fix this by rewording 25.3, p2 to read somthing like:
-</p>
-<blockquote><p>
--2- <tt>Compare</tt> is <del>used as a function object which returns
-<tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
-return value of the function call operator applied to an object of type
-<tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
-if the first argument of the call</ins> is less than the second, and
-<tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
-algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
-will not apply any non-constant function through the dereferenced iterator.
-</p></blockquote>
-
-
-<p><i>[
-Portland: Jack to define "convertible to bool" such that short circuiting isn't
-destroyed.
-]</i></p>
-
-
-
-
-
-<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>Section:</b> 27.
8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2007-10-10</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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>
<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>Section:</b> 27.
6.2.4.5 [streambuf.virt.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2007-10-09</p>
<p><b>View all 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>
<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>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#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-03-07 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</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.
Hinnant: This is a TR1 issue only. It is fixed in the current (N2135) WD.
</p>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree this has been fixed in the Working Draft.
+Move to NAD.
+</blockquote>
+
<p><b>Proposed resolution:</b></p>
<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>Section:</b> 27.
5.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>Opened:</b> 2006-04-12 <b>Last modified:</b> 2007-10-09</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>
<hr>
<h3><a name="580"></a>580. unused allocator members</h3>
-<p><b>Section:</b> 2
0.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>Section:</b> 2
3.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14 <b>Last modified:</b> 2009-05-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<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>
pre-Oxford: Martin provided wording.
]</i></p>
+
+<p><i>[
+2009-04-28 Pablo adds:
+]</i></p>
+
+
+<blockquote>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf">N2554</a>
+(scoped allocators),
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>
+(allocator concepts), and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2810.pdf">N2810</a>
+(allocator defects), address all of these points EXCEPT <tt>max_size()</tt>.
+So, I would add a note to that affect and re-class the defect as belonging
+to section 23.2.1 [container.requirements.general].
+</blockquote>
+
<p><b>Proposed resolution:</b></p>
<p>
-Specifically, I propose to change 23.1 [container.requirements],
+Specifically, I propose to change 23.2 [container.requirements],
p9 as follows:
</p>
<hr>
<h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
-<p><b>Section:</b> 20.
7.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
+<p><b>Section:</b> 20.
8.11.2 [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>Opened:</b> 2006-06-14 <b>Last modified:</b> 2009-03-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>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a></p>
<p>
The specialized algorithms [lib.specialized.algorithms] are specified
<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>Section:</b> 22.
4 [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>Opened:</b> 2006-06-22 <b>Last modified:</b> 2007-10-09</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>
<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>Section:</b> 23.
3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Gennaro Prota <b>Opened:</b> 2006-07-18 <b>Last modified:</b> 2009-05-30</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#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>
which, again, doesn't seem to consider fixed size containers
</p>
+<p><i>[
+2009-05-29 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+<ol type="a">
+<li>
+<p>
+star bullet 1 ("what's the effect of calling <tt>assign(T&)</tt> on a
+zero-sized array?[..]");
+</p>
+<blockquote>
+<tt>assign</tt> has been renamed to <tt>fill</tt> and the semantic of <tt>fill</tt> is now
+defined in terms of
+the free algorithm <tt>fill_n</tt>, which is well-defined for this situation.
+</blockquote>
+</li>
+<li>
+<p>
+star bullet 3 ("it would be desiderable to have a static const data
+member..."):
+</p>
+<blockquote>
+It seems that <tt>tuple_size<array<T, N> >::value</tt> as of 23.3.1.7 [array.tuple] does
+provide this functionality now.
+</blockquote>
+</li>
+</ol>
+</blockquote>
+
<p><b>Proposed resolution:</b></p>
<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>
+ <b>Submitter:</b> Daveed Vandevoorde <b>Opened:</b> 2006-04-05 <b>Last modified:</b> 2009-05-01</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#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>
</blockquote>
<pre>
- struct S {
- S(_Decimal32 const&); // Converting constructor
- };
- void f(S);
+ struct S {
+ S(_Decimal32 const&); // Converting constructor
+ };
+ void f(S);
- void f(_Decimal64);
+ void f(_Decimal64);
- void g(_Decimal32 d) {
- f(d);
- }
+ void g(_Decimal32 d) {
+ f(d);
+ }
</pre>
<blockquote>
<hr>
<h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3>
<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-15</p>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-15 <b>Last modified:</b> 2007-01-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>
<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>Section:</b> 21.
4 [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>Opened:</b> 2006-12-05 <b>Last modified:</b> 2008-03-12</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><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:
+consistent with 23.2 [container.requirements], p9 which says in part:
<blockquote>
All other constructors for these container types take an
<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>Section:</b> 23.
3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-30 <b>Last modified:</b> 2008-03-14</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><array></tt> header is given under 23.2 [sequences].
-23.2.1 [array]/paragraph 3 says:
+The <tt><array></tt> header is given under 23.3 [sequences].
+23.3.1 [array]/paragraph 3 says:
</p>
<blockquote><p>
"Unless otherwise specified, all array operations are as described in
-23.1 [container.requirements]".
+23.2 [container.requirements]".
</p></blockquote>
<p>
-However, array isn't mentioned at all in section 23.1 [container.requirements].
+However, array isn't mentioned at all in section 23.2 [container.requirements].
In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear)
-that std::array does not have in 23.2.1 [array].
+that std::array does not have in 23.3.1 [array].
</p>
<p>
Also, Table 83 "Optional sequence operations" lists several operations that
<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>
+<h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
-<p>
-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>
+
+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>
-Further notes/ideas from the lib-reflector, messages 17982-17984:
+The difference between the two forms of specification is that per
+17.5.1.4 [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>
-<blockquote>
<p>
-Add additional entries in num_punct to cover the complex separator (French would be ';').
+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>
-Insert a space before the comma, which should eliminate the ambiguity.
+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>
-Solve the problem for ordered sequences in general, perhaps with a
-dedicated facet. Then complex should use that solution.
+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>
-</blockquote>
-<p><i>[
-Bellevue:
-]</i></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>
-<blockquote>
<p>
-After much discussion, we agreed on the following: Add a footnote:
+Here's another similar example, one that existed even prior to the
+introduction of <i>Remark</i>s:
</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.]
+<code> insert(size_type pos, string, size_type, size_type)</code> is
+required to throw <code>out_of_range</code> if <code>pos >
+size()</code>.
</p>
+
<p>
-And move this to READY status.
+<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 > size()</code> are strictly speaking
+unspecified.
+</p><p>
+
</p>
-</blockquote>
+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><i>[
-Pre-Sophia Antipolis, Howard adds:
+Batavia: Alan and Pete to work.
]</i></p>
-<blockquote>
-Changed "showbase" to "showpoint" and changed from Ready to Review.
-</blockquote>
+<p><i>[
+Bellevue: Marked as NAD Editorial.
+]</i></p>
+
<p><i>[
Post-Sophia Antipolis:
+Martin indicates there is still work to be done on this issue.
+Reopened.
]</i></p>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
<blockquote>
-<p>
-I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change.
-In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready. We subsequently
-voted the footnote into the WP with "showbase".
-</p>
-<p>
-I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change.
-</p>
+Tom proposes we say that, unless specified otherwise,
+it is always the caller's responsibility to verify that supplied arguments
+meet the called function's requirements.
+If further semantics are specified
+(e.g., that the function throws under certain conditions),
+then it is up to the implementer to check those conditions.
+Alan feels strongly that our current use of Requires in this context
+is confusing, especially now that <tt>requires</tt> is a new keyword.
</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 <tt>showpoint</tt> into the output stream forces all outputs to show
-an explicit decimal point character; then all inserted complex sequences
-will extract unambiguously.]
-</blockquote>
-
<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>Section:</b> 26.
6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-28 <b>Last modified:</b> 2008-06-02</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
+Section 26.2 [numeric.requirements], p1 suggests that a
<code>valarray</code> specialization on a type <code>T</code> that
satisfies the requirements enumerated in the paragraph is itself a
valid type on which <code>valarray</code> may be instantiated
<code>valarray<valarray<T> >::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].
+26.2 [numeric.requirements].
</p>
<p>
<p><b>Proposed resolution:</b></p>
<p>
-Change 26.5.2.2 [valarray.assign], p1 as follows:
+Change 26.6.2.2 [valarray.assign], p1 as follows:
</p>
<blockquote>
</blockquote>
<p>
-Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4:
+Also add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4:
</p>
<blockquote>
<p>
-Change 26.5.2.2 [valarray.assign], p1 as follows:
+Change 26.6.2.2 [valarray.assign], p1 as follows:
</p>
<blockquote>
</blockquote>
<p>
-Add the following paragraph to 26.5.2.2 [valarray.assign], immediately after
+Add the following paragraph to 26.6.2.2 [valarray.assign], immediately after
p4:
</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> < *<i>first2</i></tt>" and "<tt>*<i>first2</i>
-< *<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>Section:</b> 23.
2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Lionel B <b>Opened:</b> 2007-02-01 <b>Last modified:</b> 2009-05-23</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">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>
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
does not absolutely mandate O(1).
</blockquote>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We observed that the wording "should" (in note a) has no effect.
+Howard prefers that O(1) size be mandated.
+It is not clear that this issue can be resolved to everyone's satisfaction,
+but Alan will provide wording nonetheless.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
<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>Section:</b>
X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-08 <b>Last modified:</b> 2009-05-01</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
+The table of allocator requirements in X [allocator.requirements] describes
<tt>allocator::address</tt> as:
</p>
<blockquote><pre>a.address(r)
allocator allocated seems overly restrictive.
</p>
+<p><i>[
+post San Francisco:
+]</i></p>
+
+
+<blockquote>
+Pablo recommends NAD Editorial, solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
+</blockquote>
+
+<p><i>[
+2009-04-28 Pablo adds:
+]</i></p>
+
+
+<blockquote>
+Tentatively-ready NAD Editorial as fixed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
+</blockquote>
+
<p><b>Proposed resolution:</b></p>
<p>
-Change 20.1.2 [allocator.requirements]:
+Change X [allocator.requirements]:
</p>
<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#Open">Open</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-25</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-02-25 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-X [func.wrap.func.undef]
+20.7.16.2 [func.wrap.func]
</p>
<p>
-The note in paragraph 2 refers to 'undefined void operators', while the
+The note in paragraph 2 refers to 'undefined void operators', while the
section declares a pair of operators returning bool.
</p>
type of these deleted functions to be?
</blockquote>
+<p><i>[
+2009-05-02 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I suggest harmonizing this issue with similar classes. E.g. in
+20.8.13.3 [util.smartptr.weak] <tt>bool</tt> return values for
+</p>
+<blockquote><pre>template <class Y> bool operator<(weak_ptr<Y> const&) const = delete;
+template <class Y> bool operator<=(weak_ptr<Y> const&) const = delete;
+template <class Y> bool operator>(weak_ptr<Y> const&) const = delete;
+template <class Y> bool operator>=(weak_ptr<Y> const&) const = delete;
+</pre></blockquote>
+
+<p>
+are used and basically all <em>newer</em> provided deleted copy assignment operators
+of type <tt>X</tt> use the canonical return type <tt>X&</tt> instead of <tt>void</tt>. Since the note
+mentioned in the issue description has now already been changed to
+</p>
+<blockquote>
+deleted overloads close possible hole in the type system
+</blockquote>
+<p>
+it seems to be of even lesser need to perform the change. Therefore
+I recommend declaring the issue as NAD.
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with Daniel's recommendation.
+</p>
+<p>
+Move to NAD.
+</p>
+</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Change 20.6.15.2 [func.wrap.func]
+Change 20.7.16.2 [func.wrap.func]
</p>
<blockquote><pre>...
private:
- // X [func.wrap.func.undef], undefined operators:
+ // 20.7.16.2 [func.wrap.func], undefined operators:
template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&);
template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&);
};
</pre></blockquote>
<p>
-Change X [func.wrap.func.undef]
+Change 20.7.16.2 [func.wrap.func]
</p>
<blockquote><pre>template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&);
<hr>
<h3><a name="659"></a>659. istreambuf_iterator should have an operator->()</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>Section:</b> 24.
6.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>Opened:</b> 2007-03-25 <b>Last modified:</b> 2009-05-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">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>
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->() const;</ins>
-istreambuf_iterator<charT,traits>& 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-></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->()</tt> is specified to be <tt>pointer</tt>,
</p>
</blockquote>
+<p><i>[
+2009-04-30 Alisdair adds:
+]</i></p>
+<blockquote>
+Note that operator-> is now a requirement in the <tt>InputIterator</tt> concept, so
+this issue cannot be ignored or existing valid programs will break when
+compiled with an 0x library.
+</blockquote>
-<hr>
+<p><i>[
+2009-05-29 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I agree with the observation that in principle the type 'pointer' may be a
+proxy, and the words highlighting this are redundant.
+</p>
+<p>
+However, in the current draught <tt>pointer</tt> is required to be exactly '<tt>charT *</tt>'
+by the derivation from <tt>std::iterator</tt>. At a minimum, the 4th parameter of
+this base class template should become unspecified. That permits the
+introduction of a proxy as a nested class in some further undocumented (not
+even exposition-only) base.
+</p>
+<p>
+It also permits the <tt>istream_iterator</tt> approach where the cached value is
+stored in the iterator itself, and the iterator serves as its own proxy for
+post-increment <tt>operator++</tt> - removing the need for the existing
+exposition-only nested class <tt>proxy</tt>.
+</p>
+<p>
+Note that the current <tt>proxy</tt> class also has exactly the right properties to
+serve as the pointer <tt>proxy</tt> too. This is likely to be a common case where an
+<tt>InputIterator</tt> does not hold internal state but delegates to another class.
+</p>
+<p>
+Proposed Resolution:
+</p>
+<p>
+In addition to the current proposal:
+</p>
+<p>
+24.6.3 [istreambuf.iterator]
+</p>
+<blockquote><pre>template<class charT, class traits = char_traits<charT> >
+class istreambuf_iterator
+ : public iterator<input_iterator_tag, charT,
+ typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT> {
+</pre></blockquote>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to the synopsis in 24.6.3 [istreambuf.iterator]:
+</p>
+
+<blockquote><pre>charT operator*() const;
+<ins>pointer operator->() const;</ins>
+istreambuf_iterator<charT,traits>& operator++();
+</pre></blockquote>
+
+<p>
+Change 24.6.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-></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="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>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2009-05-23</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
+22.4.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
+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>
the widened characters are not relevant to the parsing of the subject string.
</blockquote>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with Bill's comment above,
+in line with the first of the interpretations offered in the issue.
+Move to NAD.
+</blockquote>
+
<p><b>Proposed resolution:</b></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>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2009-05-23</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
+22.4.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
+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:
+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
+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>
]</i></p>
+<p>
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>.
+</p>
+<p><i>[
+2009-05-17 Howard adds:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
+
+<blockquote>
<p>
+I disagree that a <tt>negative_sign</tt> of "" means "there is no
+way to
+write a negative sign". The meaning requires the sentences of
+22.4.6.1.2 [locale.money.get.virtuals] p3 following that quoted above
+to be
+taken into account:
</p>
+<blockquote>
+-3- ... If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
+optional, and if no sign is detected, the result is given the sign that
+corresponds to the source of the empty string. Otherwise, the character
+in the indicated position must match the first character of <tt>pos</tt>
+or <tt>neg</tt>, and the result is given the corresponding sign. If the
+first character of <tt>pos</tt> is equal to the first character of
+<tt>neg</tt>, or if both strings are empty, the result is given a
+positive sign.
+</blockquote>
+<p>
+So a <tt>negative_sign</tt> of "" means "there is no way to write a
+negative sign" only when <tt>positive_sign</tt> is also "". However
+when <tt>negative_sign</tt> is "" and <tt>postive_sign.size() >
+0</tt>, then one writes a negative value by not writing the
+<tt>postive_sign</tt> in the position indicated by
+<tt>money_base::sign</tt>.
+For example:
+</p>
+<blockquote><pre>pattern = {symbol, sign, value, none}
+positive_sign = "+"
+negative_sign = ""
+$123 // a negative value, using optional sign
+$+123 // a positive value
+$-123 // a parse error
+</pre></blockquote>
-
-<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:
+And:
</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>
+<blockquote><pre>pattern = {symbol, sign, value, none}
+positive_sign = ""
+negative_sign = ""
+$123 // a positive value, no sign possible
+$+123 // a parse error
+$-123 // a parse error
+</pre></blockquote>
+
<p>
-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:
+And (regarding <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>):
</p>
-<blockquote><p>
-The input can successfully match only a positive sign, so the negative
-pattern is an unsuccessful match.
-</p></blockquote>
+<blockquote><pre>pattern = {symbol, sign, value, none}
+positive_sign = "-"
+negative_sign = "-"
+$123 // a parse error, sign is mandatory
+$+123 // a parse error
+$-123 // a positive value
+</pre></blockquote>
+
<p>
-[Plum ref _222612Y34, 222612Y51b]
+The text seems both unambiguous and clear to me. I recommend NAD for
+both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>. However I would have no
+objection to adding examples such as those above.
</p>
+</blockquote>
<p><i>[
-Bill to provide proposed wording and interpretation of existing wording.
+Batavia (2009-05):
]</i></p>
+<blockquote>
+<p>
+This discussion applies equally to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a> (q.v.).
+Howard has added examples above,
+and recommends either NAD or a resolution that adds his (or similar) examples
+to the Working Paper.
+</p>
+<p>
+Alan would like to rewrite paragraph 3.
+</p>
+<p>
+We recommend moving to NAD.
+Anyone who feels strongly about adding the examples
+is invited to submit corresponding wording.
+We further recommend issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a> be handled identically.
+</p>
+</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>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a></p>
+<h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
+<p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#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#Tentatively%20NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
-
-
<p>
-22.2.6.3 [locale.moneypunct], para 2 says:
+22.4.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
</p>
<blockquote><p>
-The value <tt>space</tt> indicates that at least one space is required at
-that position.
+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>
-The following objection has been raised:
+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>
-Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
+The input can successfully match only a positive sign, so the negative
+pattern is an unsuccessful match.
</p></blockquote>
<p>
-[Plum ref _22263Y22]
+[Plum ref _222612Y34, 222612Y51b]
</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.
+Bill to provide proposed wording and interpretation of existing wording.
+]</i></p>
+
+
+<p><i>[
+2009-05-17 See Howard's comments in related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>.
]</i></p>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+This discussion applies equally to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a> (q.v.).
+Howard has added examples there,
+and recommends either NAD or a resolution that adds his (or similar) examples
+to the Working Paper.
+</p>
+<p>
+We recommend moving to NAD.
+Anyone who feels strongly about adding the examples
+is invited to submit corresponding wording.
+We further recommend issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a> be handled identically.
+</p>
+</blockquote>
<p><b>Proposed resolution:</b></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>Section:</b> 22.
4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> John Salmon <b>Opened:</b> 2007-04-20 <b>Last modified:</b> 2009-03-12</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>
8.15 Additions to header <locale> [tr.c99.locale]
</p>
<p>
-In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
+In subclause 22.4.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
the line:
floatfield == ios_base::scientific %E
</p>
in this clause, ensure that the print functions generate hexadecimal
floating-point fields with a %a or %A conversion specifier, and that
the scan functions match hexadecimal floating-point fields with a %g
-conversion specifier. end note]
+conversion specifier. end note]
</p>
<p>
-Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
+Following the thread, in 22.4.2.2.2 [facet.num.put.virtuals], we find:
</p>
<p>
For conversion from a floating-point type, if (flags & fixed) != 0 or
<p>
This would seem to imply that when floatfield == fixed|scientific, the
precision of the conversion specifier is to be taken from
-str.precision(). Is this really what's intended? I sincerely hope
-that I'm either missing something or this is an oversight. Please
+str.precision(). Is this really what's intended? I sincerely hope
+that I'm either missing something or this is an oversight. Please
tell me that the committee did not intend to mandate that hex floats
(and doubles) should by default be printed as if by %.6a.
</p>
<p><i>[
Howard: I think the fundamental issue we overlooked was that with %f,
-%e, %g, the default precision was always 6. With %a the default
-precision is not 6, it is infinity. So for the first time, we need to
+%e, %g, the default precision was always 6. With %a the default
+precision is not 6, it is infinity. So for the first time, we need to
distinguish between the default value of precision, and the precision
value 6.
]</i></p>
<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#Review">Review</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
+<p><b>Section:</b> 20.7.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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#Tentatively%20Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-James Hopkin pointed out to me that if <tt>vector<T></tt> move assignment is O(1)
-(just a <tt>swap</tt>) then containers such as <tt>vector<shared_ptr<ostream>></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<shared_ptr<ostream>></tt> v1;
-<tt>vector<shared_ptr<ostream>></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>.
+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>
-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.
+Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
</p>
+<p><i>[
+2009-05-09 Alisdair adds:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
+<blockquote>
<p>
-Change 23.1 [container.requirements]:
+Now that <tt>ref/cref</tt> are constained that <tt>T</tt> must be an <tt>ObjectType</tt>, I do not
+believe there is any risk of binding <tt>ref</tt> to a temporary (which would rely on
+deducing <tt>T</tt> to be an rvalue reference type)
</p>
-
-<blockquote>
-<table border="1">
-<caption>Table 89: Container requirements</caption>
-<tbody><tr>
-<th>expression</th><th>return type</th><th>operational semantics</th>
-<th>assertion/note pre/post-condition</th><th>complexity</th>
-</tr>
-<tr>
-<td><tt>a = rv;</tt></td><td><tt>X&</tt></td>
-<td>All existing elements of <tt>a</tt> are either move assigned or destructed</td>
-<td><tt>a</tt> shall be equal to the
-value that <tt>rv</tt> had
-before this construction
-</td>
-<td><del>(Note C)</del> <ins>linear</ins></td>
-</tr>
-</tbody></table>
-
<p>
-Notes: the algorithms <tt>swap()</tt>, <tt>equal()</tt> and
-<tt>lexicographical_compare()</tt> are defined in clause 25. Those
-entries marked "(Note A)" should have constant complexity. Those entries
-marked "(Note B)" have constant complexity unless
-<tt>allocator_propagate_never<X::allocator_type>::value</tt> is
-<tt>true</tt>, in which case they have linear complexity.
-<del>Those entries
-marked "(Note C)" have constant complexity if <tt>a.get_allocator() ==
-rv.get_allocator()</tt> or if either
-<tt>allocator_propagate_on_move_assignment<X::allocator_type>::value</tt>
-is <tt>true</tt> or
-<tt>allocator_propagate_on_copy_assignment<X::allocator_type>::value</tt>
-is <tt>true</tt> and linear complexity otherwise.</del>
+However, the problem for <tt>cref</tt> remains, so I recommend retaining that deleted
+overload.
</p>
</blockquote>
-
-
<p><i>[
-post Bellevue Howard adds:
+2009-05-10 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.
+Without:
</p>
-</blockquote>
-
-<p><i>[
-post Sophia Antipolis Howard updated proposed wording:
-]</i></p>
+<blockquote><pre>template <class T> void ref(const T&& t) = delete;
+</pre></blockquote>
+<p>
+I believe this program will compile:
+</p>
+<blockquote><pre>#include <functional>
+struct A {};
+const A source() {return A();}
-<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>
+int main()
+{
+ std::reference_wrapper<const A> r = std::ref(source());
+}
+</pre></blockquote>
<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.
+I.e. in:
</p>
+<blockquote><pre>template <ObjectType T> reference_wrapper<T> ref(T& t);
+</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".
+this:
</p>
+<blockquote><pre>ref(source())
+</pre></blockquote>
+<p>
+deduces <tt>T</tt> as <tt>const A</tt>, and so:
+</p>
+<blockquote><pre>ref(const A& t)
+</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
-
<p>
-Add to 23.4 [unord]:
+will bind to a temporary (tested with a pre-concepts rvalue-ref enabled compiler).
+</p>
+<p>
+Therefore I think we still need the ref-protection. I respectfully disagree with Alisdair's
+comment and am in favor of the proposed wording as it stands. Also, CWG 606
+(noted below) has now been "favorably" resolved.
</p>
-<blockquote><pre>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
- unordered_map<Key, T, Hash, Pred, Alloc>& y);
+</blockquote>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
- unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
- unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
-template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.7 [function.objects], add the following two signatures to the synopsis:
+</p>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+<blockquote><pre>template <class T> void ref(const T&& t) = delete;
+template <class T> void cref(const T&& t) = delete;
+</pre></blockquote>
-...
-template <class Value, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Value, Hash, Pred, Alloc>& x,
- unordered_set<Value, Hash, Pred, Alloc>& y);
-<ins>template <class Value, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Value, Hash, Pred, Alloc>& x,
- unordered_set<Value, Hash, Pred, Alloc>&& y);</ins>
+<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>
-<ins>template <class Value, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Value, Hash, Pred, Alloc>&& x,
- unordered_set<Value, Hash, Pred, Alloc>& y);</ins>
-template <class Value, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x,
- unordered_multiset<Value, Hash, Pred, Alloc>& y);
+<p><i>[
+Bellevue: Doug noticed problems with the current wording.
+]</i></p>
-<ins>template <class Value, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x,
- unordered_multiset<Value, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Value, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x,
- unordered_multiset<Value, Hash, Pred, Alloc>& y);</ins>
-</pre></blockquote>
+<p><i>[
+post Bellevue: Howard and Peter provided revised wording.
+]</i></p>
-<p><b><tt>unordered_map</tt></b></p>
-<p>
-Change 23.4.1 [unord.map]:
-</p>
+<p><i>[
+This resolution depends on a "favorable" resolution of CWG 606: that is,
+the "special deduction rule" is disabled with the const T&& pattern.
+]</i></p>
-<blockquote><pre>class unordered_map
-{
- ...
- unordered_map(const unordered_map&);
- <ins>unordered_map(unordered_map&&);</ins>
- ~unordered_map();
- unordered_map& operator=(const unordered_map&);
- <ins>unordered_map& operator=(unordered_map&&);</ins>
- ...
- // modifiers
- <del>std::</del>pair<iterator, bool> insert(const value_type& obj);
- <ins>template <class P> pair<iterator, bool> insert(P&& obj);</ins>
- iterator insert(iterator hint, const value_type& obj);
- <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins>
- const_iterator insert(const_iterator hint, const value_type& obj);
- <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins>
- ...
- void swap(unordered_map&<ins>&</ins>);
- ...
- mapped_type& operator[](const key_type& k);
- <ins>mapped_type& operator[](key_type&& k);</ins>
- ...
-};
-template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
- unordered_map<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
- unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
- unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre></blockquote>
+<hr>
+<h3><a name="696"></a>696. <code>istream::operator>>(int&)</code> broken</h3>
+<p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-23 <b>Last modified:</b> 2009-05-28</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#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-Add to 23.4.1.1 [unord.map.cnstr]:
+From message c++std-lib-17897:
</p>
-
-<blockquote>
-<pre>template <class InputIterator>
- unordered_map(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher& hf = hasher(),
- const key_equal& eql = key_equal(),
- const allocator_type& 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<key_type, mapped_type></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]:
+The code shown in 27.7.1.2.2 [istream.formatted.arithmetic] as the "as if"
+implementation of the two arithmetic extractors that don't have a
+corresponding <code>num_get</code> interface (i.e., the
+<code>short</code> and <code>int</code> overloads) is subtly buggy in
+how it deals with <code>EOF</code>, overflow, and other similar
+conditions (in addition to containing a few typos).
+</p>
+<p>
+One problem is that if <code>num_get::get()</code> reaches the EOF
+after reading in an otherwise valid value that exceeds the limits of
+the narrower type (but not <code>LONG_MIN</code> or
+<code>LONG_MAX</code>), it will set <code><i>err</i></code> to
+<code>eofbit</code>. Because of the if condition testing for
+<code>(<i>err</i> == 0)</code>, the extractor won't set
+<code>failbit</code> (and presumably, return a bogus value to the
+caller).
+</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>
-<blockquote>
-
-<pre>mapped_type& operator[](const key_type& k);</pre>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
<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>
+<p>
+We believe this part of the Standard has been recently adjusted
+and that this issue was addressed during that rewrite.
+</p>
+<p>
+Move to NAD.
+</p>
</blockquote>
-<pre><ins>mapped_type& operator[](key_type&& 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<const key_type, mapped_type>(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>
+<p><i>[
+2009-05-28 Howard adds:
+]</i></p>
-</blockquote>
+<blockquote>
<p>
-Add new section [unord.map.modifiers]:
+I've moved this issue from Tentatively NAD to Open.
</p>
-<blockquote>
-<pre><ins>pair<iterator, bool> insert(const value_type& x);</ins>
-<ins>template <class P> pair<iterator, bool> insert(P&& x);</ins>
-<ins>iterator insert(iterator hint, const value_type& x);</ins>
-<ins>template <class P> iterator insert(iterator hint, P&& x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
-<ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins>
-<ins>template <class InputIterator>
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-
-<blockquote>
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const value_type&</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<const key_type,
-mapped_type></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]:
+The current wording of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
+in 22.4.2.1.2 [facet.num.get.virtuals] p3, stage 3 appears to indicate that
+in parsing arithmetic types, the value is always set, but sometimes in addition
+to setting <tt>failbit</tt>.
</p>
-<blockquote>
-<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
- unordered_map<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
- unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
- unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre>
-</blockquote>
+<ul>
+<li>
+If there is a range error, the value is set to min or max, else
+</li>
+<li>
+if there is a conversion error, the value is set to 0, else
+</li>
+<li>
+if there is a grouping error, the value is set to whatever it would be if grouping were ignored, else
+</li>
+<li>
+the value is set to its error-free result.
+</li>
+</ul>
-<p><b><tt>unordered_multimap</tt></b></p>
+<p>
+However there is a contradictory sentence in 22.4.2.1.2 [facet.num.get.virtuals] p1.
+</p>
<p>
-Change 23.4.2 [unord.multimap]:
+27.7.1.2.2 [istream.formatted.arithmetic] should mimic the behavior of 22.4.2.1.2 [facet.num.get.virtuals]
+(whatever we decide that behavior is) for
+<tt>int</tt> and <tt>short</tt>, and currently does not. I believe that the
+correct code fragment should look like:
</p>
-<blockquote><pre>class unordered_multimap
+<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
+iostate err = ios_base::goodbit;
+long lval;
+use_facet<numget>(loc).get(*this, 0, *this, err, lval);
+if (lval < numeric_limits<int>::min())
{
- ...
- unordered_multimap(const unordered_multimap&);
- <ins>unordered_multimap(unordered_multimap&&);</ins>
- ~unordered_multimap();
- unordered_multimap& operator=(const unordered_multimap&);
- <ins>unordered_multimap& operator=(unordered_multimap&&);</ins>
- ...
- // modifiers
- iterator insert(const value_type& obj);
- <ins>template <class P> iterator insert(P&& obj);</ins>
- iterator insert(iterator hint, const value_type& obj);
- <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins>
- const_iterator insert(const_iterator hint, const value_type& obj);
- <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins>
- ...
- void swap(unordered_multimap&<ins>&</ins>);
- ...
-};
-
-template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
-
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+ err |= ios_base::failbit;
+ val = numeric_limits<int>::min();
+}
+else if (lval > numeric_limits<int>::max())
+{
+ err |= ios_base::failbit;
+ val = numeric_limits<int>::max();
+}
+else
+ val = static_cast<int>(lval);
+setstate(err);
</pre></blockquote>
+</blockquote>
+
+<p><b>Proposed resolution:</b></p>
<p>
-Add to 23.4.2.1 [unord.multimap.cnstr]:
+Change 22.4.2.1.2 [facet.num.get.virtuals], p1:
</p>
<blockquote>
-<pre>template <class InputIterator>
- unordered_multimap(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher& hf = hasher(),
- const key_equal& eql = key_equal(),
- const allocator_type& 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<key_type, mapped_type></tt>,
-then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
-<tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
+-1- <i>Effects:</i> Reads characters from <tt>in</tt>, interpreting them
+according to <tt>str.flags()</tt>, <tt>use_facet<ctype<charT>
+>(loc)</tt>, and <tt>use_facet< numpunct<charT>
+>(loc)</tt>, where <tt>loc</tt> is <tt>str.getloc()</tt>. <del>If an error
+occurs, <tt>val</tt> is unchanged; otherwise it is set to the resulting value.</del>
</blockquote>
<p>
-Add new section [unord.multimap.modifiers]:
+Change 27.7.1.2.2 [istream.formatted.arithmetic], p2 and p3:
</p>
<blockquote>
-<pre><ins>iterator insert(const value_type& x);</ins>
-<ins>template <class P> iterator insert(P&& x);</ins>
-<ins>iterator insert(iterator hint, const value_type& x);</ins>
-<ins>template <class P> iterator insert(iterator hint, P&& x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
-<ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins>
-<ins>template <class InputIterator>
- void insert(InputIterator first, InputIterator last);</ins>
+<pre>operator>>(short& val);
</pre>
-
<blockquote>
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const value_type&</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<const key_type,
-mapped_type></tt>, then <tt>key_type</tt> must be
-<tt>CopyConstructible</tt>).
-</ins></p>
+<p>
+-2- The conversion occurs as if performed by the following code fragment (using the same notation as for
+the preceding code fragment):
+</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><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
+iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
+long lval;
+use_facet<numget>(loc).get(*this, 0, *this, err, lval);
+<del>if (err != 0)
+ ;
+else if (lval < numeric_limits<short>::min()
+ || numeric_limits<short>::max() < lval)
+ err = ios_base::failbit;</del>
+<ins>if (lval < numeric_limits<short>::min())
+{
+ err |= ios_base::failbit;
+ val = numeric_limits<short>::min();
+}
+else if (lval > numeric_limits<short>::max())
+{
+ err |= ios_base::failbit;
+ val = numeric_limits<short>::max();
+}</ins>
+else
+ val = static_cast<short>(lval);
+setstate(err);
+</pre></blockquote>
</blockquote>
+<pre>operator>>(int& val);
+</pre>
+<blockquote>
<p>
-Add to 23.4.2.2 [unord.multimap.swap]:
+-3- The conversion occurs as if performed by the following code fragment (using the same notation as for
+the preceding code fragment):
</p>
-<blockquote>
-<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre>
-</blockquote>
+<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
+iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
+long lval;
+use_facet<numget>(loc).get(*this, 0, *this, err, lval);
+<del>if (err != 0)
+ ;
+else if (lval < numeric_limits<int>::min()
+ || numeric_limits<int>::max() < lval)
+ err = ios_base::failbit;</del>
+<ins>if (lval < numeric_limits<int>::min())
+{
+ err |= ios_base::failbit;
+ val = numeric_limits<int>::min();
+}
+else if (lval > numeric_limits<int>::max())
+{
+ err |= ios_base::failbit;
+ val = numeric_limits<int>::max();
+}</ins>
+else
+ val = static_cast<int>(lval);
+setstate(err);
+</pre></blockquote>
-<p><b><tt>unordered_set</tt></b></p>
+</blockquote>
-<p>
-Change 23.4.3 [unord.set]:
-</p>
+</blockquote>
-<blockquote><pre>class unordered_set
-{
- ...
- unordered_set(const unordered_set&);
- <ins>unordered_set(unordered_set&&);</ins>
- ~unordered_set();
- unordered_set& operator=(const unordered_set&);
- <ins>unordered_set& operator=(unordered_set&&);</ins>
- ...
- // modifiers
- <del>std::</del>pair<iterator, bool> insert(const value_type& obj);
- <ins>pair<iterator, bool> insert(value_type&& obj);</ins>
- iterator insert(iterator hint, const value_type& obj);
- <ins>iterator insert(iterator hint, value_type&& obj);</ins>
- const_iterator insert(const_iterator hint, const value_type& obj);
- <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins>
- ...
- void swap(unordered_set&<ins>&</ins>);
- ...
-};
-template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
- unordered_set<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
- unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x,
- unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre></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#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Christopher Crawford <b>Opened:</b> 2007-06-30 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</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 > -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 & 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>
-Add to 23.4.3.1 [unord.set.cnstr]:
+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>
-<blockquote>
-<pre>template <class InputIterator>
- unordered_set(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher& hf = hasher(),
- const key_equal& eql = key_equal(),
- const allocator_type& a = allocator_type());
-</pre>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
-<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>
+We understand the issue, and have opted not to extend as recommended.
+</p>
+<p>
+Move to NAD.
+</p>
</blockquote>
+
+<p><b>Proposed resolution:</b></p>
<p>
-Add new section [unord.set.modifiers]:
</p>
-<blockquote>
-<pre><ins>pair<iterator, bool> insert(const value_type& x);</ins>
-<ins>pair<iterator, bool> insert(value_type&& x);</ins>
-<ins>iterator insert(iterator hint, const value_type& x);</ins>
-<ins>iterator insert(iterator hint, value_type&& x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
-<ins>const_iterator insert(const_iterator hint, value_type&& x);</ins>
-<ins>template <class InputIterator>
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-<blockquote>
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const
-value_type&</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>
+<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#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Christopher Crawford <b>Opened:</b> 2007-06-30 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</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| <= 1</tt>, not <tt>x >= 0</tt>.</p>
-</blockquote>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+<blockquote>
<p>
-Add to 23.4.3.2 [unord.set.swap]:
+The error has been corrected in the pending IS.
+</p>
+<p>
+Move to NAD.
</p>
-
-<blockquote>
-<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
- unordered_set<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
- unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x,
- unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre>
</blockquote>
-<p><b><tt>unordered_multiset</tt></b></p>
+<p><b>Proposed resolution:</b></p>
<p>
-Change 23.4.4 [unord.multiset]:
</p>
-<blockquote><pre>class unordered_multiset
-{
- ...
- unordered_multiset(const unordered_multiset&);
- <ins>unordered_multiset(unordered_multiset&&);</ins>
- ~unordered_multiset();
- unordered_multiset& operator=(const unordered_multiset&);
- <ins>unordered_multiset& operator=(unordered_multiset&&);</ins>
- ...
- // modifiers
- iterator insert(const value_type& obj);
- <ins>iterator insert(value_type&& obj);</ins>
- iterator insert(iterator hint, const value_type& obj);
- <ins>iterator insert(iterator hint, value_type&& obj);</ins>
- const_iterator insert(const_iterator hint, const value_type& obj);
- <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins>
- ...
- void swap(unordered_multiset&<ins>&</ins>);
- ...
-};
-template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
- unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
- unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x,
- unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre></blockquote>
+<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>Opened:</b> 2007-07-28 <b>Last modified:</b> 2008-09-17</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</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>
-Add to 23.4.4.1 [unord.multiset.cnstr]:
+The POSIX "Extended API Set Part 4,"
</p>
-
-<blockquote>
-<pre>template <class InputIterator>
- unordered_multiset(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher& hf = hasher(),
- const key_equal& eql = key_equal(),
- const allocator_type& 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>
+<a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
</p></blockquote>
-</blockquote>
-
<p>
-Add new section [unord.multiset.modifiers]:
+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>
-
-<blockquote>
-<pre><ins>iterator insert(const value_type& x);</ins>
-<ins>iterator insert(value_type&& x);</ins>
-<ins>iterator insert(iterator hint, const value_type& x);</ins>
-<ins>iterator insert(iterator hint, value_type&& x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
-<ins>const_iterator insert(const_iterator hint, value_type&& x);</ins>
-<ins>template <class InputIterator>
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-
-<blockquote>
-
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const
-value_type&</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.4.2 [unord.multiset.swap]:
+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>
+<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.
+</p>
+<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>.
</p>
-
-<blockquote>
-<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
- unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
- unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x,
- unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre>
-</blockquote>
-
-
<p><i>[
-Voted to WP in Bellevue.
+Kona (2007): Bill and Nick to provide wording.
]</i></p>
<p><i>[
-post Bellevue, Pete notes:
+San Francisco: Bill and Nick still intend to provide wording, but this
+is a part of the task to be addressed by the group that will look into
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>.
]</i></p>
-<blockquote>
-<p>
-Please remind people who are reviewing issues to check that the text
-modifications match the current draft. Issue 676, for example, adds two
-overloads for unordered_map::insert taking a hint. One takes a
-const_iterator and returns a const_iterator, and the other takes an
-iterator and returns an iterator. This was correct at the time the issue
-was written, but was changed in Toronto so there is only one hint
-overload, taking a const_iterator and returning an iterator.
-</p>
+
+
+<p><b>Proposed resolution:</b></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>
+
<hr>
-<h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
-<p><b>Section:</b> 20.
6.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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>
+<h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
+<p><b>Section:</b> 20.
8.13.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-08-24 <b>Last modified:</b> 2008-06-18</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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#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>
-
-<p>
-Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+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><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><b>Proposed resolution:</b></p>
<p>
-In 20.6 [function.objects], add the following two signatures to the synopsis:
+after the aliasing constructor
</p>
-<blockquote><pre>template <class T> void ref(const T&& t) = delete;
-template <class T> void cref(const T&& t) = delete;
+<blockquote><pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
</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>
+This is contradicted by the second sentence in the Returns clause of 20.8.13.2.5 [util.smartptr.shared.obs]:
+</p>
-<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>
-
+<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: Doug noticed problems with the current wording.
+Bellevue:
]</i></p>
-<p><i>[
-post Bellevue: Howard and Peter provided revised wording.
-]</i></p>
-
+<blockquote>
+<p>
+Adopt option 1 and move to review, not ready.
+</p>
+<p>
+There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
+isn't defined anywhere), and whether we have a good mental model for how
+one behaves. We think it might be possible to deduce what the definition
+should be, but the words just aren't there. We need to open an issue on
+the use of this undefined term. (The resolution of that issue might
+affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.)
+</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><i>[
-This resolution depends on a "favorable" resolution of CWG 606: that is,
-the "special deduction rule" is disabled with the const T&& pattern.
+Sophia Antipolis:
]</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#Ready">Ready</a>
- <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2007-06-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</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:
+We heard from Peter Dimov, who explained his reason for preferring solution 1.
+</p>
+<p>
+Because it doesn't seem to add anything. It simply makes the behavior
+for p = 0 undefined. For programmers who don't create empty pointers
+with p = 0, there is no difference. Those who do insist on creating them
+presumably have a good reason, and it costs nothing for us to define the
+behavior in this case.
+</p>
+<p>
+The aliasing constructor is sharp enough as it is, so "protecting" users
+doesn't make much sense in this particular case.
+</p>
+<p>
+> Do you have a use case for r being empty and r being non-null?
</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.
+I have received a few requests for it from "performance-conscious"
+people (you should be familiar with this mindset) who don't like the
+overhead of allocating and maintaining a control block when a null
+deleter is used to approximate a raw pointer. It is obviously an "at
+your own risk", low-level feature; essentially a raw pointer behind a
+shared_ptr facade.
</p>
<p>
-Is this really an oversight, or am I missing something?
+We could not agree upon a resolution to the issue; some of us thought
+that Peter's description above is supporting an undesirable behavior.
</p>
+</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Add the following two rows to table 93 (unordered associative container
-requirements) in section 23.1.5 [unord.req]:
+In keeping the N2351 spirit and obviously my preference, change 20.8.13.2.5 [util.smartptr.shared.obs]:
</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>
+<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>
-Add to the synopsis in 23.4.1 [unord.map]:
+Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
</p>
-<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;</ins>
-</pre></blockquote>
-
<p>
-Add to the synopsis in 23.4.2 [unord.multimap]:
+Change 20.8.13.2.1 [util.smartptr.shared.const]:
</p>
-<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;</ins>
-</pre></blockquote>
-
+<blockquote>
+<pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
+</pre>
+<blockquote>
<p>
-Add to the synopsis in 23.4.3 [unord.set]:
+<ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins>
</p>
-
-<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;</ins>
-</pre></blockquote>
-
<p>
-Add to the synopsis in 23.4.4 [unord.multiset]:
+<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>
-
-<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;</ins>
-</pre></blockquote>
+</blockquote>
+</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#Review">Review</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
+<p><b>Section:</b> 28.14 [re.grammar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-08-31 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-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.
+TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.14 [re.grammar]/3 say:
</p>
+
+<blockquote>
<p>
-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.
+The following productions within the ECMAScript grammar are modified as follows:
</p>
-<p>
-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>
+<blockquote><pre>CharacterClass ::
+[ [lookahead ∉ {^}] ClassRanges ]
+[ ^ ClassRanges ]
+</pre></blockquote>
+
+</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:
+This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
</p>
-<blockquote><p>
-<i>Effects</i>: The expression <code><i>in</i> >> 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:
+Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
</p>
-<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<charT,
-traits></code> then the expression <code><i>in</i> >> 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:
+Batavia (2009-05):
]</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>>(int&)</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>
-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).
-</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).
+We agree that what is specified is identical to what ECMA-262 specifies.
+Pete would like to take a bit of time to assess whether we had intended,
+but failed, to make a change.
+It would also be useful to hear from John Maddock on the issue.
</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.
+Move to Open.
</p>
+</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
+Remove this mention of the CharacterClass production.
</p>
+<blockquote><pre><del>CharacterClass ::
+[ [lookahead ∉ {^}] ClassRanges ]
+[ ^ ClassRanges ]</del>
+</pre></blockquote>
+
+
<hr>
-<h3><a name="698"></a>698. <tt>system_error</tt> needs <tt>const char*</tt> constructors</h3>
-<p><b>Section:</b> 19.4.5.1 [syserr.syserr.overview] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-24</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3>
+<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-08-18 <b>Last modified:</b> 2008-03-12</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>
-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&</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>.
+Paragraph 21.4 [basic.string]/3 states:
</p>
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
<p>
-This proposed wording assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a> has been accepted and applied to the working paper.
+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>
-Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview, as indicated:
+First of all, 23.2.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container".
+Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>,
+<tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not
+even close to conform to the current requirements.
</p>
-<blockquote><pre>public:
- system_error(error_code ec, const string& what_arg);
- <ins>system_error(error_code ec, const char* what_arg);</ins>
- system_error(error_code ec);
- system_error(int ev, const error_category* ecat,
- const string& what_arg);
- <ins>system_error(int ev, const error_category* ecat,
- const char* what_arg);</ins>
- system_error(int ev, const error_category* ecat);
-</pre></blockquote>
+<p><i>[
+Bellevue:
+]</i></p>
-<p>
-To 19.4.5.2 [syserr.syserr.members] Class system_error members add:
-</p>
<blockquote>
-<pre>system_error(error_code ec, const char* what_arg);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
-</p>
+<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>
-<pre>system_error(int ev, const error_category* ecat, const char* what_arg);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
-</p>
+
+<p><b>Proposed resolution:</b></p>
<p>
-<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
+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>
-</blockquote>
-</blockquote>
-
<hr>
-<h3><a name="701"></a>701. assoc laguerre poly's</h3>
-<p><b>Section:</b> TR1 5.2.1.1 [tr.num.sf.Lnm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
-<p><b>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.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-25 <b>Last modified:</b> 2009-03-14</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<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 > -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 & 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>
-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>.
+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="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| <= 1</tt>, not <tt>x >= 0</tt>.</p>
-
-
-<p><b>Proposed resolution:</b></p>
<p>
+I strongly suggest that the standard provides a type traits for
+literal types in 20.6.4.3 [meta.unary.prop] for several reasons:
</p>
+<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>
-
-
-
-<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>.
+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>
-<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>
+<blockquote>
+<ul>
+<li>at least one constexpr constructor other than the copy constructor,</li>
+</ul>
+</blockquote>
-<table border="1">
-<caption>Container Requirements</caption>
-<tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
-<tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> and containers with a <tt>propagate_never</tt> allocator require <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr>
-<tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
- Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>.
- Sequences and Associative containers with <tt>propagate_never</tt> and <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> and containers with <tt>propagate_never</tt> and
- <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr>
-</tbody></table>
-<p>
-</p>
-<table border="1">
-<caption>Sequence Requirements</caption>
-<tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
-<tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
-<tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
-<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
- The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
-<tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
- If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
- The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
-<tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.clear()</tt></td><td></td></tr>
-<tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
- If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
-<tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
- The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-</tbody></table>
+<p><i>[
+Alisdair is considering preparing a paper listing a number of missing
+type traits, and feels that it might be useful to handle them all
+together rather than piecemeal. This would affect issue 719 and 750.
+These two issues should move to OPEN pending AM paper on type traits.
+]</i></p>
+
-<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><b>Proposed resolution:</b></p>
<p>
+In 20.6.2 [meta.type.synop] in the group "type properties",
+just below the line
</p>
-<table border="1">
-<caption>Associative Container Requirements</caption>
-<tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
-</tbody></table>
+<blockquote><pre>template <class T> struct is_pod;
+</pre></blockquote>
<p>
+add a new one:
</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>
+<blockquote><pre>template <class T> struct is_literal;
+</pre></blockquote>
<p>
+In 20.6.4.3 [meta.unary.prop], table Type Property Predicates, just
+below the line for the <tt>is_pod</tt> property add a new line:
</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><tr>
+<th>Template</th><th>Condition</th><th>Preconditions</th>
+</tr>
+<tr>
+<td><tt>template <class T> 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><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>
-
<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="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3>
+<p><b>Section:</b> 22.3.3.2.2 [conversions.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>Opened:</b> 2007-08-27 <b>Last modified:</b> 2008-09-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#conversions.string">active issues</a> in [conversions.string].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#conversions.string">issues</a> in [conversions.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>
-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>
-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>
-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>
-<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.
+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>
-<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>.
+How are we going to explain this code to beginning programmers?
</p>
+<blockquote><pre>template<class I, class E, class S>
+struct codecvt : std::codecvt<I, E, S>
+{
+ ~codecvt()
+ { }
+};
+
+void main()
+{
+ std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok;
+
+ std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> > not_ok;
+}
+</pre></blockquote>
+
<p><i>[
-Kona (2007): Bill and Nick to provide wording.
+San Francisco:
]</i></p>
+<blockquote>
+Bill will propose a resolution.
+</blockquote>
<p><b>Proposed resolution:</b></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#Review">Review</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
+<p><b>Section:</b> 28.9 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-29 <b>Last modified:</b> 2009-03-13</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#Open">Open</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>&</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>Addresses UK 316</b></p>
-
-<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
+According to the current state of the standard draft, the class
+template <tt>basic_regex</tt>, as described in 28.9 [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>
-<blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c);
-</pre></blockquote>
-
-
-
<p><i>[
-Bellevue:
+Sophia Antipolis:
]</i></p>
<blockquote>
-Resolution: NAD editorial - up to Pete's judgment
+Needs wording for the semantics, the idea is agreed upon.
</blockquote>
<p><i>[
-Post Sophia Antipolis
+Post Summit Daniel updated wording to reflect new "swap rules".
]</i></p>
-<blockquote>
-Moved from Pending NAD Editorial to Review. The proposed wording appears to be correct but non-editorial.
-</blockquote>
-
-
-
-<hr>
-<h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</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 the class definition of <tt>basic_regex</tt>, just below 28.9 [re.regex]/3,
+perform the following changes:
</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>
-
+<ol type="a">
+<li>
<p>
-after the aliasing constructor
+Just after <tt>basic_regex(const basic_regex&);</tt> insert:
</p>
-<blockquote><pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
+<blockquote><pre>basic_regex(basic_regex&&);
</pre></blockquote>
-
+</li>
+<li>
<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.
+Just after <tt>basic_regex& operator=(const basic_regex&);</tt> insert:
</p>
-
+<blockquote><pre>basic_regex& operator=(basic_regex&&);
+</pre></blockquote>
+</li>
+<li>
<p>
-This is contradicted by the second sentence in the Returns clause of 20.7.12.2.5 [util.smartptr.shared.obs]:
-</p>
-
-<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>
-Adopt option 1 and move to review, not ready.
-</p>
-<p>
-There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
-isn't defined anywhere), and whether we have a good mental model for how
-one behaves. We think it might be possible to deduce what the definition
-should be, but the words just aren't there. We need to open an issue on
-the use of this undefined term. (The resolution of that issue might
-affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.)
+Just after <tt>basic_regex& assign(const basic_regex& that);</tt> insert:
</p>
+<blockquote><pre>basic_regex& assign(basic_regex&& that);
+</pre></blockquote>
+</li>
+<li>
<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.
+In 28.9.2 [re.regex.construct], just after p.11 add the following
+new member definition:
</p>
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
+<blockquote><pre>basic_regex(basic_regex&& e);
+</pre>
<blockquote>
<p>
-We heard from Peter Dimov, who explained his reason for preferring solution 1.
-</p>
-<p>
-Because it doesn't seem to add anything. It simply makes the behavior
-for p = 0 undefined. For programmers who don't create empty pointers
-with p = 0, there is no difference. Those who do insist on creating them
-presumably have a good reason, and it costs nothing for us to define the
-behavior in this case.
-</p>
-<p>
-The aliasing constructor is sharp enough as it is, so "protecting" users
-doesn't make much sense in this particular case.
-</p>
-<p>
-> Do you have a use case for r being empty and r being non-null?
+<i>Effects:</i> Move-constructs a <tt>basic_regex</tt> instance from <tt>e</tt>.
</p>
<p>
-I have received a few requests for it from "performance-conscious"
-people (you should be familiar with this mindset) who don't like the
-overhead of allocating and maintaining a control block when a null
-deleter is used to approximate a raw pointer. It is obviously an "at
-your own risk", low-level feature; essentially a raw pointer behind a
-shared_ptr facade.
+<i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>e.flags()</tt> and
+<tt>e.mark_count()</tt>, respectively,
+that <tt>e</tt> had before construction, leaving
+<tt>e</tt> in a valid state with an unspecified value.
</p>
<p>
-We could not agree upon a resolution to the issue; some of us thought
-that Peter's description above is supporting an undesirable behavior.
+<i>Throws:</i> nothing.
</p>
</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
+</blockquote>
+</li>
+<li>
<p>
-In keeping the N2351 spirit and obviously my preference, change 20.7.12.2.5 [util.smartptr.shared.obs]:
+Also in 28.9.2 [re.regex.construct], just after p.18 add the
+following new member definition:
</p>
-<blockquote>
-<pre>T* get() const;
+<blockquote><pre>basic_regex& operator=(basic_regex&& e);
</pre>
-<blockquote><p>
-<i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
-</p></blockquote>
+<blockquote>
+<i>Effects:</i> Returns the result of <tt>assign(std::move(e))</tt>.
</blockquote>
-
-<p>
-Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
-</p>
-
+</blockquote>
+</li>
+<li>
<p>
-Change 20.7.12.2.1 [util.smartptr.shared.const]:
+In 28.9.3 [re.regex.assign], just after p. 2 add the following new
+member definition:
</p>
-
-<blockquote>
-<pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
+<blockquote><pre>basic_regex& assign(basic_regex&& rhs);
</pre>
<blockquote>
<p>
-<ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins>
+<i>Effects:</i> Move-assigns a <tt>basic_regex</tt> instance from <tt>rhs</tt> and returns <tt>*this</tt>.
</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>
+<i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>rhs.flags()</tt>
+and <tt>rhs.mark_count()</tt>, respectively, that
+<tt>rhs</tt> had before assignment, leaving <tt>rhs</tt>
+in a valid state with an unspecified value.
+</p>
+<p>
+<i>Throws:</i> nothing.
</p>
</blockquote>
</blockquote>
-
+</li>
+</ol>
<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#Ready">Ready</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
+<p><b>Section:</b> 28.12.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22 <b>Last modified:</b> 2008-06-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-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.
+Two overloads of <tt>regex_replace()</tt> are currently provided:
</p>
+<blockquote><pre>template <class OutputIterator, class BidirectionalIterator,
+ class traits, class charT>
+ OutputIterator
+ regex_replace(OutputIterator out,
+ BidirectionalIterator first, BidirectionalIterator last,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+
+template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const basic_string<charT>& s,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& 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 << regex_replace(s, r, "y") << endl;
+</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:
+The compiler error message will be something like "could not deduce
+template argument for 'const std::basic_string<_Elem> &' from 'const
+char[1]'".
</p>
-<blockquote>
<p>
-<i>Complexity:</i> <del>Approximately</del> <ins>O(</ins><i>N</i> log(<i>N</i>)<ins>)</ins> (where <i>N</i> == <i>last</i> - <i>first</i> )
-comparisons<del> on the average</del>.<del><sup>266)</sup></del>
+Users expect that anything taking a <tt>basic_string<charT></tt> can also take a
+<tt>const charT *</tt>. In their own code, when they write a function taking
+<tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
+wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor. Because the
+regex algorithms are templated on <tt>charT</tt>, they can't rely on
+<tt>basic_string</tt>'s implicit constructor (as the compiler error message
+indicates, template argument deduction fails first).
</p>
+
<p>
-<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>
+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>
-</blockquote>
-
+</li>
+<li>
+There is an efficiency consideration: constructing <tt>basic_string</tt>s can
+impose performance costs that could be avoided by a library
+implementation taking C strings and dealing with them directly.
+(Currently, for replacement sources, C strings can be converted into
+iterator pairs at the cost of verbosity, but for format strings, there
+is no way to avoid constructing a <tt>basic_string</tt>.)
+</li>
+</ol>
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+<blockquote>
+We note that Boost already has these overloads. However, the proposed
+wording is provided only for 28.12.4 [re.alg.replace]; wording is needed for the synopsis
+as well. We also note that this has impact on <tt>match_results::format</tt>,
+which may require further overloads.
+</blockquote>
-<hr>
-<h3><a name="714"></a>714. <tt>search_n</tt> complexity is too lax</h3>
-<p><b>Section:</b> 25.1.12 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The complexity for <tt>search_n</tt> (25.1.12 [alg.search] par 7) is specified as "At most
-(last - first ) * count applications of the corresponding predicate if
-count is positive, or 0 otherwise." This is unnecessarily pessimistic.
-Regardless of the value of count, there is no reason to examine any
-element in the range more than once.
-</p>
<p><b>Proposed resolution:</b></p>
<p>
-Change the complexity to "At most (last - first) applications of the corresponding predicate".
+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.12.4 [re.alg.replace]:
</p>
<blockquote>
-<pre>template<class ForwardIterator, class Size, class T>
- ForwardIterator
- search_n(ForwardIterator first , ForwardIterator last , Size count ,
- const T& value );
+<pre>template <class OutputIterator, class BidirectionalIterator,
+ class traits, class charT>
+ OutputIterator
+ regex_replace(OutputIterator out,
+ BidirectionalIterator first, BidirectionalIterator last,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+
+<ins>template <class OutputIterator, class BidirectionalIterator,
+ class traits, class charT>
+ OutputIterator
+ regex_replace(OutputIterator out,
+ BidirectionalIterator first, BidirectionalIterator last,
+ const basic_regex<charT, traits>& e,
+ const charT* fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);</ins>
+</pre>
+<p>...</p>
+<pre>template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const basic_string<charT>& s,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+
+<ins>template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const basic_string<charT>& s,
+ const basic_regex<charT, traits>& e,
+ const charT* fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);</ins>
+
+<ins>template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const charT* s,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);</ins>
-template<class ForwardIterator, class Size, class T,
- class BinaryPredicate>
- ForwardIterator
- search_n(ForwardIterator first , ForwardIterator last , Size count ,
- const T& value , BinaryPredicate pred );
+<ins>template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const charT* s,
+ const basic_regex<charT, traits>& e,
+ const charT* fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);</ins>
</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>.
-</p>
-</blockquote>
</blockquote>
<hr>
-<h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
-<p><b>Section:</b> 28.13 [re.grammar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-08-31</p>
-<p><b>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="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.12.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
+<tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string<charT, ST,
+SA>&</tt>. <tt>regex_replace()</tt> takes <tt>const basic_string<charT>&</tt>. This prevents
+<tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
+allocators.
</p>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
<blockquote>
<p>
-The following productions within the ECMAScript grammar are modified as follows:
+Bill comments, "We need to look at the depth of this change."
</p>
-
-<blockquote><pre>CharacterClass ::
-[ [lookahead ∉ {^}] ClassRanges ]
-[ ^ ClassRanges ]
-</pre></blockquote>
-
-</blockquote>
-
<p>
-This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
+Pete remarks that we are here dealing with a convenience function
+that saves a user from calling the iterato-based overload.
</p>
-
<p>
-Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
+Move to Open.
</p>
+</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Remove this mention of the CharacterClass production.
+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<charT, ST,
+SA>&</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>
-<blockquote><pre><del>CharacterClass ::
-[ [lookahead ∉ {^}] ClassRanges ]
-[ ^ ClassRanges ]</del>
-</pre></blockquote>
-
-
<hr>
-<h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3>
-<p><b>Section:</b> 2
1.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> 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="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3>
+<p><b>Section:</b> 2
0.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-03-11</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>
-Paragraph 21.3 [basic.string]/3 states:
+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>
+<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>
-The class template <tt>basic_string</tt> conforms to the requirements for a
-Sequence (23.1.1) and for a Reversible Container (23.1).
+What level of magic do we expect to deduce if this is known?
+</p>
+<p>
+E.g.
</p>
-</blockquote>
+<blockquote><pre>struct test{
+ int x;
+ test() : x() {}
+};
+</pre></blockquote>
<p>
-First of all, 23.1.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container".
-Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>,
-<tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not
-even close to conform to the current requirements.
+Should I expect a conforming compiler to
+ <tt>assert( has_nothrow_constructor<test>::value )</tt>
+</p>
+<p>
+Is this a QoI issue?
+</p>
+<p>
+Should I expect to 'know' only if-and-only-if there is an inline definition
+available?
+</p>
+<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?
+</p>
+<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.
+</p>
+<p>
+(agreement since is that trivial ops and explicit no-throws are required.
+Open if QoI should be allowed to detect further)
</p>
<p><i>[
<blockquote>
-<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.
+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>
-
<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>
<hr>
-<h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
-<p><b>Section:</b> 20.5 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
+<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.6.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>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-03-11</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.rel">active issues</a> in [meta.rel].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.rel">issues</a> in [meta.rel].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>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:
+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><i>[
+Bellevue:
+]</i></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>
+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>
-I strongly suggest that the standard provides a type traits for
-literal types in 20.5.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>
-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>
-<p>
-Here follows a simply example to demonstrate it's usefulness:
-</p>
-<blockquote><pre>template <typename T>
-constexpr typename std::enable_if<std::is_literal<T>::value, T>::type
-abs(T x) {
- return x < T() ? -x : x;
-}
-template <typename T>
-typename std::enable_if<!std::is_literal<T>::value, T>::type
-abs(const T& x) {
- return x < T() ? -x : x;
-}
-</pre></blockquote>
+<hr>
+<h3><a name="751"></a>751. change pass-by-reference members of <tt>vector<bool></tt> to pass-by-value?</h3>
+<p><b>Section:</b> 23.3.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-22</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#Open">Open</a> status.</p>
+<p><b>Discussion:</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&</tt> we could decide to
-use <tt>T&&</tt>, but that is another issue).
+A number of vector<bool> members take const bool& 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>[
-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.
+post Bellevue:
]</i></p>
-
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
<p>
-In 20.5.2 [meta.type.synop] in the group "type properties",
-just below the line
+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>
-
-<blockquote><pre>template <class T> struct is_pod;
-</pre></blockquote>
-
<p>
-add a new one:
+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>
-
-<blockquote><pre>template <class T> struct is_literal;
-</pre></blockquote>
-
<p>
-In 20.5.4.3 [meta.unary.prop], table Type Property Predicates, just
-below the line for the <tt>is_pod</tt> property add a new line:
+Many in the group feel that for vector<bool>, this is a "don't care",
+and that at this point in the process it's not worth the bandwidth.
</p>
-
-<table border="1">
-<tbody><tr>
-<th>Template</th><th>Condition</th><th>Preconditions</th>
-</tr>
-<tr>
-<td><tt>template <class T> struct is_literal;</tt></td>
-<td><tt>T</tt> is a literal type (3.9)</td>
-<td><tt>T</tt> shall be a complete type, an
-array of unknown bound, or
-(possibly cv-qualified) <tt>void</tt>.</td>
-</tr>
-</tbody></table>
-
-
-
-
-
-
-<hr>
-<h3><a name="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#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<ol>
-<li>
-The member function <tt>bool array<T,N>::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<N>::test() const</tt> must be a
-<tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
-bitset<N>::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
-</li>
-<li>
-I wonder how the constructor <tt>bitset<N>::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>
+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><i>[
-Sophia Antipolis:
+San Francisco:
]</i></p>
<blockquote>
<p>
-We handle this as two parts
+This is really a clause 17 issue, rather than something specific to vector<bool>.
+</p>
+<p>
+Move to Open. Alisdair to provide a resolution. Alternately, Howard can
+close this as NAD and then open a new issue to handle the general issue
+(rather than the vector<bool> one).
</p>
-<ol>
-<li>
-The proposed resolution is correct; move to ready.
-</li>
-<li>
-The issue points out a real problem, but the issue is larger than just
-this solution. We believe a paper is needed, applying the full new
-features of C++ (including extensible literals) to update <tt>std::bitset</tt>.
-We note that we do not consider this new work, and that is should be
-handled by the Library Working Group.
-</li>
-</ol>
<p>
-In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution.
+Howard: Haven't yet opened new issue. Lacking wording for it.
</p>
</blockquote>
-
<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>
-
<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>
+<h3><a name="760"></a>760. The emplace issue</h3>
+<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-11-11 <b>Last modified:</b> 2008-06-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#Open">Open</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).
-</p>
-
-<p>
-How are we going to explain this code to beginning programmers?
+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.2 [container.requirements]/11, the implementation must check all of them for
+that possibility. A possible solution can involve extending the
+exception in 23.2 [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>
-<blockquote><pre>template<class I, class E, class S>
-struct codecvt : std::codecvt<I, E, S>
-{
- ~codecvt()
- { }
-};
+<p><i>[
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
+]</i></p>
-void main()
-{
- std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok;
-
- std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> > not_ok;
-}
-</pre></blockquote>
+<p><i>[
+Bellevue:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+<p>
+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>
+</blockquote>
-
-
-<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#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</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.
+Add after 23.2 [container.requirements]/12:
</p>
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
<blockquote>
-Needs wording for the semantics, the idea is agreed upon.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<ol type="a">
-<li>
<p>
-In the header <tt><regex></tt> synopsis 28.4 [re.syn], just below the function
-template <tt>swap</tt> add two further overloads:
+-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No
+diagnostic required.
</p>
-<blockquote><pre>template <class charT, class traits>
- void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>& e2);
-<ins>template <class charT, class traits>
- void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
-template <class charT, class traits>
- void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& 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:
+<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>
-</li>
-<li>
-<p>Just after the copy c'tor:</p>
-<blockquote><pre>basic_regex(basic_regex&&);
-</pre></blockquote>
-</li>
+</blockquote>
-<li>
-<p>Just after the copy-assignment op.:</p>
-<blockquote><pre>basic_regex& operator=(basic_regex&&);
-</pre></blockquote>
-</li>
-<li>
-<p>Just after the first <tt>assign</tt> overload insert:</p>
-<blockquote><pre>basic_regex& assign(basic_regex&& that);
-</pre></blockquote>
-</li>
-<li>
-<p>Change the current <tt>swap</tt> function to read:</p>
-<blockquote><pre>void swap(basic_regex&&);
-</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&&);
-</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& operator=(basic_regex&&);
-</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& assign(basic_regex&& that);
-</pre></blockquote>
-</li>
+<hr>
+<h3><a name="765"></a>765. more on iterator validity</h3>
+<p><b>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-12-14 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+ <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&& e);
-</pre></blockquote>
-</li>
+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.
-<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 <class charT, class traits>
- void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
-template <class charT, class traits>
- void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2);
-</pre></blockquote>
-</li>
-</ol>
+ </p>
+ <p>
-<p>
-Of course there would be need of corresponding proper standardese
-to describe these additions.
-</p>
+Consider the following code:
+
+ </p>
+ <pre> std::deque<int> x, y;
+ std::deque<int>::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() && j == x.end()
+ </pre>
+ <p>
+(There are at least two implementations where the expression
+returns <code>false</code>.)
+ </p>
+ <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>
+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><i>[
-Bellevue:
+San Francisco:
]</i></p>
<blockquote>
-<p>
-Walking into the default/value-initialization mess...
+<p>Pablo: add a note to the last bullet of paragraph 11 of 23.1.1
+clarifying that the end() iterator doesn't refer to an element and that
+it can therefore be invalidated.
</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!
+Proposed wording:
</p>
+<blockquote>
+[<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element and can
+therefore be invalidated. <i>-- end note</i>]
+</blockquote>
<p>
-Example: const int would not accept first line, but will accept the second.
+Howard will add this proposed wording to the issue and then move it to Review.
</p>
+</blockquote>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
<p>
-This is an issue that must be solved by concepts, but we might need to solve it independantly first.
+Lawrence: suggestion: "Note: The <tt>end()</tt> iterator does not refer to any element"
</p>
<p>
-It seems that the requirements are the syntax in the proposed first
-column is valid, but not clear what semantics we need.
+Walter: "Note: The <tt>end()</tt> iterator can nevertheless be invalidated,
+because it does not refer to any element."
</p>
<p>
-A table where there is no post-condition seems odd, but appears to sum up our position best.
+Nick: "The <tt>end()</tt> iterator does not refer to any element. It is therefore
+subject to being invalidated."
</p>
<p>
-At a minimum an object is declared and is destuctible.
+Consensus: go with Nick
</p>
<p>
-Move to open, as no-one happy to produce wording on the fly.
+With that update, Recommend Tentatively Ready.
</p>
</blockquote>
+
<p><b>Proposed resolution:</b></p>
<p>
-In section 20.1.1 [utility.arg.requirements], before table 33, add the
-following table:
+Add to 23.2.1 [container.requirements.general], p11:
</p>
-<p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
-
-<div align="center">
-
-<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>
-
+<blockquote>
+<p>
+Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and
+23.2.6.4) all container types defined in this Clause meet the following
+additional requirements:
+</p>
+<ul>
+<li>...</li>
+<li>
+no <tt>swap()</tt> function invalidates any references, pointers, or
+iterators referring to the elements of the containers being swapped.
+<ins>[<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element. It is therefore
+subject to being invalidated. <i>-- end note</i>]</ins>
+</li>
+</ul>
+</blockquote>
<hr>
-<h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
-<p><b>Section:</b> 2
8.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
+<h3><a name="774"></a>774. Member swap undefined for most containers</h3>
+<p><b>Section:</b> 2
3 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-01-14 <b>Last modified:</b> 2008-05-11</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>
-Two overloads of <tt>regex_replace()</tt> are currently provided:
+It appears most containers declare but do not define a member-swap
+function.
</p>
-<blockquote><pre>template <class OutputIterator, class BidirectionalIterator,
- class traits, class charT>
- OutputIterator
- regex_replace(OutputIterator out,
- BidirectionalIterator first, BidirectionalIterator last,
- const basic_regex<charT, traits>& e,
- const basic_string<charT>& fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-
-template <class traits, class charT>
- basic_string<charT>
- regex_replace(const basic_string<charT>& s,
- const basic_regex<charT, traits>& e,
- const basic_string<charT>& 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 << regex_replace(s, r, "y") << endl;
-</pre></blockquote>
-
<p>
-The compiler error message will be something like "could not deduce
-template argument for 'const std::basic_string<_Elem> &' from 'const
-char[1]'".
+This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
+member-swap function!
+(required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
+[Table 87])
</p>
<p>
-Users expect that anything taking a <tt>basic_string<charT></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).
+Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
+yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
+definition.
</p>
<p>
-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.
+A quick survey of clause 23 shows that the following containers provide a
+definition for member-swap:
</p>
-</li>
-
-<li>
-There is an efficiency consideration: constructing <tt>basic_string</tt>s can
-impose performance costs that could be avoided by a library
-implementation taking C strings and dealing with them directly.
-(Currently, for replacement sources, C strings can be converted into
-iterator pairs at the cost of verbosity, but for format strings, there
-is no way to avoid constructing a <tt>basic_string</tt>.)
-</li>
-</ol>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
+<blockquote><pre>array
+queue
+stack
+vector
+</pre></blockquote>
-<blockquote>
-We note that Boost already has these overloads. However, the proposed
-wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis
-as well. We also note that this has impact on <tt>match_results::format</tt>,
-which may require further overloads.
-</blockquote>
-
+<p>
+Whereas the following declare it, but do not define the semantics:
+</p>
+<blockquote><pre>deque
+list
+map
+multimap
+multiset
+priority_queue
+set
+unordered_map
+unordered_multi_map
+unordered_multi_set
+unordered_set
+</pre></blockquote>
-<p><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]:
+Suggested resolution:
</p>
-
<blockquote>
-<pre>template <class OutputIterator, class BidirectionalIterator,
- class traits, class charT>
- OutputIterator
- regex_replace(OutputIterator out,
- BidirectionalIterator first, BidirectionalIterator last,
- const basic_regex<charT, traits>& e,
- const basic_string<charT>& fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-
-<ins>template <class OutputIterator, class BidirectionalIterator,
- class traits, class charT>
- OutputIterator
- regex_replace(OutputIterator out,
- BidirectionalIterator first, BidirectionalIterator last,
- const basic_regex<charT, traits>& e,
- const charT* fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);</ins>
-</pre>
-<p>...</p>
-<pre>template <class traits, class charT>
- basic_string<charT>
- regex_replace(const basic_string<charT>& s,
- const basic_regex<charT, traits>& e,
- const basic_string<charT>& fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-
-<ins>template <class traits, class charT>
- basic_string<charT>
- regex_replace(const basic_string<charT>& s,
- const basic_regex<charT, traits>& e,
- const charT* fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);</ins>
-
-<ins>template <class traits, class charT>
- basic_string<charT>
- regex_replace(const charT* s,
- const basic_regex<charT, traits>& e,
- const basic_string<charT>& fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);</ins>
-
-<ins>template <class traits, class charT>
- basic_string<charT>
- regex_replace(const charT* s,
- const basic_regex<charT, traits>& e,
- const charT* fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);</ins>
-</pre>
+Provide a definition for each of the affected containers...
</blockquote>
+<p><i>[
+Bellevue:
+]</i></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>
-<p><b>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<charT, ST,
-SA>&</tt>. <tt>regex_replace()</tt> takes <tt>const basic_string<charT>&</tt>. This prevents
-<tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
-allocators.
-</p>
+<blockquote>
+Move to Open and ask Alisdair to provide wording.
+</blockquote>
<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<charT, ST,
-SA>&</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.
+Wording provided in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>.
</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#Ready">Ready</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
+<p><b>Section:</b> 25.5.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-25 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</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>].
+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>
-I see two possible resolutions:
+Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.5.4 [alg.merge] in N2461
+have no Requires element and the Effects element contains some requirements,
+which is probably editorial. Worse is that:
</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
+<ul>
+<li>
+no assignment requirements are specified (neither implicit nor explicit).
</li>
-</ol>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for further discussion.
-</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 <) and redundant (because the
+following subordinate
+clause mentions comp again)
+</li>
+</ul>
<p><i>[
-Bellevue:
+Post Summit Alisdair adds:
]</i></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.
+Suggest:
</p>
+<blockquote>
+(where <tt>last</tt> is equal to <tt>next(result, distance(first1, last1) +
+distance(first2, last2))</tt>, such that resulting range will be sorted in
+non-decreasing order; that is, for every iterator <tt>i</tt> in <tt>[result,last)</tt> other
+than <tt>result</tt>, the condition <tt>*i < *prev(i)</tt> or, respectively, <tt>comp(*i,
+*prev(i))</tt> will be <tt>false</tt>.
</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.
+Note that this might still not be technically accurate in the case of
+<tt>InputIterators</tt>, depending on other resolutions working their way through the
+system (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>).
</p>
+</blockquote>
<p><i>[
-Stephan Tolksdorf adds pre-Bellevue:
+Post Summit Daniel adds:
]</i></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.
+If we want to use <tt>prev</tt> and <tt>next</tt> here (Note: <tt>merge</tt>
+is sufficiently satisfied with <tt>InputIterator</tt>) we should instead *add* more to
+25 [algorithms]/6, but I can currently not propose any good wording for this.
</blockquote>
<p><i>[
-Sophia Antipolis:
+Batavia (2009-05):
]</i></p>
-
<blockquote>
-Note the main part of the issue is resolved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>.
-</blockquote>
-
-
-
-
-
-
-<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#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>
-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.
+Pete points out the existing wording in [algorithms]/4
+that permits the use of + in algorithm specifications.
</p>
-
<p>
-<b>Possible resolution:</b> For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
+Alisdair points out that that wording may not apply to input iterators.
</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
<p>
-Disagreement persists.
+Move to Review.
</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></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.
+In 25.5.4 [alg.merge] replace p.1+ 2:
</p>
+
+<blockquote>
<p>
-Correction: The formula above should instead read 1+sin(n*x).
+<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 < *(i - 1)</tt> or,
+respectively, <tt>comp(*i, *(i - 1))</tt> will be false</ins>.
</p>
+
<p>
-Objector proposes the following possible compromise positions:
+<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 < *(i - 1)</tt> or
+<tt>comp(*i, *(i - 1))</tt> will be false.</del>
</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>
-
-
-<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.
+[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><algorithm></tt> show, just a matter of consistency]
</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#Review">Review</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</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#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> John Maddock <b>Opened:</b> 2008-01-15 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</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).
+Table 16 of TR1 requires that all Pseudo Random Number generators have a
</p>
-<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>
+<blockquote><pre>seed(integer-type s)
+</pre></blockquote>
<p>
-<b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters
-to double.
+member function that is equivalent to:
</p>
-<p><i>[
-Bellevue:
+<blockquote><pre>mygen = Generator(s)
+</pre></blockquote>
+
+<p>
+But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
+</p>
+
+<blockquote><pre>template <class Gen>
+seed(Gen&);
+</pre></blockquote>
+
+<p>
+member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
+</p>
+
+<p>
+So... is this a bug in TR1?
+</p>
+
+<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>
-In N2424. Not wildly enthusiastic, not really felt necessary. Less
-frequently used in practice. Not terribly bad either. Move to OPEN.
+Both engines do have the necessary
+constructor, therefore the omission of the <tt>seed()</tt> member
+functions appears to be an oversight.
</blockquote>
<p><i>[
-Sophia Antipolis:
+Post Summit Daniel adds:
]</i></p>
<blockquote>
-<p>
-Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test.
-</p>
-<p>
-Marc Paterno: Ask implementers whether floating-point is a significant burden.
-</p>
-<p>
-Alisdair: It's neater to do it now, do ask Bill Plauger.
-</p>
-<p>
-Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent.
-</p>
+Recommend NAD: <tt>xor_combine</tt> does no longer exist and <tt>discard_block[_engine]</tt>
+has now the required seed overload accepting a <tt>result_type</tt>, which shall be an
+unsigned integral type.
</blockquote>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to NAD as recommended.
+</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.
+NAD Recommended.
</p>
-<p><i>[
-Stephan Tolksdorf adds pre-Bellevue:
-]</i></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>
+<hr>
+<h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
+<p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-02-06 <b>Last modified:</b> 2009-03-14</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#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 287</b></p>
+
+<blockquote>
<p>
-Replace both occurrences of "<tt>explicit chi_squared_distribution(int n = 1);</tt>"
-with "<tt>explicit chi_squared_distribution(RealType n = 1);</tt>".
+It is not clear what the initial state of an <tt>istream_iterator</tt> should be. Is
+_value_ initialized by reading the stream, or default/value initialized? If
+it is initialized by reading the stream, what happens if the initialization
+is deferred until first dereference, when ideally the iterator value should
+have been that of an end-of-stream iterator which is not safely
+dereferencable?
</p>
<p>
-Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
+Recommendation: Specify _value_ is initialized by reading the stream, or
+the iterator takes on the end-of-stream value if the stream is empty.
</p>
-
</blockquote>
<p>
-In 26.4.8.4.5 [rand.dist.norm.f]:
+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>
-<p>
-Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph.
-</p>
+<tt>istream_iterator</tt> reads (using <tt>operator>></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&</tt> is
+returned. The result of <tt>operator-></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>
-Replace both occurrences of
-</p>
-<blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1);
-</pre></blockquote>
-<p>
-with
+<tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>,
+otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or
+<tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't
+necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after
+extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will
+have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator
+void*()</tt> will return a non-null value).
</p>
-<blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
-</pre></blockquote>
<p>
-Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>".
+Also I would prefer to be explicit about calling <tt>fail()</tt> here
+(there is no <tt>operator void*()</tt> anymore.)
</p>
-<p>
-Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>".
-</p>
-</blockquote>
+<p><i>[
+Summit:
+]</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>
+Moved from Ready to Open for the purposes of using this issue to address NB UK 287.
+Martin to handle.
+</blockquote>
-<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>".
+Change 24.6.1 [istream.iterator]/1:
</p>
-</blockquote>
+<blockquote>
+<tt>istream_iterator</tt> reads (using <tt>operator>></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&</tt> is
+returned. The result of <tt>operator-></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="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>
+<h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
+<p><b>Section:</b> 20.5 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-02-18 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a> now just
-deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
-requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
-<tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
+Classes with trivial special member functions are inherently more
+efficient than classes without such functions. This efficiency is
+particularly pronounced on modern ABIs that can pass small classes
+in registers. Examples include value classes such as complex numbers
+and floating-point intervals. Perhaps more important, though, are
+classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>. When the
+parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
+themselves can be trivial, leading to substantial performance wins.
</p>
-
<p>
-This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators. Here
-is example code:
+The current working draft make specification of trivial functions
+(where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
+As long as the semantics of defaulted and deleted functions match
+the intended semantics, specification of defaulted and deleted
+functions will yield more efficient programs.
+</p>
+<p>
+There are at least two cases where specification of an explicitly
+defaulted function may be desirable.
+</p>
+<p>
+First, the <tt>std::pair</tt> template has a non-trivial default constructor,
+which prevents static initialization of the pair even when the
+types are statically initializable. Changing the definition to
</p>
-<blockquote><pre>namespace Mine {
-
-template <class T>
-struct proxy {...};
-
-template <class T>
-struct proxied_iterator
-{
- typedef T value_type;
- typedef proxy<T> reference;
- reference operator*() const;
- ...
-};
-
-struct A
-{
- // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
- void swap(A&);
- ...
-};
-
-void swap(A&, A&);
-void swap(proxy<A>, A&);
-void swap(A&, proxy<A>);
-void swap(proxy<A>, proxy<A>);
+<blockquote><pre>pair() = default;
+</pre></blockquote>
-} // Mine
+<p>
+would enable such initialization. Unfortunately, the change is
+not semantically neutral in that the current definition effectively
+forces value initialization whereas the change would not value
+initialize in some contexts.
+</p>
-...
+<p>
+** Does the committee confirm that forced value initialization
+was the intent? If not, does the committee wish to change the
+behavior of <tt>std::pair</tt> in C++0x?
+</p>
+<p>
+Second, the same default constructor issue applies to <tt>std::tuple</tt>.
+Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
+which effectively prevents passing it in registers. To enable
+passing <tt>tuples</tt> in registers, the copy constructor should be
+make explicitly <tt>default</tt>ed. The new declarations are:
+</p>
-Mine::proxied_iterator<Mine::A> i(...)
-Mine::A a;
-<b>swap(*i1, a);</b>
+<blockquote><pre>tuple() = default;
+tuple(const tuple&) = default;
</pre></blockquote>
<p>
-The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
-and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
-same type). A secondary point is that to support proxies, one must be able to pass rvalues
-to <tt>swap</tt>. But note that I am not stating that the general purpose <tt>std::swap</tt>
-should accept rvalues! Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
-to take rvalues.
+This changes is not implementation neutral. In particular, it
+prevents implementations based on pointers to the parameter
+types. It does however, permit implementations using the
+parameter types as bases.
</p>
-
<p>
-That is, no standard library code needs to change. We simply need to have a more flexible
-definition of <tt>Swappable</tt>.
+** How does the committee wish to trade implementation
+efficiency versus implementation flexibility?
</p>
<p><i>[
<blockquote>
<p>
-While we believe Concepts work will define a swappable concept, we
-should still resolve this issue if possible to give guidance to the
-Concepts work.
+General agreement; the first half of the issue is NAD.
</p>
<p>
-Would an ambiguous swap function in two namespaces found by ADL break
-this wording? Suggest that the phrase "valid expression" means such a
-pair of types would still not be swappable.
+Before voting on the second half, it was agreed that a "Strongly Favor"
+vote meant support for trivial tuples (assuming usual requirements met),
+even at the expense of other desired qualities. A "Weakly Favor" vote
+meant support only if not at the expense of other desired qualities.
</p>
<p>
-Motivation is proxy-iterators, but facility is considerably more
-general. Are we happy going so far?
+Concensus: Go forward, but not at expense of other desired qualities.
</p>
<p>
-We think this wording is probably correct and probably an improvement on
-what's there in the WP. On the other hand, what's already there in the
-WP is awfully complicated. Why do we need the two bullet points? They're
-too implementation-centric. They don't add anything to the semantics of
-what swap() means, which is there in the post-condition. What's wrong
-with saying that types are swappable if you can call swap() and it
-satisfies the semantics of swapping?
+It was agreed to Alisdair should fold this work in with his other
+pair/tuple action items, above, and that issue 801 should be "open", but
+tabled until Alisdair's proposals are disposed of.
</p>
</blockquote>
+<p><i>[
+2009-05-27 Daniel adds:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.1.1 [utility.arg.requirements]:
-</p>
-
<blockquote>
+This is partly solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>.
+</blockquote>
-<p>
--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><b>Proposed resolution:</b></p>
<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>
-
<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.5.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
-<p><b>View 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>
+<h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
+<p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-03-01 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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#Tentatively%20Ready">Tentatively Ready</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. 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?
+The recent draft (as well as the original proposal n2072) uses an
+operational semantic
+for <tt>get_money</tt> ([ext.manip]/4) and <tt>put_money</tt> ([ext.manip]/6), which uses
</p>
+
+<blockquote><pre>istreambuf_iterator<charT>
+</pre></blockquote>
+
<p>
-E.g.
+and
</p>
-<blockquote><pre>struct test{
- int x;
- test() : x() {}
-};
+<blockquote><pre>ostreambuf_iterator<charT>
</pre></blockquote>
+
<p>
-Should I expect a conforming compiler to
- <tt>assert( has_nothrow_constructor<test>::value )</tt>
-</p>
-<p>
-Is this a QoI issue?
-</p>
-<p>
-Should I expect to 'know' only if-and-only-if there is an inline definition
-available?
-</p>
-<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?
-</p>
-<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.
+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<charT,traits></tt> as argument.
</p>
<p>
-(agreement since is that trivial ops and explicit no-throws are required.
-Open if QoI should be allowed to detect further)
+The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic
+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><i>[
-Bellevue:
+Batavia (2009-05):
]</i></p>
-
<blockquote>
-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.
+<p>
+This appears to be an issue of presentation.
+</p>
+<p>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</p>
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
+In 27.7.4 [ext.manip]/4 within function <tt>f</tt> replace the first line
</p>
+<blockquote><pre>template <class charT, class traits, class moneyT>
+void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) {
+ typedef istreambuf_iterator<charT<ins>, traits</ins>> Iter;
+ ...
+</pre></blockquote>
+<p>
+In 27.7.4 [ext.manip]/5 remove the first template <tt>charT</tt> parameter:
+</p>
+<blockquote><pre>template <<del>class charT, </del>class moneyT> unspecified put_money(const moneyT& mon, bool intl = false<ins>)</ins>;
+</pre></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.5.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-With the pending arrival of explicit conversion functions though, I'm
-wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
+In 27.7.4 [ext.manip]/6 within function <tt>f</tt> replace the first line
</p>
-<p><i>[
-Bellevue:
-]</i></p>
+<blockquote><pre>template <class charT, class traits, class moneyT>
+void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) {
+ typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter;
+ ...
+</pre></blockquote>
+<p>
+In 27.7.4 [ext.manip]/8 within function <tt>f</tt> replace the first line
+</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>
+<blockquote><pre>template <class charT, class traits>
+void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) {
+ typedef <ins>i</ins>streambuf_iterator<charT<ins>, traits</ins>> Iter;
+ ...
+</pre></blockquote>
+<p>
+In 27.7.4 [ext.manip]/10 within function <tt>f</tt> replace the first line
+</p>
+
+<blockquote><pre>template <class charT, class traits>
+void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) {
+ typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter;
+ ...
+</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
+In 27.7 [iostream.format], Header <tt><iomanip></tt> synopsis change:
</p>
+<blockquote><pre>template <<del>class charT, </del>class moneyT> T8 put_money(const moneyT& mon, bool intl = false);
+</pre></blockquote>
+
<hr>
-<h3><a name="751"></a>751. change pass-by-reference members of <tt>vector<bool></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>
+<h3><a name="814"></a>814. <tt>vector<bool>::swap(reference, reference)</tt> not defined</h3>
+<p><b>Section:</b> 23.3.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-17 <b>Last modified:</b> 2009-05-23</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-A number of vector<bool> members take const bool& 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?
+<tt>vector<bool>::swap(reference, reference)</tt> has no definition.
</p>
<p><i>[
-post Bellevue:
+San Francisco:
]</i></p>
<blockquote>
-<p>
-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>
-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>
-Many in the group feel that for vector<bool>, 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>
+Move to Open. Alisdair to provide a resolution.
</blockquote>
+<p><i>[
+Post Summit Daniel provided wording.
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
-<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#Review">Review</a>
- <b>Submitter:</b> Hans Boehm <b>Date:</b> 2007-10-11</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
-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. 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><b>Proposed resolution:</b></p>
<p>
-<tt>Allocate()</tt> more blatantly takes time proportional to the size of the
-object if you mix in GC. But it's not really a new problem, and I think
-we'd be confusing things by leaving the bogus requirements there. The
-current requirement on <tt>allocate()</tt> is generally not important anyway,
-since it takes O(size) to construct objects in the resulting space.
-There are real performance issues here, but they're all concerned with
-the constants, not the asymptotic complexity.
+Just after 23.3.7 [vector.bool]/5 add the following prototype and description:
</p>
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
<p>
-Change 20.1.2 [allocator.requirements]/2:
+<ins>static void swap(reference x, reference y);</ins>
</p>
-
<blockquote>
<p>
--2- Table 39 describes the requirements on types manipulated through
-allocators. <del>All the operations on the allocators are expected to be
-amortized constant time.</del> Table 40 describes the
-requirements on allocator types.
+<ins>-6- <i>Effects:</i> Exchanges the contents of <tt>x</tt> and <tt>y</tt> as-if</ins> by:
</p>
+<blockquote><pre><ins>
+bool b = x;
+x = y;
+y = b;
+</ins></pre></blockquote>
+</blockquote>
</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#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>
+<h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
+<p><b>Section:</b> 20.7.16.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-16 <b>Last modified:</b> 2009-06-01</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The draft standard n2369 uses the term <i>move constructor</i> in a few
-places, but doesn't seem to define it.
+<tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
+described in the rvalue core proposal.
</p>
-<p>
-<tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as
-follows:
-</p>
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
<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>
+According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect
+forwarding can not be obtained because of type erasure. Not everyone
+agreed with this diagnosis of forwarding.
</blockquote>
-<p>
-(where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
-</p>
-
-<p>
-So I assume the move constructor is the constructor that would be used
-in filling the above requirement.
-</p>
+<p><i>[
+2009-05-01 Howard adds:
+]</i></p>
-<p>
-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>
-<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!
+Sebastian Gesemann brought to my attention that the <tt>CopyConstructible</tt>
+requirement on <tt>function</tt>'s <tt>ArgTypes...</tt> is an unnecessary
+restriction.
</p>
-<p>
-I 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><pre>template<Returnable R, <b>CopyConstructible</b>... ArgTypes>
+class function<R(ArgTypes...)>
+...
+</pre></blockquote>
<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.
+On further investigation, this complaint seemed to be the same
+issue as this one. I believe the reason <tt>CopyConstructible</tt> was put
+on <tt>ArgTypes</tt> in the first place was because of the nature of the
+<i>invoke</i> member:
</p>
+<blockquote><pre>template<class R, class ...ArgTypes>
+R
+function<R(ArgTypes...)>::operator()(ArgTypes... arg) const
+{
+ if (f_ == 0)
+ throw bad_function_call();
+ return (*f_)(arg...);
+}
+</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
-Add new defintions to 17.1 [definitions]:
+However now with rvalue-refs, "by value" no longer implies <tt>CopyConstructible</tt>
+(as Sebastian correctly points out). If rvalue arguments are supplied, <tt>MoveConstructible</tt>
+is sufficient. Furthermore, the constraint need not be applied in <tt>function</tt>
+if I understand correctly. Rather the client must apply the proper constraints
+at the call site. Therefore, at the very least, I recommend that <tt>CopyConstructible</tt>
+be removed from the template class <tt>function</tt>.
</p>
-<blockquote>
-<p>
-<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.
+Furthermore we need to mandate that the <i>invoker</i> is coded as:
</p>
-</blockquote>
-
-<p><i>[
-Howard adds post-Bellevue:
-]</i></p>
+<blockquote><pre>template<class R, class ...ArgTypes>
+R
+function<R(ArgTypes...)>::operator()(ArgTypes... arg) const
+{
+ if (f_ == 0)
+ throw bad_function_call();
+ return (*f_)(<b>std::forward<ArgTypes>(</b>arg<b>)</b>...);
+}
+</pre></blockquote>
-<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. :-)
+Note that <tt>ArgTypes&&</tt> (the "perfect forwarding signature") is not
+appropriate here as this is not a deduced context for <tt>ArgTypes</tt>. Instead
+the client's arguments must implicitly convert to the non-deduced <tt>ArgType</tt>
+type. Catching these arguments by value makes sense to enable decay.
</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3>
-<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-10-31</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-Consider the following program:
+Next <tt>forward</tt> is used to move the <tt>ArgTypes</tt> as efficiently as
+possible, and also with minimum requirements (not <tt>CopyConstructible</tt>)
+to the type-erased functor. For object types, this will be a <tt>move</tt>. For
+reference type <tt>ArgTypes</tt>, this will be a copy. The end result <em>must</em> be
+that the following is a valid program:
</p>
-<blockquote><pre>int main() {
- shared_ptr<int> p(nullptr);
- return 0;
-}
-</pre></blockquote>
+<blockquote><pre>#include <functional>
+#include <memory>
+#include <cassert>
-<p>
-This program will fail to compile because <tt>shared_ptr</tt> uses the following
-template constructor to construct itself from pointers:
-</p>
+std::unique_ptr<int>
+f(std::unique_ptr<int> p, int& i)
+{
+ ++i;
+ return std::move(p);
+}
-<blockquote><pre>template <class Y> shared_ptr(Y *);
+int main()
+{
+ int i = 2;
+ std::function<std::unique_ptr<int>(std::unique_ptr<int>,
+ int&> g(f);
+ std::unique_ptr<int> p = g(std::unique_ptr<int>(new int(1)), i);
+ assert(*p == 1);
+ assert(i == 3);
+}
</pre></blockquote>
-<p>
-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<T *>(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<T*>(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<T *>(0))</tt> may not.
-</p>
-
<p><i>[
-Bellevue:
+Tested in pre-concepts rvalue-ref-enabled compiler.
]</i></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>
-<p>
-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>
-<p>
-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>
<p>
-Move to Ready, modulo editorial comments
+In the example above, the first <tt>ArgType</tt> is <tt>unique_ptr<int></tt>
+and the second <tt>ArgType</tt> is <tt>int&</tt>. Both <em>must</em> work!
</p>
+
</blockquote>
<p><i>[
-post Bellevue Peter adds:
+2009-05-27 Daniel adds:
]</i></p>
<blockquote>
<p>
-The following wording changes are less intrusive:
+in the 2009-05-01 comment of above mentioned issue Howard
</p>
+<ol type="a">
+<li>
+Recommends to replace the <tt>CopyConstructible</tt> requirement by a
+<tt>MoveConstructible</tt> requirement
+</li>
+<li>
+Says: "Furthermore, the constraint need not be applied in <tt>function</tt> if I
+understand correctly. Rather the client must apply the proper constraints
+at the call site"
+</li>
+</ol>
<p>
-In 20.7.12.2.1 [util.smartptr.shared.const], add:
+I'm fine with (a), but I think comment (b) is incorrect, at least in the
+sense I read these sentences. Let's look at Howard's example code:
</p>
-<blockquote><pre>shared_ptr(nullptr_t);
+<blockquote><pre>function<R(ArgTypes...)>::operator()(ArgTypes... arg) const
+{
+ if (f_ == 0)
+ throw bad_function_call();
+ return (*f_)(std::forward<ArgTypes>(arg)...);
+}
</pre></blockquote>
<p>
-after:
+In the constrained scope of this <tt>operator()</tt> overload the expression
+"<tt>(*f_)(std::forward<ArgTypes>(arg)...)</tt>" must be valid. How can it
+do so, if <tt>ArgTypes</tt> aren't at least <tt>MoveConstructible</tt>?
</p>
+</blockquote>
-<blockquote><pre>shared_ptr();
-</pre></blockquote>
-<p>
-(Absence of explicit intentional.)
-</p>
+<p><b>Proposed resolution:</b></p>
<p>
-<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><pre>template<class D> shared_ptr(nullptr_t p, D d);
-template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
-</pre></blockquote>
-<p>
-after
-</p>
-<blockquote><pre>template<class Y, class D> shared_ptr(Y* p, D d);
-template<class Y, class D, class A> shared_ptr(Y* p, D d, A a);
-</pre></blockquote>
+
+<hr>
+<h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3>
+<p><b>Section:</b> 20.7.12.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2008-02-08 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-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>.
+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>
-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.
+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>
-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.
+Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended
+to cover both calling <tt>bind()</tt> and copying the returned functor?
</p>
+
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+<tt>tuple</tt> construction should probably have a similar guarantee.
</blockquote>
<p><i>[
-Sophia Antipolis:
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+Howard to provide wording.
+</blockquote>
+
+<p><i>[
+Post Summit, Anthony provided wording.
]</i></p>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
<blockquote>
+Part of all of this issue appears to be rendered moot
+by the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a> (q.v.).
+We recommend the issues be considered simultaneously
+(or possibly even merged)
+to ensure there is no overlap.
+Move to Open, and likewise for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-We want to remove the reset functions from the proposed resolution.
+Add a new sentence to the end of paragraphs 2 and 4 of 20.7.12.1.3 [func.bind.bind]:
</p>
+
+<blockquote>
<p>
-The remaining proposed resolution text (addressing the constructors) are wanted.
+-2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2,
+..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable<F cv,V1, V2, ..., VN>::result_type)</tt>, where <i>cv</i>
+represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments
+<tt>v1, v2, ..., vN</tt> are determined as specified below.
+<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
+exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
+in <tt>BoundArgs...</tt> throw an exception.</ins>
</p>
+<p>...</p>
<p>
-Disposition: move to review. The review should check the wording in the then-current working draft.
+-4- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym
+for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the
+values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below.
+<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
+exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
+in <tt>BoundArgs...</tt> throw an exception.</ins>
</p>
-</blockquote>
+</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following constructors to 20.7.12.2 [util.smartptr.shared]:
-</p>
-<blockquote><pre>shared_ptr(nullptr_t);
-template <class D> shared_ptr(nullptr_t, D d);
-template <class D, class A> shared_ptr(nullptr_t, D d, A a);
-</pre></blockquote>
+<hr>
+<h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
+<p><b>Section:</b> 20.7.12.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-03-17 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses US 72, JP 38 and DE 21</b></p>
<p>
-Add the following constructor definitions to 20.7.12.2.1 [util.smartptr.shared.const]:
+The functor returned by <tt>bind()</tt> should have a move constructor that
+requires only move construction of its contained functor and bound arguments.
+That way move-only functors can be passed to objects such as <tt>thread</tt>.
</p>
-
-<blockquote>
-<pre> explicit shared_ptr(nullptr_t);
-</pre>
-<blockquote>
<p>
-<i>Effects:</i> Constructs an empty shared_ptr object.
+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>
-<i>Postconditions:</i> <tt>use_count() == 0 && get() == 0</tt>.
+US 72:
</p>
+
+<blockquote>
+<tt>bind</tt> should support move-only functors and bound arguments.
+</blockquote>
+
<p>
-<i>Throws:</i> nothing.
+JP 38:
</p>
-</blockquote>
-</blockquote>
<blockquote>
-<pre>template <class D> shared_ptr(nullptr_t, D d);
-template <class D, class A> shared_ptr<nullptr_t, D d, A a);
-</pre>
-<blockquote>
<p>
-<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<T *>(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.
+add the move requirement for bind's return type.
</p>
<p>
-<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.
+For example, assume following <tt>th1</tt> and <tt>th2</tt>,
</p>
+
+<blockquote><pre>void f(vector<int> v) { }
+
+vector<int> v{ ... };
+thread th1([v]{ f(v); });
+thread th2(bind(f, v));
+</pre></blockquote>
+
<p>
-<i>Postconditions:</i> <tt>use_count() == 1</tt> and <tt>get() == 0</tt>.
+When function object are set to thread, <tt>v</tt> is moved to <tt>th1</tt>'s lambda
+expression in a Move Constructor of lambda expression because <tt>th1</tt>'s lambda
+expression has a Move Constructor. But <tt>bind</tt> of <tt>th2</tt>'s
+return type doesn't have the requirement of Move, so it may not
+moved but copied.
</p>
<p>
-<i>Throws:</i> <tt>bad_alloc</tt>, or an implementation-defined exception when a
-resource other than memory could not be obtained.
+Add the requirement of move to get rid of this useless copy.
</p>
<p>
-<i>Exception safety:</i> If an exception is thrown, <tt>d(static_cast<Y *>(nullptr))</tt> is called.
+And also, add the <tt>MoveConstructible</tt> as well as <tt>CopyConstructible</tt>.
</p>
</blockquote>
-</blockquote>
-
-
-
-
-
-
-
-<hr>
-<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>
-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
+DE 21
</p>
+<blockquote>
+The specification for bind claims twice that "the values and types for
+the bound arguments v1, v2, ..., vN are determined as specified below".
+No such specification appears to exist.
+</blockquote>
+
<p><i>[
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
+San Francisco:
]</i></p>
+<blockquote>
+Howard to provide wording.
+</blockquote>
+
<p><i>[
-Bellevue:
+Post Summit Alisdair and Howard provided wording.
]</i></p>
<blockquote>
<p>
-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.
+Several issues are being combined in this resolution. They are all touching the
+same words so this is an attempt to keep one issue from stepping on another, and
+a place to see the complete solution in one place.
</p>
-</blockquote>
-
+<ol>
+<li>
+<tt>bind</tt> needs to be "moved".
+</li>
+<li>
+20.7.12.1.3 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798.
+</li>
+<li>
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a> argues for a way to pass by && for
+efficiency but retain the decaying behavior of pass by value for the
+<tt>thread</tt> constructor. That same solution is applicable here.
+</li>
+</ol>
+</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>
-Add after 23.1 [container.requirements]/12:
-</p>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
<blockquote>
<p>
--12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No
-diagnostic required.
+We were going to recommend moving this issue to Tentatively Ready
+until we noticed potential overlap with issue 816 (q.v.).
</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>
+Move to Open,
+and recommend both issues be considered together
+(and possibly merged).
</p>
-
</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.7 [function.objects] p2:
+</p>
+<blockquote><pre>template<<del>CopyConstructible</del> <ins>MoveConstructible</ins> Fn, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... Types>
+ <i>unspecified</i> bind(Fn<ins>&&</ins>, Types<ins>&&</ins>...);
+template<Returnable R, <del>CopyConstructible</del> <ins>MoveConstructible</ins> Fn, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... Types>
+ <i>unspecified</i> bind(Fn<ins>&&</ins>, Types<ins>&&</ins>...);
+</pre></blockquote>
-
-
-<hr>
-<h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3>
-<p><b>Section:</b> 20.7.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-11-30</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>
-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>.
+Change 20.7.12.1.3 [func.bind.bind]:
</p>
-<p><i>[
-Bellevue:
-]</i></p>
-
+<blockquote><pre>template<<del>CopyConstructible</del> <ins>MoveConstructible</ins> F, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... BoundArgs>
+ <i>unspecified</i> bind(F<ins>&&</ins> f, BoundArgs<ins>&&</ins>... bound_args);
+</pre>
<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>
-The proposed changes in the following revision refers to the current state of
-N2521 including the assumption that 20.7.11.4 [unique.ptr.compiletime] will be removed
-according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>.
+<ins><i>Requires:</i> <i>unspecified</i> return type shall be <tt>MoveConstructible</tt>.</ins>
</p>
<p>
-The specialization <tt>unique_ptr<T[]></tt> has some more restrictive constraints on
-type-completeness on <tt>T</tt> than <tt>unique_ptr<T></tt>. The following proposed wordings
-try to cope with that. If the committee sees less usefulness on relaxed
-constraints on <tt>unique_ptr<T[]></tt>, the alternative would be to stop this relaxation
-e.g. by adding one further bullet to 20.7.11.3 [unique.ptr.runtime]/1:
-"<tt>T</tt> shall be a complete type, if used as template argument of
-<tt>unique_ptr<T[], D></tt>
+-1- <i>Requires:</i> <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid expression for some values
+<i>w1, w2, ..., wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
</p>
<p>
-This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, but it seems not to cause any
-problems with this one,
-because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict
-with the here discussed
-ones, provided that <tt>D::pointer</tt>'s operations (including default
-construction, copy construction/assignment,
-and pointer conversion) are specified <em>not</em> to throw, otherwise this
-would have impact on the
-current specification of <tt>unique_ptr</tt>.
+-2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2,
+..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable<F cv,V1, V2, ..., VN>::result_type)</tt>, where <i>cv</i>
+represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments
+<tt>v1, v2, ..., vN</tt> are determined as specified below.
</p>
+<p><ins>
+<i>Throws:</i> Nothing unless the constructor of <tt>F</tt> or of one of the types in the <tt>BoundArgs...</tt> pack expansion
+throws an exception.
+</ins></p>
+</blockquote>
-<ol>
-<li>
-<p>
-In 20.7.11 [unique.ptr]/2 add as the last sentence to the existing para:
-</p>
+<pre>template<Returnable R, <del>CopyConstructible</del> <ins>MoveConstructible</ins> F, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... BoundArgs>
+ <i>unspecified</i> bind(F<ins>&&</ins> f, BoundArgs<ins>&&</ins>... bound_args);
+</pre>
<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>
-
-<li>
<p>
-20.7.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
+<ins><i>Requires:</i> <i>unspecified</i> return type shall be <tt>MoveConstructible</tt>.</ins>
</p>
-
-<blockquote>
-<p><i>[
-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>
-
-<li>
<p>
-In 20.7.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
+-3- <i>Requires:</i> <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> shall be a valid expression for some values <i>w1, w2, ...,
+wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
</p>
-
-<blockquote>
<p>
-<i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor
-of <tt>D</tt> shall not throw an exception.</del>
-<del><tt>D</tt> must not be a reference type.</del>
-<ins>
-<tt>D</tt> shall be default constructible, and that construction
-shall not throw an exception.
-</ins>
+-4- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym
+for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the
+values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below.
</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<Y*, X*></tt>, which
-again requires Completeness of <tt>Y</tt>, if <tt>!SameType<X, Y></tt>
-]</i></p>
+<p>
+</p><p><ins>
+<i>Throws:</i> Nothing unless the constructor of <tt>F</tt> or of one of the types in the <tt>BoundArgs...</tt> pack expansion
+throws an exception.
+</ins></p>
</blockquote>
-</li>
-<li>
-<p>
-Merge 20.7.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
-of 12, but transferring the "requires" to 13:
-</p>
+<p><ins>
+Let the values of <i>bound arguments</i> <tt>v1, v2, ..., vN</tt> and
+their corresponding types <tt>V1, V2, ..., VN</tt> depend on the type of
+the corresponding argument <tt>ti</tt> in <tt>bound_args</tt> in the
+call to <tt>bind</tt> and the <i>cv</i>-qualifiers <i>cv</i> of the call
+wrapper <tt>g</tt> as follows. Let <tt>Ti</tt> be an alias for the ith
+element of the pack expansion <tt>decay<BoundArgs>::type...</tt>,
+and let <tt>ti</tt> be an alias for the ith element in the function
+parameter pack expansion <tt>bound_args...</tt>:
+</ins></p>
-<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>
+<ul>
+<li><ins>
+if <tt>ti</tt> is of type <tt>reference_wrapper<T></tt> the argument is
+<tt>ti.get()</tt> and its type <tt>Vi</tt> is <tt>T&</tt>;
+</ins></li>
+<li><ins>
+if the value of <tt>std::is_bind_expression<Ti>::value</tt> is <tt>true</tt> the argument is <tt>ti(u1, u2, ..., uM)</tt> and
+its type <tt>Vi</tt> is <tt>result_of<Ti cv (U1&, U2&, ..., UM&)>::type</tt>;
+</ins></li>
+<li><ins>
+if the value <tt>j</tt> of <tt>std::is_placeholder<Ti>::value</tt> is not zero the argument is <tt>std::forward<Uj>(uj)</tt> and
+its type <tt>Vi</tt> is <tt>Uj&&</tt>;
+</ins></li>
+<li><ins>
+otherwise the value is <tt>ti</tt> and its type <tt>Vi</tt> is <tt>Ti cv &</tt>.
+</ins></li>
+</ul>
</blockquote>
-</li>
-<li>
-20.7.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
-</li>
-<li>
-<p>20.7.11.2.1 [unique.ptr.single.ctor]/21:</p>
-<blockquote>
-<i>Requires:</i> If <tt>D</tt> is not a reference type, construction of
-the deleter <tt>D</tt> from an rvalue of type <tt>E</tt> shall be well
-formed and shall not throw an exception. If <tt>D</tt> is a reference
-type, then <tt>E</tt> shall be the same type as <tt>D</tt> (diagnostic
-required). <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt>.
-<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
-be complete types. <i>-- end note</i>]</ins>
-</blockquote>
-<p><i>[
-N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt>
-is completely defined, because it requires that <tt>Convertible<U*, T*></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>
-<li>
+
+<hr>
+<h3><a name="819"></a>819. rethrow_if_nested</h3>
+<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-25 <b>Last modified:</b> 2008-09-17</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-20.7.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
+Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
+got it quite right.
</p>
-<blockquote>
+
<p>
-<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
-shall have well-defined behavior, and shall not throw exceptions.
-<ins>[<i>Note:</i> The use of <tt>default_delete</tt> requires <tt>T</tt> to
-be a complete type. <i>-- end note</i>]</ins>
+The current wording says:
</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>template <class E> void rethrow_if_nested(const E& 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>
-</li>
-<li>
<p>
-20.7.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
-current editorial issue, that "must shall" has to be changed to
-"shall", but this change is not a special part of this resolution.
+This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
+derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
+required to be sure. Unfortunately, if <tt>e</tt> is dynamically but not statically
+derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
</p>
<p><i>[
-N.B. The current wording is sufficient, because we can delegate all
-further requirements on the requirements of the effects clause
+San Francisco:
]</i></p>
-</li>
-
-<li>
-<p>
-20.7.11.2.3 [unique.ptr.single.asgn]/6:
-</p>
<blockquote>
-<i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
-<tt>D</tt> shall not throw an exception. <tt>U*</tt> shall be implicitly
-convertible to <tt>T*</tt>.
-<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
-be complete types. <i>-- end note</i>]</ins>
+Alisdair was volunteered to provide wording.
</blockquote>
-<p><i>[
-N.B.: The current wording of p. 6 already implicitly guarantees that
-<tt>U</tt> is completely defined, because it requires that <tt>Convertible<U*, T*></tt>
-is true, see (6)+(8).
-]</i></p>
-</li>
+<p><b>Proposed resolution:</b></p>
-<li>
-<p>
-20.7.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
-</p>
-<p><i>[
-N.B.: Delegation to requirements of effects clause is sufficient.
-]</i></p>
-</li>
-<li>
-20.7.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11:
-</li>
-<blockquote>
-<pre>T* operator->() const;</pre>
-<blockquote>
-<ins><i>Note:</i> Use typically requires <tt>T</tt> shall be complete. <i>-- end note</i>]</ins>
-</blockquote>
-</blockquote>
-<li>
-20.7.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
-</li>
+<hr>
+<h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
+<p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> James Kanze <b>Opened:</b> 2008-04-01 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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#Tentatively%20NAD">Tentatively NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I just noticed that the following program is legal in C++03, but
+is forbidden in the current draft:
+</p>
+
+<blockquote><pre>#include <vector>
+#include <iostream>
+
+class Toto
+{
+public:
+ Toto() {}
+ explicit Toto( Toto const& ) {}
+} ;
+
+int
+main()
+{
+ std::vector< Toto > v( 10 ) ;
+ return 0 ;
+}
+</pre></blockquote>
-<li>
<p>
-20.7.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
+Is this change intentional? (And if so, what is the
+justification? I wouldn't call such code good, but I don't see
+any reason to break it unless we get something else in return.)
</p>
+
+<p><i>[
+San Francisco:
+]</i></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.
+The subgroup that looked at this felt this was a good change, but it may
+already be handled by incoming concepts (we're not sure).
</blockquote>
-</li>
-<li>
-20.7.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
-</li>
+<b>
+Original Proposed resolution:
+</b>
-<li>
<p>
-20.7.11.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1:
+In X [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>
-A specialization for array types is provided with a slightly altered interface.
+In X [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
</p>
-<ul>
-<li>
-...
-</li>
-<li>
-<ins><tt>T</tt> shall be a complete type.</ins>
-</li>
-</ul>
+<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>
-</li>
-</ol>
<p><i>[
-post Bellevue: Daniel provided revised wording.
+Post Summit:
]</i></p>
+<blockquote>
+<p>
+Alisdair: Proposed resolution kinda funky as these tables no longer
+exist. Move from direct init to copy init. Clarify with Doug, recommends
+NAD.
+</p>
+<p>
+Walter: Suggest NAD via introduction of concepts.
+</p>
+<p>
+Recommend close as NAD.
+</p>
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+Recommend close as NAD.
+</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<int> x, y;
- std::deque<int>::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>?
+<hr>
+<h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3>
+<p><b>Section:</b> 19.5.2.2 [syserr.errcode.overview], 20.8.13.2.8
+[util.smartptr.shared.io], 22.4.8 [facets.examples], 20.3.6.3
+[bitset.operators], 26.4.6 [complex.ops], 27.6 [stream.buffers], 28.10
+[re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-04-10 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Should the following use rvalues references to stream in insert/extract
+operators?
+</p>
- </p>
- <pre> i == y.end() && j == x.end()
- </pre>
- <p>
+<ul>
+<li>19.5.2.2 [syserr.errcode.overview]</li>
+<li>20.8.13.2.8 [util.smartptr.shared.io]</li>
+<li>22.4.8 [facets.examples]</li>
+<li>20.3.6.3 [bitset.operators]</li>
+<li>26.4.6 [complex.ops]</li>
+<li>Doubled signatures in 27.6 [stream.buffers] for character inserters
+(ref 27.7.2.6.4 [ostream.inserters.character])
++ definition 27.7.2.6.4 [ostream.inserters.character]</li>
+<li>28.10 [re.submatch]</li>
+</ul>
-(There are at least two implementations where the expression
-returns <code>false</code>.)
+<p><i>[
+Sophia Antipolis
+]</i></p>
- </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?
+<blockquote>
+Agree with the idea in the issue, Alisdair to provide wording.
+</blockquote>
- </p>
- <p>
+<p><i>[
+Daniel adds 2009-02-14:
+]</i></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>
+<blockquote>
+The proposal given in the paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2831.html">N2831</a>
+apparently resolves this issue.
+</blockquote>
-<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><i>[
+Batavia (2009-05):
+]</i></p>
- </p>
+<blockquote>
+<p>
+The cited paper is an earlier version of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>,
+which changed the rvalue reference binding rules.
+That paper includes generic templates
+<tt>operator<<</tt> and <tt>operator>></tt>
+that adapt rvalue streams.
+</p>
+<p>
+We therefore agree with Daniel's observation.
+Move to NAD Editorial.
+</p>
+</blockquote>
<p><b>Proposed resolution:</b></p>
<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.6.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
+<p><b>Section:</b> 20.8.13.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-11 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-N2461 already replaced in 20.6.15.2 [func.wrap.func] it's originally proposed
-(implicit) conversion operator to "unspecified-bool-type" by the new
-explicit bool conversion, but the inverse conversion should also
-use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer-
-type".
+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>
+<p><i>[
+San Francisco:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
+<blockquote>
<p>
-In 20.6 [function.objects], header <tt><functional></tt> synopsis replace:
+It's not clear to us that you can initialize a pointer with the literal
+0 in a constant expression. We need to ask CWG to make sure this works.
+Bjarne has been appointed to do this.
</p>
-
-<blockquote><pre>template<class R, class... ArgTypes>
- bool operator==(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template<class R, class... ArgTypes>
- bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
-template<class R, class... ArgTypes>
- bool operator!=(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template<class R, class... ArgTypes>
- bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
-</pre></blockquote>
-
<p>
-In the class function synopsis of 20.6.15.2 [func.wrap.func] replace
+Core got back to us and assured as that <tt>nullptr</tt> would do the job
+nicely here.
</p>
+</blockquote>
+
+<p><i>[
+2009-05-01 Alisdair adds:
+]</i></p>
-<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-...
-function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-</pre></blockquote>
+<blockquote>
<p>
-In 20.6.15.2 [func.wrap.func], "Null pointer comparisons" replace:
+I don't believe that constexpr will buy anything in this case.
+<tt>shared_ptr/weak_ptr/enable_shared_from_this</tt> cannot be literal types as they
+have a non-trivial copy constructor. As they do not produce literal types,
+then the constexpr default constructor will <em>not</em> guarantee constant
+initialization, and so not buy the hoped for optimization.
</p>
-
-<blockquote><pre>template <class R, class... ArgTypes>
- bool operator==(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template <class R, class... ArgTypes>
- bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
-template <class R, class... ArgTypes>
- bool operator!=(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template <class R, class... ArgTypes>
- bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
-</pre></blockquote>
-
<p>
-In 20.6.15.2.1 [func.wrap.func.con], replace
+I recommend referring this back to Core to see if we can get static
+initialization for types with constexpr constructors, even if they are not
+literal types. Otherwise this should be closed as NAD.
</p>
+</blockquote>
-<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-...
-function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-</pre></blockquote>
+<p><i>[
+2009-05-26 Daniel adds:
+]</i></p>
-<p>
-In 20.6.15.2.6 [func.wrap.func.nullptr], replace
-</p>
-<blockquote><pre>template <class R, class... ArgTypes>
- bool operator==(const function<R(ArgTypes...)>& f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template <class R, class... ArgTypes>
- bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>& f);
-</pre></blockquote>
+<blockquote>
+If Alisdair's 2009-05-01 comment is correct, wouldn't that also make
+<tt>constexpr mutex()</tt> useless, because this class has a non-trivial
+destructor? (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>)
-<p>
-and replace
-</p>
+</blockquote>
-<blockquote><pre>template <class R, class... ArgTypes>
- bool operator!=(const function<R(ArgTypes...)>& f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template <class R, class... ArgTypes>
- bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>& f);
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
<hr>
-<h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3>
-<p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
+<p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-18 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.class">active issues</a> in [thread.mutex.class].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-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:
+[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
</p>
-
-<blockquote>
-<i>Throws:</i> nothing
-</blockquote>
-
<p>
-Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value
-this throws clause is impossible to realize in general, since the <tt>basic_string</tt>
-constructors can fail due to out-of-memory conditions. Either these throws
-clauses should be removed or should be more detailled like:
+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>
-<blockquote>
-<i>Throws:</i> Nothing if the string construction throws nothing
-</blockquote>
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+<blockquote>
+<p>
+We believe this is implementable on POSIX, because the initializer-list
+feature and the constexpr feature make this work. Double-check core
+language about static initialization for this case. Ask core for a core
+issue about order of destruction of statically-initialized objects wrt.
+dynamically-initialized objects (should come afterwards). Check
+non-POSIX systems for implementability.
+</p>
<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><string></tt> synopsis of 21.2 [string.classes] is correct in this
-regard).
+If ubiquitous implementability cannot be assured, plan B is to introduce
+another constructor, make this constexpr, which is
+conditionally-supported. To avoid ambiguities, this new constructor needs
+to have an additional parameter.
</p>
+</blockquote>
+<p><i>[
+Post Summit:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
+<blockquote>
<p>
-In 21.4 [string.conversions], remove the paragraphs 8 and 16.
+Jens: constant initialization seems to be ok core-language wise
+</p>
+<p>
+Consensus: Defer to threading experts, in particular a Microsoft platform expert.
+</p>
+<p>
+Lawrence to send e-mail to Herb Sutter, Jonathan Caves, Anthony Wiliams,
+Paul McKenney, Martin Tasker, Hans Boehm, Bill Plauger, Pete Becker,
+Peter Dimov to alert them of this issue.
+</p>
+<p>
+Lawrence: What about header file shared with C? The initialization
+syntax is different in C and C++.
+</p>
+<p>
+Recommend Keep in Review
</p>
-
-<blockquote>
-<pre>string to_string(long long val);
-string to_string(unsigned long long val);
-string to_string(long double val);
-</pre>
-<blockquote>
-<del><i>Throws:</i> nothing</del>
-</blockquote>
</blockquote>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
<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>
+Keep in Review status pending feedback from members of the Concurrency subgroup.
</blockquote>
-</blockquote>
-
-
-
+<p><i>[
+See related comments from Alisdiar and Daniel in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>.
+]</i></p>
-<hr>
-<h3><a name="772"></a>772. Impossible return clause in [string.conversions]</h3>
-<p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
-overloads says:
-</p>
-<blockquote>
-<i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character
-representation of the value of its argument that would be generated by
-calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>,
-or <tt>L"%f"</tt>, respectively.
-</blockquote>
+<p><b>Proposed resolution:</b></p>
<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><wchar.h>/<cwchar></tt>, but this has the non-equivalent
-declaration:
+Change 30.4.1.1 [thread.mutex.class]:
</p>
-<blockquote><pre>int swprintf(wchar_t * restrict s, size_t n,
-const wchar_t * restrict format, ...);
+<blockquote><pre>class mutex {
+public:
+ <ins>constexpr</ins> mutex();
+ ...
</pre></blockquote>
-<p>
-therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>.
-</p>
-<p><b>Proposed resolution:</b></p>
+
+<hr>
+<h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3>
+<p><b>Section:</b> 21.2 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2008-04-23 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-Change the current wording of 21.4 [string.conversions]/p. 15 to:
+ Paragraph 4 of 21.2 [char.traits] mentions that this
+ section specifies two specializations (<code>char_traits<char></code>
+ and (<code>char_traits<wchar_t></code>). However, there are actually
+ four specializations provided, i.e. in addition to the two above also
+ <code>char_traits<char16_t></code> and <code>char_traits<char32_t></code>).
+ I guess this was just an oversight and there is nothing wrong with just
+ fixing this.
</p>
+<p><i>[
+Alisdair adds:
+]</i></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>.
+<tt>char_traits< char16/32_t ></tt>
+should also be added to <tt><ios_fwd></tt> in 27.3 [iostream.forward], and all the specializations
+taking a <tt>char_traits</tt> parameter in that header.
</blockquote>
-<p>
-[Hint to the editor: The resolution also adds to mention the name of
-the format specifier "fmt"]
-</p>
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+<blockquote>
<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>.
+Idea of the issue is ok.
</p>
-
<p>
-Change the current wording of 21.4 [string.conversions]/p. 7 to:
+Alisdair to provide wording, once that wording arrives, move to review.
</p>
-<blockquote>
-<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the
-character representation of the value of its argument that would be
-generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of
-<tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal
-character buffer of sufficient size</ins>.
</blockquote>
+<p><i>[
+2009-05-04 Alisdair adds:
+]</i></p>
-
-
-
-<hr>
-<h3><a name="774"></a>774. Member swap undefined for most containers</h3>
-<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>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>
+<blockquote>
<p>
-It appears most containers declare but do not define a member-swap
-function.
+The main point of the issue was resolved editorially in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>,
+so we are
+close to NAD Editorial.
+However, exploring the issue we found a second tweak was necessary for
+<tt><iosfwd></tt> and that is still outstanding, so here are the words I am long
+overdue delivering:
</p>
-<p>
-This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
-member-swap function!
-(required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
-[Table 87])
-</p>
+<p><i>[
+Howard: I've put Alisdair's words into the proposed wording section and
+moved the issue to Review.
+]</i></p>
-<p>
-Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
-yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
-definition.
-</p>
-<p>
-A quick survey of clause 23 shows that the following containers provide a
-definition for member-swap:
-</p>
+</blockquote>
-<blockquote><pre>array
-queue
-stack
-vector
-</pre></blockquote>
+<p><i>[
+Original proposed wording.
+]</i></p>
-<p>
-Whereas the following declare it, but do not define the semantics:
-</p>
-<blockquote><pre>deque
-list
-map
-multimap
-multiset
-priority_queue
-set
-unordered_map
-unordered_multi_map
-unordered_multi_set
-unordered_set
-</pre></blockquote>
+<blockquote>
<p>
-Suggested resolution:
+ Replace paragraph 4 of 21.2 [char.traits] by:
</p>
<blockquote>
-Provide a definition for each of the affected containers...
+<p>
+ This subclause specifies a struct template, <code>char_traits<charT></code>,
+ and four explicit specializations of it, <code>char_traits<char></code>,
+ <code>char_traits<char16_t></code>, <code>char_traits<char32_t></code>, and
+ <code>char_traits<wchar_t></code>, all of which appear in the header
+ <string> and satisfy the requirements below.
+</p>
+</blockquote>
</blockquote>
<p><i>[
-Bellevue:
+Batavia (2009-05):
]</i></p>
-
<blockquote>
-Move to Open and ask Alisdair to provide wording.
+We agree. Move to NAD Editorial.
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Wording provided in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>.
+Change Forward declarations 27.3 [iostream.forward]:
+</p>
+
+<blockquote>
+<p>
+<b>Header <tt><iosfwd></tt> synopsis</b>
</p>
+<pre>namespace std {
+ template<class charT> class char_traits;
+ template<> class char_traits<char>;
+ <ins>template<> class char_traits<char16_t>;</ins>
+ <ins>template<> class char_traits<char32_t>;</ins>
+ template<> class char_traits<wchar_t>;
+...
+}
+</pre>
+</blockquote>
<hr>
-<h3><a name="776"></a>776. Undescribed assign function of std::array</h3>
-<p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
+<p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-05-14 <b>Last modified:</b> 2009-03-11</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#compliance">active issues</a> in [compliance].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The class template array synopsis in 23.2.1 [array]/3 declares a member
-function
+Once the C++0x standard library is feature complete, the LWG needs to
+review 17.6.1.3 [compliance] Freestanding implementations header list to
+ensure it reflects LWG consensus.
</p>
-<blockquote><pre>void assign(const T& u);
-</pre></blockquote>
+<p><i>[
+San Francisco:
+]</i></p>
+
+<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.
+This is a placeholder defect to remind us to review the table once we've
+stopped adding headers to the library.
</p>
-
<p>
-I found only one reference to this function in the issue list,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a> where the question is raised:
+Three new headers that need to be added to the list:
</p>
-
-<blockquote>
-what's the effect of calling <tt>assign(T&)</tt> on a zero-sized array?
-</blockquote>
-
+<blockquote><pre><initializer_list> <concept> <iterator_concepts>
+</pre></blockquote>
<p>
-which does not answer the basic question of this issue.
+<tt><iterator_concepts></tt>, in particular, has lots of stuff
+that isn't needed, so maybe the stuff that is needed should be broken
+out into a separate header.
</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.
+Robert: What about <tt>reference_closure</tt>? It's currently in
+<tt><functional></tt>.
</p>
+</blockquote>
+
+<p><i>[
+Post Summit Daniel adds:
+]</i></p>
+
+
+<blockquote>
+<ol>
+<li>
+The comment regarding <tt>reference_closure</tt> seems moot since it was just
+recently decided to remove that.
+</li>
+<li>
+A reference to proposal
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a>
+("Fixing freestanding") should be added. This
+paper e.g. proposes to add only <tt><initializer_list></tt> to the include list
+of freestanding.
+</li>
+</ol>
+</blockquote>
+
<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& u);
-</pre>
-<p>
-1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
-</p>
-</blockquote>
+
+<hr>
+<h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
+<p><b>Section:</b> 20.8.12.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-05-14 <b>Last modified:</b> 2008-06-19</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-[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]
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>) proposes a useful
+extension point for <tt>unique_ptr</tt> by granting support for an optional
+<tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
+(In the following: <tt>pointer</tt>).
</p>
-
<p>
-Change the synopsis in 23.2.1 [array]/3:
+Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
+impact on at least two key features of <tt>unique_ptr</tt>:
</p>
-<blockquote><pre>template <class T, size_t N>
-struct array {
- ...
- void <del>assign</del> <ins>fill</ins>(const T& u);
- ...
-</pre></blockquote>
+<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-defects.html#762">762</a>).
+</p>
<p><i>[
-Bellevue:
+Sophia Antipolis:
]</i></p>
<blockquote>
<p>
-Suggest substituting "fill" instead of "assign".
+Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the
+arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector<T>::iterator</tt>.
</p>
<p>
-Set state to Review given substitution of "fill" for "assign".
+Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function.
</p>
</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#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-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>
-
-
<p><b>Proposed resolution:</b></p>
<p>
-In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with:
+Add the following sentence just at the end of the newly proposed
+20.8.12.2 [unique.ptr.single]/p. 3:
</p>
<blockquote>
-<i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
-and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be
-valid.</ins>
+<tt>unique_ptr<T, D>::pointer</tt>'s operations shall be well-formed, shall have well
+defined behavior, and shall not throw exceptions.
</blockquote>
-
<hr>
-<h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
-<p><b>Section:</b> 25.3.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
+<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
-<p>
-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>
-<p>
-Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461
-have no Requires element and the Effects element contains some requirements,
-which is probably editorial. Worse is that:
-</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.
-<ul>
-<li>
-no assignment requirements are specified (neither implicit nor explicit).
-</li>
+ </p>
+ <p>
-<li>
-the effects clause just speaks of "merges", which is badly worded
-near to a circular definition.
-</li>
+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.
-<li>
-p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
-function arguments or otherwise.
-</li>
+ </p>
+ <p>
-<li>
-p. 2 says "according to the ordering defined by comp" which is both
-incomplete (because
-this excludes the first variant with <) and redundant (because the
-following subordinate
-clause mentions comp again)
-</li>
-</ul>
+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 << std::flush;</code>
+
+ </p>
+ <blockquote>
+ <pre>#include <iostream>
+int main ()
+{
+ std::cout.tie (&std::cerr);
+ std::cerr.tie (&std::cout);
+ std::cout << "cout\n";
+ std::cerr << "cerr\n";
+}
+</pre>
+</blockquote>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Review.
+</blockquote>
+
+<p><i>[
+2009-05-26 Daniel adds:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In 25.3.4 [alg.merge] replace p.1+ 2:
-</p>
<blockquote>
<p>
-<i>Effects:</i> <del>Merges</del> <ins>Copies all the elements of the</ins> two sorted ranges <tt>[first1,last1)</tt> and
-<tt>[first2,last2)</tt> into the range
-<del><tt>[result,result + (last1 - first1) + (last2 - first2))</tt></del>
-<ins><tt>[result, last)</tt> (where <tt>last</tt> is equal to <tt>result + (last1
-- first1) + (last2 - first2))</tt>, such that resulting range will be
-sorted in non-decreasing order; that is, for every iterator <tt>i</tt> in
-<tt>[result,last)</tt> other than <tt>result</tt>, the condition <tt>*i < *(i - 1)</tt> or,
-respectively, <tt>comp(*i, *(i - 1))</tt> will be false</ins>.
+I think that the most recently suggested change in
+27.7.2.4 [ostream::sentry] need some further word-smithing. As
+written, it would make the behavior undefined, if under
+conditions when <tt>pubsync()</tt> should be called, but when
+in this scenario <tt>os.rdbuf()</tt> returns 0.
</p>
-
<p>
-<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 < *(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>
+This case is explicitly handled in <tt>flush()</tt> and needs to be
+taken care of. My suggested fix is:
</p>
+
+<blockquote>
+If <tt>((os.flags() & ios_base::unitbuf) && !uncaught_exception()</tt>
+<ins><tt>&& os.rdbuf() != 0</tt></ins>) is true, calls <del><tt>os.flush()</tt></del>
+<ins><tt>os.rdbuf()->pubsync()</tt></ins>.
</blockquote>
<p>
-[N.B.: I attempted to reuse the wording style of <tt>inplace_merge</tt>,
-therefore proposing to
-insert ", respectively," between both predicate tests. This is no
-strictly necessary as
-other parts of <tt><algorithm></tt> show, just a matter of consistency]
+Two secondary questions are:
</p>
+<ol>
+<li>
+Should <tt>pubsync()</tt> be invoked in any case or shouldn't a
+base requirement for this trial be that <tt>os.good() == true</tt>
+as required in the original <tt>flush()</tt> case?
+</li>
+<li>
+Since <tt>uncaught_exception()</tt> is explicitly tested, shouldn't
+a return value of -1 of <tt>pubsync()</tt> produce <tt>setstate(badbit)</tt>
+(which may throw <tt>ios_base::failure</tt>)?
+</li>
+</ol>
+</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->tie()</code>
+through <code>tiestr()->tie()->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.
-<hr>
-<h3><a name="785"></a>785. Random Number Requirements in TR1</h3>
-<p><b>Section:</b> TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> John Maddock <b>Date:</b> 2008-01-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Table 16 of TR1 requires that all Pseudo Random Number generators have a
-</p>
+ </p>
+ <p>
-<blockquote><pre>seed(integer-type s)
-</pre></blockquote>
+Add a <i>Requires</i> clause to 27.5.4.2 [basic.ios.members] withethe following
+text:
-<p>
-member function that is equivalent to:
-</p>
+ </p>
+ <blockquote>
-<blockquote><pre>mygen = Generator(s)
-</pre></blockquote>
+<i>Requires:</i> If <code>(tiestr != 0)</code> is
+true, <code>tiestr</code> must not be reachable by traversing the
+linked list of tied stream objects starting
+from <code>tiestr->tie()</code>.
-<p>
-But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
-</p>
+ </blockquote>
+ <p>
-<blockquote><pre>template <class Gen>
-seed(Gen&);
-</pre></blockquote>
+In addition, to prevent the infinite recursion that Bo writes about in
+his comp.lang.c++.moderated post, I propose to change
+27.7.2.4 [ostream::sentry], p2 like so:
-<p>
-member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
-</p>
+ </p>
+ <blockquote>
-<p>
-So... is this a bug in TR1?
-</p>
+If <code>((os.flags() & ios_base::unitbuf) &&
+!uncaught_exception())</code> is true,
+calls <del>os.flush()</del> <ins><code>os.rdbuf()->pubsync()</code></ins>.
-<p>This is a real issue BTW, since the Boost implementation does adhere
-to the requirements of Table 16, while at least one commercial
-implementation does not and follows a strict adherence to sections
-5.1.4.5 and 5.1.4.6 instead.
-</p>
+ </blockquote>
+
-<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>
+<hr>
+<h3><a name="836"></a>836.
+ effects of <code>money_base::space</code> and
+ <code>money_base::none</code> on <code>money_get</code>
+ </h3>
+<p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2008-09-22</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>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a></p>
+<p><b>Discussion:</b></p>
+ <p>
+In paragraph 2, 22.4.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="787"></a>787. complexity of <tt>binary_search</tt></h3>
-<p><b>Section:</b> 25.3.3.4 [binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-08</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 25.3.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as
-</p>
+where <code>money_base::space</code> appears in the format, at least
+one space is required, and
-<blockquote>
-At most <tt>log(last - first) + 2</tt> comparisons.
-</blockquote>
+ </li>
+ <li>
-<p>
-This should be precised and brought in line with the nomenclature used for
-<tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>.
-</p>
+where <code>money_base::none</code> appears in the format, space is
+allowed but not required.
-<p>
-All existing libraries I'm aware of, delegate to
-<tt>lower_bound</tt> (+ one further comparison). Since
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>
-has now WP status, the resolution of #787 should
-be brought in-line with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> by changing the <tt>+ 2</tt>
-to <tt>+ O(1)</tt>.
-</p>
+ </li>
+ </ol>
+ </blockquote>
+ <p>
+
+The other is that:
+
+ </p>
+ <blockquote>
+
+where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
+
+ </blockquote>
<p><i>[
-Sophia Antipolis:
+San Francisco:
]</i></p>
<blockquote>
-Alisdair prefers to apply an upper bound instead of O(1), but that would
-require fixing for <tt>lower_bound</tt>, <tt>upper_bound</tt> etc. as well. If he really
-cares about it, he'll send an issue to Howard.
+Martin will revise the proposed resolution.
</blockquote>
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+I propose to change the text to make it clear that the first
+interpretation is intended, that is, to make following change to
+22.4.6.1.2 [locale.money.get.virtuals], p2:
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 25.3.3.4 [binary.search]/3
-</p>
+ </p>
-<blockquote>
-<i>Complexity:</i> At most <tt>log<ins><sub>2</sub></ins>(last - first) + <del>2</del> <ins><i>O</i>(1)</ins></tt> comparisons.
-</blockquote>
+ <blockquote>
+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() & str.showbase)</code> is <code>false</code>, ...
+ </blockquote>
+
<hr>
-<h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
-<p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-02-06</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="837"></a>837.
+ <code>basic_ios::copyfmt()</code> overly loosely specified
+ </h3>
+<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
-<p>
-The description of how an istream_iterator object becomes an
-end-of-stream iterator is a) ambiguous and b) out of date WRT
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>:
-</p>
-
-<blockquote>
-<tt>istream_iterator</tt> reads (using <tt>operator>></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&</tt> is
-returned. The result of <tt>operator-></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>
-<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>
-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>></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&</tt> is
-returned. The result of <tt>operator-></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>
+The <code>basic_ios::copyfmt()</code> member function is specified in 27.5.4.2 [basic.ios.members] to have the following effects:
+ </p>
+ <blockquote>
+<i>Effects</i>: If <code>(this == &rhs)</code> does
+nothing. Otherwise assigns to the member objects of <code>*this</code>
+the corresponding member objects of <code>rhs</code>, except that
-<hr>
-<h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
-<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>discrete_distribution</tt> should have a constructor like:
-</p>
+ <ul>
+ <li>
-<blockquote><pre>template<class _Fn>
- discrete_distribution(result_type _Count, double _Low, double _High,
- _Fn& _Func);
-</pre></blockquote>
+<code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
-<p>
-(Makes it easier to fill a histogram with function values over a range.)
-</p>
+ </li>
+ <li>
-<p><i>[
-Bellevue:
-]</i></p>
+<code>exceptions()</code> is altered last by
+calling <code>exceptions(rhs.except)</code>
+ </li>
+ <li>
-<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>
+the contents of arrays pointed at by <code>pword</code>
+and <code>iword</code> are copied not the pointers themselves
-<p><i>[
-Sophia Antipolis:
-]</i></p>
+ </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.
-<blockquote>
-<p>
-Bill is not requesting this.
-</p>
-<p>
-Marc Paterno: <tt>_Fn</tt> cannot return negative values at the points where the
-function is sampled. It is sampled in the middle of each bin. <tt>_Fn</tt> cannot
-return 0 everywhere it is sampled.
-</p>
-<p>
-Jens: lambda expressions are rvalues
-</p>
-<p>
-Add a library issue to provide an
-<tt>initializer_list<double></tt> constructor for
-<tt>discrete_distribution</tt>.
-</p>
-<p>
-Marc Paterno: dislikes reference for <tt>_Fn</tt> parameter. Make it pass-by-value (to use lambda),
-use <tt>std::ref</tt> to wrap giant-state function objects.
</p>
-<p>
-Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference.
-</p>
-<p>
-Daniel to draft wording.
-</p>
-</blockquote>
<p><i>[
-Pre San Francisco, Daniel provided wording:
+Batavia (2009-05):
]</i></p>
-
<blockquote>
-The here proposed changes of the WP refer to the current state of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
-During the Sophia Antipolis meeting two different proposals came up
-regarding the functor argument type, either by value or by rvalue-reference.
-For consistence with existing conventions (state-free algorithms and the
-<tt>general_pdf_distribution</tt> c'tor signature) the author decided to propose a
-function argument that is provided by value. If severe concerns exists that
-stateful functions would be of dominant relevance, it should be possible to
-replace the two occurrences of <tt>Func</tt> by <tt>Func&&</tt> in this proposal as part
-of an editorial process.
+We agree with the proposed resolution.
+Move to NAD Editorial.
</blockquote>
-
<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>
-In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
-<em>before</em> the member declaration
-</p>
-
-<blockquote><pre>explicit discrete_distribution(const param_type& parm);
-</pre></blockquote>
-
-<p>
-insert:
-</p>
-
-
-<blockquote><pre>template<typename Func>
-discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
-</pre></blockquote>
-</li>
-
-<li>
-<p>
-Between p.4 and p.5 insert a series of new paragraphs as part of the
-new member description::
-</p>
-<blockquote><pre>template<typename Func>
-discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
-</pre>
-
-<p>
-<i>Complexity:</i> Exactly nf invocations of fw.
-</p>
<p>
-<i>Requires:</i>
-</p>
-<ol type="a">
-<li>
-fw shall be callable with one argument of type double, and shall
-return values of a type convertible to double;</li>
-<li>If nf > 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> < <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
-<tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN,
-and non-infinity;</li>
+I propose to tighten things up by adding a <i>Postcondition</i> clause
+to the function like so:
-<li>The following relations shall hold: nf ≥ 0, and 0 < S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
+ </p>
+ <blockquote>
+ <i>Postconditions:</i>
-</ol>
+ <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>
-<p>
-<i>Effects:</i>
-</p>
-<ol type="a">
-<li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
- consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
+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.
-<li>
-<p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> +
-0.5 * deltax.</p>
-<blockquote><pre>For each k = 0, . . . ,n-1, calculates:
- <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
- <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
-</pre></blockquote>
-</li>
-<li>
-<p>Constructs a discrete_distribution object with probabilities:</p>
-<blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S for k = 0, . . . , n-1.
-</pre></blockquote>
-</li>
-</ol>
-</blockquote>
-</li>
-</ol>
+ </p>
+ <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="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
-<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
+<h3><a name="838"></a>838.
+ can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
+ </h3>
+<p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2008-10-27</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
-<p>
-<tt>piecewise_constant_distribution</tt> should have a constructor like:
-</p>
+ <p>
-<blockquote><pre>template<class _Fn>
- piecewise_constant_distribution(size_t _Count,
- _Ty _Low, _Ty _High, _Fn& _Func);
-</pre></blockquote>
+From message c++std-lib-20003...
-<p>
-(Makes it easier to fill a histogram with function values over a range.
-The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>) make a sensible replacement for
-<tt>general_pdf_distribution</tt>.)
-</p>
+ </p>
+ <p>
-<p><i>[
-Sophia Antipolis:
-]</i></p>
+The description of <code>istream_iterator</code> in
+24.6.1 [istream.iterator], p1 specifies that objects of the
+class become the <i>end-of-stream</i> (EOS) iterators under the
+following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a> another problem
+with this paragraph):
+ </p>
+ <blockquote>
-<blockquote>
-<p>
-Marc: uses variable width of bins and weight for each bin. This is not
-giving enough flexibility to control both variables.
-</p>
-<p>
-Add a library issue to provide an constructor taking an
-<tt>initializer_list<double></tt> and <tt>_Fn</tt> for <tt>piecewise_constant_distribution</tt>.
-</p>
-<p>
-Daniel to draft wording.
-</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.
-<p><i>[
-Pre San Francisco, Daniel provided wording.
-]</i></p>
+ </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 >> value</code>, without checking
+for <code>(in_stream == 0)</code>.
-<blockquote>
-The here proposed changes of the WP refer to the current state of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
-For reasons explained in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, the author decided to propose a function
-argument that is provided by value. The issue proposes a c'tor signature,
-that does not take advantage of the full flexibility of
-<tt>piecewise_constant_distribution</tt>,
-because it restricts on a constant bin width, but the use-case seems to
-be popular enough to justify it's introduction.
-</blockquote>
+ </p>
+ <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>
-<p><b>Proposed resolution:</b></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.
-<ol>
-<li>
-<p>
-In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
-just <em>before</em> the member declaration
-</p>
+ </p>
+ <p>
-<blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm);
-</pre></blockquote>
-<p>
-insert:
-</p>
-<blockquote><pre>template<typename Func>
-piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
-</pre></blockquote>
-</li>
+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 << "2 3 ";
+ assert (it != eos);
+ i = *++it;
+ assert (3 == i);
+ </pre>
+ </blockquote>
+ <p>
+
+Or is it intended that once an iterator becomes EOS it stays EOS until
+the end of its lifetime?
+
+ </p>
+
+ <p><i>[
+San Francisco:
+]</i></p>
-<li>
-<p>
-Between p.4 and p.5 insert a new sequence of paragraphs nominated
-below as [p5_1], [p5_2],
-[p5_3], and [p5_4] as part of the new member description:
-</p>
-<blockquote><pre>template<typename Func>
-piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
-</pre>
<blockquote>
<p>
-[p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
-</p>
-<p>
-[p5_2] <i>Requires:</i>
-</p>
-<ol type="a">
-<li><tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
-return values of a type convertible to double;
-</li>
-<li>
-For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight
-value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
-</li>
-<li>
-The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> < <tt><i>x<sub>max</sub></i></tt>, and
-0 < S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
-</li>
-</ol>
-<p>
-[p5_3] <i>Effects:</i>
+We like the direction of the proposed resolution. We're not sure about
+the wording, and we need more time to reflect on it,
</p>
-<ol type="a">
-<li>
-<p>If nf == 0,</p>
- <ol type="a">
- <li>
-sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
-<li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
- value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
-<li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and
- <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
-</li>
-</ol>
-</li>
-<li>
-<p>Otherwise,</p>
-<ol type="a">
-<li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n,
- <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
-</li>
-<li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p>
-<blockquote><pre>for each k = 0, . . . ,n-1, calculates:
- <tt><i>dx<sub>k</sub></i></tt> = k * deltax
- <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
- <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
- <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
-</pre></blockquote>
-<p> and</p>
-</li>
-<li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
-</ol>
-</li>
-<li>
<p>
-Constructs a <tt>piecewise_constant_distribution</tt> object with
-the above computed sequence <tt>b</tt> as the interval boundaries
-and with the probability densities:
+Move to Open. Detlef to rewrite the proposed resolution in such a way
+that no reference is made to exposition only members of
+<tt>istream_iterator</tt>.
</p>
-<blockquote><pre><tt><i>ρ<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax) for k = 0, . . . , n-1.
-</pre></blockquote>
-</li>
-</ol>
-<p>
-[p5_4] <i>Remarks:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly
- known as the <i>bins</i> of a histogram.
- </p>
-</blockquote>
</blockquote>
-</li>
-</ol>
-
+ <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>
-<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>
+To this end we propose to change 24.6.1 [istream.iterator], p1,
+as follows:
-<p>
-There are two more minor issues:
-</p>
+ </p>
+ <blockquote>
-<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>
+The result of operator-> 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><i>[
-Bellevue:
-]</i></p>
+ </blockquote>
+ <p>
+Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
-<blockquote>
-Move to OPEN Bill will try to propose a resolution by the next meeting.
-</blockquote>
+ </p>
+ <blockquote>
-<p><i>[
-post Bellevue: Bill provided wording.
-]</i></p>
+<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>
-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>
+<pre>istream_iterator(istream_type &s);</pre>
+<i>Effects</i>: Initializes <code>in_stream</code> with &s. value
+may be initialized during construction or the first time it is
+referenced.<br>
+<ins><i>Postcondition</i>: <code>in_stream == &s</code>.</ins>
+<pre>istream_iterator(const istream_iterator &x);</pre>
-<p><b>Proposed resolution:</b></p>
-<p>
-Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with:
-</p>
+<i>Effects</i>: Constructs a copy of <code>x</code>.<br>
+<ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
-<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>
+<pre>istream_iterator& operator++();</pre>
-<blockquote><pre>for( v.clear(); n > 0; n -= 32 )
- v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
-</pre></blockquote>
-</blockquote>
+<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
+<i>Effects</i>: <code>*in_stream >> value</code>.
+<pre>istream_iterator& 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 >> value;
+return tmp;
+ </pre>
+ </blockquote>
+ </blockquote>
+
<hr>
-<h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
-<p><b>Section:</b> 2
0.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-02-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
+<h3><a name="839"></a>839. Maps and sets missing splice operation</h3>
+<p><b>Section:</b> 2
3.4 [associative], 23.5 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2008-05-18 <b>Last modified:</b> 2008-09-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative">active issues</a> in [associative].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative">issues</a> in [associative].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Classes with trivial special member functions are inherently more
-efficient than classes without such functions. This efficiency is
-particularly pronounced on modern ABIs that can pass small classes
-in registers. Examples include value classes such as complex numbers
-and floating-point intervals. Perhaps more important, though, are
-classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>. When the
-parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
-themselves can be trivial, leading to substantial performance wins.
-</p>
-<p>
-The current working draft make specification of trivial functions
-(where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
-As long as the semantics of defaulted and deleted functions match
-the intended semantics, specification of defaulted and deleted
-functions will yield more efficient programs.
-</p>
-<p>
-There are at least two cases where specification of an explicitly
-defaulted function may be desirable.
-</p>
-<p>
-First, the <tt>std::pair</tt> template has a non-trivial default constructor,
-which prevents static initialization of the pair even when the
-types are statically initializable. Changing the definition to
+Splice is a very useful feature of <tt>list</tt>. This functionality is also very
+useful for any other node based container, and I frequently wish it were
+available for maps and sets. It seems like an omission that these
+containers lack this capability. Although the complexity for a splice is
+the same as for an insert, the actual time can be much less since the
+objects need not be reallocated and copied. When the element objects are
+heavy and the compare operations are fast (say a <tt>map<int, huge_thingy></tt>)
+this can be a big win.
</p>
-<blockquote><pre>pair() = default;
-</pre></blockquote>
-
<p>
-would enable such initialization. Unfortunately, the change is
-not semantically neutral in that the current definition effectively
-forces value initialization whereas the change would not value
-initialize in some contexts.
+<b>Suggested resolution:</b>
</p>
<p>
-** Does the committee confirm that forced value initialization
-was the intent? If not, does the committee wish to change the
-behavior of <tt>std::pair</tt> in C++0x?
-</p>
-<p>
-Second, the same default constructor issue applies to <tt>std::tuple</tt>.
-Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
-which effectively prevents passing it in registers. To enable
-passing <tt>tuples</tt> in registers, the copy constructor should be
-make explicitly <tt>default</tt>ed. The new declarations are:
+Add the following signatures to map, set, multimap, multiset, and the unordered associative containers:
</p>
-
-<blockquote><pre>tuple() = default;
-tuple(const tuple&) = default;
+<blockquote><pre>
+void splice(list<T,Allocator>&& x);
+void splice(list<T,Allocator>&& x, const_iterator i);
+void splice(list<T,Allocator>&& x, const_iterator first, const_iterator last);
</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?
+Hint versions of these are also useful to the extent hint is useful.
+(I'm looking for guidance about whether hints are in fact useful.)
</p>
+
+<blockquote><pre>
+void splice(const_iterator position, list<T,Allocator>&& x);
+void splice(const_iterator position, list<T,Allocator>&& x, const_iterator i);
+void splice(const_iterator position, list<T,Allocator>&& x, const_iterator first, const_iterator last);
+</pre></blockquote>
<p><i>[
-Bellevue:
+Sophia Antipolis:
]</i></p>
<blockquote>
<p>
-General agreement; the first half of the issue is NAD.
+Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type.
</p>
<p>
-Before voting on the second half, it was agreed that a "Strongly Favor"
-vote meant support for trivial tuples (assuming usual requirements met),
-even at the expense of other desired qualities. A "Weakly Favor" vote
-meant support only if not at the expense of other desired qualities.
+<tt>forward_list</tt> already has <tt>splice_after</tt>.
</p>
<p>
-Concensus: Go forward, but not at expense of other desired qualities.
+Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>?
</p>
<p>
-It was agreed to Alisdair should fold this work in with his other
-pair/tuple action items, above, and that issue 801 should be "open", but
-tabled until Alisdair's proposals are disposed of.
+Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s.
</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
<p>
+Howard: <tt>adopt</tt>?
</p>
-
-
-
-
-
-<hr>
-<h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2008-02-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-<tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt>
-object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a
-32-bit vector.
+Jens: <tt>absorb</tt>?
</p>
<p>
-This repacking triggers several problems:
+Alan: <tt>subsume</tt>?
</p>
-<ol>
-<li>
-Distinctness of the output of <tt>seed_seq::generate</tt> required the
-introduction of the initial "<tt>if (w < 32) v.push_back(n);</tt>" (Otherwise
-the unsigned short vectors [1, 0] and [1] generate the same sequence.)
-</li>
-<li>
-Portability demanded the introduction of the template parameter <tt>u</tt>.
-(Otherwise some sequences could not be obtained on computers where no
-integer types are exactly 32-bits wide.)
-</li>
-<li>
-The description and algorithm have become unduly complicated.
-</li>
-</ol>
<p>
-I 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).
+Robert: <tt>recycle</tt>?
</p>
<p>
-Here's how the description would read
+Howard: <tt>transfer</tt>? (but no direction)
</p>
-<blockquote>
<p>
-26.4.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
+Jens: <tt>transfer_from</tt>. No.
</p>
-
-<blockquote>
-<pre>template<class InputIterator>
- seed_seq(InputIterator begin, InputIterator end);
-</pre>
-<blockquote>
<p>
-5 <i>Requires:</i> NO CHANGE
+Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes.
</p>
<p>
-6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by
+Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow.
</p>
-<blockquote>
-<pre>for (InputIterator s = begin; s != end; ++s)
- v.push_back((*s) mod 2^32);
-</pre>
-</blockquote>
-</blockquote>
-</blockquote>
</blockquote>
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<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<InputIterator>::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.
+Martin: this would possibly outlaw an implementation technique that is
+currently in use; caching nodes in containers.
</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
+Alan: if you cache in the allocator, rather than the individual
+container, this proposal doesn't interfere with that.
</p>
-<blockquote><pre>v = { 0x3, 0x434241 };
-</pre></blockquote>
<p>
-while the simplified proposal yields
+Martin: I'm not opposed to this, but I'd like to see an implementation
+that demonstrates that it works.
</p>
-<blockquote><pre>v = { 0x41, 0x42, 0x43 };
-</pre></blockquote>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="847"></a>847. string exception safety guarantees</h3>
+<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Hervé Brönnimann <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2009-02-14</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.require">active issues</a> in [string.require].</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#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
<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.
+In March, on comp.lang.c++.moderated, I asked what were the
+string exception safety guarantees are, because I cannot see
+*any* in the working paper, and any implementation I know offers
+the strong exception safety guarantee (string unchanged if a
+member throws exception). The closest the current draft comes to
+offering any guarantees is 21.4 [basic.string], para 3:
</p>
-</li>
-<li>
+
+<blockquote>
+The class template <tt>basic_string</tt> conforms to the requirements
+for a Sequence Container (23.1.1), for a Reversible Container (23.1),
+and for an Allocator-aware container (91). The iterators supported by
+<tt>basic_string</tt> are random access iterators (24.1.5).
+</blockquote>
+
<p>
-With long strings (e.g., with bit-length comparable to the number of
- bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified
- proposal and <tt>seed_seq::generate</tt> will be slower.
+However, the chapter 23 only says, on the topic of exceptions: 23.2 [container.requirements],
+para 10:
</p>
+
+<blockquote>
<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>.
+Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following
+additional requirements:
</p>
-</li>
-<li>
+
+<ul>
+<li>if an exception is thrown by...</li>
+</ul>
+</blockquote>
+
<p>
-A user can pass an array of 64-bit integers and all the bits will be
- used.
+I take it as saying that this paragraph has *no* implication on
+<tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and
+this paragraph does not define a *requirement* of Sequence
+nor Reversible Container, just of the models defined in Clause 23.
+In addition, LWG Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a> proposes to remove 23.2 [container.requirements], para 3.
</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
+Finally, the fact that no operation on Traits should throw
+exceptions has no bearing, except to suggest (since the only
+other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>)
+that the strong exception guarantee can be achieved.
</p>
-<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.
+The reaction in that group by Niels Dekker, Martin Sebor, and
+Bo Persson, was all that this would be worth an LWG issue.
</p>
-</li>
-</ul>
<p>
-Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>.
+A related issue is that <tt>erase()</tt> does not throw. This should be
+stated somewhere (and again, I don't think that the 23.2 [container.requirements], para 1
+applies here).
</p>
<p><i>[
-Bellevue:
+San Francisco:
]</i></p>
<blockquote>
-Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
+Implementors will study this to confirm that it is actually possible.
</blockquote>
<p><i>[
-Sophia Antipolis:
+Daniel adds 2009-02-14:
]</i></p>
<blockquote>
-<p>
-Marc Paterno wants portable behavior between 32bit and 64bit machines;
-we've gone to significant trouble to support portability of engines and
-their values.
-</p>
-<p>
-Jens: the new algorithm looks perfectly portable
-</p>
-<p>
-Marc Paterno to review off-line.
-</p>
-<p>
-Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..."
-</p>
-<p>
-Disposition: move to review; unanimous consent.
-</p>
-<p>
-(moots <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>)
-</p>
+The proposed resolution of paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a>
+interacts with this issue (the paper does not refer to this issue).
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Change 26.4.7.1 [rand.util.seedseq]:
+Add a blanket statement in 21.4.1 [string.require]:
</p>
<blockquote>
-<pre>template<class InputIterator<del>,
- size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
- 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<InputIterator>::value_type</tt> shall denote an integral type.
+- if any member function or operator of <tt>basic_string<charT, traits, Allocator></tt>
+throws, that function or operator has no effect.
</p>
<p>
--6- Constructs a <tt>seed_seq</tt> object by <ins>the following algorithm</ins> <del>rearranging some or all of the bits of the supplied sequence
-<tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
+- no <tt>erase()</tt> or <tt>pop_back()</tt> function throws.
</p>
+</blockquote>
+
<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 = ∑<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>
+As far as I can tell, this is achieved by any implementation. If I made a
+mistake and it is not possible to offer this guarantee, then
+either state all the functions for which this is possible
+(certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>),
+or add paragraphs to Effects clauses wherever appropriate.
</p>
-<blockquote><pre><del>
-v.clear();
-if ($w$ < 32)
- v.push_back($n$);
-for( ; $n$ > 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="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3>
-<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="851"></a>851. simplified array construction</h3>
+<p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Benjamin Kosnik <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2009-06-10</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 type="A">
-<li>
<p>
-19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and
-19.4.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses
-declare an expository data member <tt>cat_</tt>:
+This is an issue that came up on the libstdc++ list, where a
+discrepancy between "C" arrays and C++0x's <tt>std::array</tt> was pointed
+out.
+</p>
+
+<p>
+In "C," this array usage is possible:
</p>
-<blockquote><pre>const error_category& cat_; // exposition only
+
+<blockquote><pre>int ar[] = {1, 4, 6};
</pre></blockquote>
+
<p>
-which is used to define the semantics of several members. The decision
-to use a member of reference type lead to several problems:
+But for C++,
</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>
+
+<blockquote><pre>std::array<int> a = { 1, 4, 6 }; // error
+</pre></blockquote>
+
<p>
-The simple fix would be to replace the reference by a pointer member.
+Instead, the second parameter of the <tt>array</tt> template must be
+explicit, like so:
</p>
-</li>
-<li>
-I would like to give the editorial remark that in both classes the
-constrained <tt>operator=</tt>
-overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
-usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
-parameter the return type would be defined to be <tt>void&</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>
+<blockquote><pre>std::array<int, 3> a = { 1, 4, 6 };
+</pre></blockquote>
-<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>
+Doug Gregor proposes the following solution, that assumes
+generalized initializer lists.
+</p>
+
+<blockquote><pre>template<typename T, typename... Args>
+inline array<T, sizeof...(Args)>
+make_array(Args&&... args)
+{ return { std::forward<Args>(args)... }; }
+</pre></blockquote>
+
+<p>
+Then, the way to build an <tt>array</tt> from a list of unknown size is:
+</p>
+
+<blockquote><pre>auto a = make_array<T>(1, 4, 6);
+</pre></blockquote>
<p><i>[
-Sophia Antipolis:
+San Francisco:
]</i></p>
<blockquote>
<p>
-Part A: NAD (editorial), cleared by the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.
+Benjamin: Move to Ready?
+</p>
+<p>
+Bjarne: I'm not convinced this is useful enough to add, so I'd like us
+to have time to reflect on it.
</p>
<p>
-Part B: Technically correct, save for typo. Rendered moot by the concept proposal
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2620.html">N2620</a>) NAD (editorial).
+Alisdair: the constraints are wrong, they should be
</p>
+<blockquote><pre>template<ValueType T, ValueType... Args>
+requires Convertible<Args, T>...
+array<T, sizeof...(Args)> make_array(Args&&... args);
+</pre></blockquote>
<p>
-Part C: We agree; this is consistent with the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>.
+Alidair: this would be useful if we had a constexpr version.
</p>
<p>
-Howard: please ping Beman, asking him to clear away parts A and B from
-the wording in the proposed resolution, so it is clear to the editor
-what needs to be applied to the working paper.
+Bjarne: this is probably useful for arrays with a small number of
+elements, but it's not clearly useful otherwise.
</p>
<p>
-Beman provided updated wording. Since issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a> is not going
-forward, the provided wording includes resolution of part A.
+Consensus is to move to Open.
</p>
</blockquote>
+<p><i>[
+2009-06-07 Daniel adds:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-
+<blockquote>
<p>
-Resolution of part A:
+I suggest a fix and a simplification of the current proposal: Recent
+prototyping by
+Howard showed, that a fix is required because narrowing conversion
+8.5.4 [dcl.init.list]/6 b.3
+would severely limit the possible distribution of argument types, e.g.
+the expression
+<tt>make_array<double>(1, 2.0)</tt> is ill-formed, because the narrowing
+happens <em>inside</em> the
+function body where no constant expressions exist anymore. Furthermore
+given e.g.
</p>
-<blockquote>
+<blockquote><pre>int f();
+double g();
+</pre></blockquote>
<p>
-Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated:
+we probably want to support
</p>
-
-<blockquote><pre>private:
- int val_; // exposition only
- const error_category<del>&</del><ins>*</ins> cat_; // exposition only
+<blockquote><pre>make_array<double>(f(), g());
</pre></blockquote>
<p>
-Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated:
+as well. To make this feasible, the currently suggested expansion
</p>
-<blockquote>
-<pre>error_code();
-</pre>
-<blockquote>
+<blockquote><pre>{ std::forward<Args>(args)... }
+</pre></blockquote>
+
<p>
-<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
+needs to be replaced by
</p>
+
+<blockquote><pre>{ static_cast<T>(std::forward<Args>(args))... }
+</pre></blockquote>
+
<p>
-<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>system_category</tt>.
+which is safe, because we already ensure convertibility via the
+element-wise <tt>Convertible<Args, T></tt> requirement. Some other fixes are
+necessary: The <tt>ValueType</tt> requirement for the function <em>parameters</em>
+is invalid, because all lvalue arguments will deduce to an lvalue-reference,
+thereby no longer satisfying this requirement.
</p>
+
<p>
-<i>Throws:</i> Nothing.
+The suggested simplification is to provide a default-computed effective
+type for the result array based on common_type and decay, in
+unconstrained form:
</p>
-</blockquote>
-<pre>error_code(int val, const error_category& cat);
-</pre>
-<blockquote>
+
+<blockquote><pre>template<typename... Args>
+array<typename decay<typename common_type<Args...>::type>::type,
+sizeof...(Args)>
+make_array(Args&&... args);
+</pre></blockquote>
+
<p>
-<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
-</p>
+The approach used below is similar to that of <tt>make_pair</tt> and <tt>make_tuple</tt>
+using a symbol <tt>C</tt> to represent the decayed common type [Note: Special
+handling of <tt>reference_wrapper</tt> types is intentionally <em>not</em> provided, because
+our target has so satisfy <tt>ValueType</tt>, thus under the revised proposal only
+an all-<tt>reference_wrapper</tt>-arguments would be well-formed and an array of
+<tt>reference_wrapper</tt> will be constructed]. I do currently not suggest to
+add new concepts reflecting <tt>decay</tt> and <tt>common_type</tt>, but an implementor will
+need something like this to succeed. Note that we use a similar fuzziness for
+<tt>make_pair</tt> and <tt>make_tuple</tt> currently. This fuzziness is not related to
+the currently
+missing <tt>Constructible<Vi, Ti&&></tt> requirement for those functions. The following
+proposal fixes that miss for <tt>make_array</tt>. If the corresponding <tt>C</tt> type
+deduction is
+explicitly wanted for standardization, here the implementation
+</p>
+
+<blockquote><pre>auto concept DC<typename... T> {
+ typename type = typename decay<typename common_type<T...>::type>::type;
+}
+</pre></blockquote>
+
<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
+where <tt>C</tt> is identical to <tt>DC<Args...>::type</tt> in the proposed resolution below.
</p>
<p>
-<i>Throws:</i> Nothing.
+I intentionally added no further type relation between type and the concept
+template parameters, but instead added this requirement below to make
+the specification as transparent as possible. As written this concept is
+satisfied, if the corresponding associated type exists.
</p>
-</blockquote>
-</blockquote>
-<p>
-Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated:
-</p>
+<p><b>Suggested Resolution:</b></p>
-<blockquote>
-<pre>void assign(int val, const error_category& cat);
-</pre>
-<blockquote>
+<ol>
+<li>
<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
+Add to the array synopsis in 23.3 [sequences]:
</p>
+<blockquote><pre><ins>
+template<ReferentType... Args>
+requires ValueType<C> && Constructible<C, Args&&>...
+array<C, sizeof...(Args)>
+make_array(Args&&... args);
+</ins>
+</pre></blockquote>
+</li>
+
+<li>
<p>
-<i>Throws:</i> Nothing.
+Append after 23.3.1.7 [array.tuple] Tuple interface to class template array
+the following new section:
+</p>
+<blockquote>
+<p>
+23.4.1.7 Array creation functions [array.creation]
</p>
+
+<pre><ins>
+template<ReferentType... Args>
+requires ValueType<C> && Constructible<C, Args&&>...
+array<C, sizeof...(Args)>
+make_array(Args&&... args);</ins>
+</pre>
+
+<blockquote>
+<p><ins>
+Let <tt>C</tt> be <tt>decay<common_type<Args...>::type>::type</tt>.
+</ins></p>
+<p>
+<ins><i>Returns:</i> an <tt>array<C, sizeof...(Args)></tt> initialized with
+<tt>{ static_cast<C>(std::forward<Args>(args))... }</tt>.
+</ins></p>
</blockquote>
</blockquote>
+</li>
+
+</ol>
+
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated:
+Add to the <tt>array</tt> synopsis in 23.3 [sequences]:
+</p>
+
+<blockquote><pre>template<ValueType T, ValueType... Args>
+ requires Convertible<Args, T>...
+ array<T, sizeof...(Args)>
+ make_array(Args&&... args);
+</pre></blockquote>
+
+<p>
+Append after 23.3.1.7 [array.tuple] Tuple interface to class template <tt>array</tt> the
+following new section.
</p>
-<blockquote>
-const error_category& category() const;
<blockquote>
<p>
-<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
+23.2.1.7 Convenience interface to class template <tt>array</tt> [array.tuple]
</p>
+
+<pre>template<ValueType T, ValueType... Args>
+ requires Convertible<Args, T>...
+ array<T, sizeof...(Args)>
+ make_array(Args&&... args);
+</pre>
+
+<blockquote>
<p>
-<i>Throws:</i> Nothing.
+<i>Returns:</i> an <tt>array<T, sizeof...(Args)></tt> initialized with <tt>{std::forward<T>(args)...}</tt>.
</p>
</blockquote>
</blockquote>
-<p>
-Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated:
-</p>
-<blockquote><pre>private:
- int val_; // exposition only
- const error_category<del>&</del><ins>*</ins> cat_; // exposition only
-</pre></blockquote>
+
+
+<hr>
+<h3><a name="853"></a>853. <tt>to_string</tt> needs updating with <tt>zero</tt> and <tt>one</tt></h3>
+<p><b>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18 <b>Last modified:</b> 2009-05-10</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a> adds defaulted arguments to the <tt>to_string</tt> member, but neglects to update
+the three newer <tt>to_string</tt> overloads.
</p>
+
<p><i>[
-(If the proposed resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has already been applied, the
-name <tt>posix_category</tt> will have been changed to <tt>generic_category</tt>. That has
-no effect on this resolution.)
+post San Francisco:
]</i></p>
<blockquote>
-<pre>error_condition();
-</pre>
+Daniel found problems with the wording and provided fixes. Moved from Ready
+to Review.
+</blockquote>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
<blockquote>
<p>
-<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
+Alisdair: suggest to not repeat the default arguments in B, C, D
+(definition of to_string members)
</p>
<p>
-<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>posix_category</tt>.
+Walter: This is not really a definition.
</p>
<p>
-<i>Throws:</i> Nothing.
+Consensus: Add note to the editor: Please apply editor's judgement
+whether default arguments should be repeated for B, C, D changes.
</p>
-</blockquote>
-<pre>error_condition(int val, const error_category& cat);
-</pre>
-<blockquote>
<p>
-<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
+Recommend Tentatively Ready.
</p>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
+</blockquote>
+
+<p><i>[
+2009-05-09: See alternative solution in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol type="A">
+<li>
+<p>replace in 20.3.6 [template.bitset]/1 (class <tt>bitset</tt>)
</p>
+<blockquote><pre>template <class charT, class traits>
+ basic_string<charT, traits, allocator<charT> >
+ to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
+template <class charT>
+ basic_string<charT, char_traits<charT>, allocator<charT> >
+ to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
+basic_string<char, char_traits<char>, allocator<char> >
+ to_string(<ins>char zero = '0', char one = '1'</ins>) const;
+</pre></blockquote>
+</li>
+<li>
<p>
-<i>Throws:</i> Nothing.
+replace in 20.3.6.2 [bitset.members]/37
</p>
+<blockquote><pre>template <class charT, class traits>
+ basic_string<charT, traits, allocator<charT> >
+ to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
+</pre>
+<blockquote>
+37 <i>Returns:</i> <tt>to_string<charT, traits, allocator<charT> >(<ins>zero, one</ins>)</tt>.
</blockquote>
</blockquote>
-
+</li>
+<li>
<p>
-Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
+replace in 20.3.6.2 [bitset.members]/38
</p>
+<blockquote><pre>template <class charT>
+ basic_string<charT, char_traits<charT>, allocator<charT> >
+ to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
+</pre>
<blockquote>
-void assign(int val, const error_category& cat);
-<blockquote>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
+38 <i>Returns:</i> <tt>to_string<charT, char_traits<charT>, allocator<charT> >(<ins>zero, one</ins>)</tt>.
</blockquote>
</blockquote>
+</li>
+<li>
<p>
-Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated:
+replace in 20.3.6.2 [bitset.members]/39
</p>
+<blockquote><pre>basic_string<char, char_traits<char>, allocator<char> >
+ to_string(<ins>char zero = '0', char one = '1'</ins>) const;
+</pre>
<blockquote>
-const error_category& category() const;
-<blockquote>
+39 <i>Returns:</i> <tt>to_string<char, char_traits<char>, allocator<char> >(<ins>zero, one</ins>)</tt>.
+</blockquote>
+</blockquote>
+</li>
+
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3>
+<p><b>Section:</b> 20.8.12.1.1 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
+No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template.
</p>
<p>
-<i>Throws:</i> Nothing.
+Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor<T></tt>;
+the latter should also become a concept.
</p>
-</blockquote>
-</blockquote>
-</blockquote>
-
<p>
-Resolution of part C:
+Rules out cross-casting.
</p>
-
-<blockquote>
-
<p>
-In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
+The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter.
</p>
-<blockquote>
-<pre>virtual string message(int ev) const = 0;
-</pre>
+<p><i>[
+Howard adds 2008-11-26:
+]</i></p>
+
<blockquote>
<p>
-<i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>.
+I believe we need to be careful to not outlaw the following use case, and
+I believe the current proposed wording
+(<tt>requires Convertible<U*, T*> && HasVirtualDestructor<T></tt>) does so:
</p>
+
+<blockquote><pre>#include <memory>
+
+int main()
+{
+ std::unique_ptr<int> p1(new int(1));
+ std::unique_ptr<const int> p2(move(p1));
+ int i = *p2;
+<font color="#c80000">// *p2 = i; // should not compile</font>
+}
+</pre></blockquote>
+
<p>
-<del><i>Throws:</i> Nothing.</del>
+I've removed "<tt>&& HasVirtualDestructor<T></tt>" from the
+<tt>requires</tt> clause in the proposed wording.
</p>
-</blockquote>
+
</blockquote>
-<p>
-In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
-</p>
+<p><i>[
+Post Summit:
+]</i></p>
+
-<blockquote>
-<pre>string message() const;
-</pre>
<blockquote>
<p>
-<i>Returns:</i> <tt>category().message(value())</tt>.
+Alisdair: This issue has to stay in review pending a paper constraining
+<tt>unique_ptr</tt>.
</p>
<p>
-<del><i>Throws:</i> Nothing.</del>
+Consensus: We agree with the resolution, but <tt>unique_ptr</tt> needs
+to be constrained, too.
</p>
-</blockquote>
-</blockquote>
-
<p>
-In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
+Recommend Keep in Review.
</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
<blockquote>
-<pre>string message() const;
-</pre>
-<blockquote>
+Keep in Review status for the reasons cited.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-<i>Returns:</i> <tt>category().message(value())</tt>.
+Change 20.8.12.1.1 [unique.ptr.dltr.dflt]:
</p>
+
+<blockquote><pre>namespace std {
+ template <class T> struct default_delete {
+ default_delete();
+ template <class U>
+ <ins>requires Convertible<U*, T*></ins>
+ default_delete(const default_delete<U>&);
+ void operator()(T*) const;
+ };
+}
+</pre></blockquote>
+
<p>
-<del><i>Throws:</i> Nothing.</del>
+...
</p>
-</blockquote>
-</blockquote>
-</blockquote>
+<blockquote><pre>template <class U>
+ <ins>requires Convertible<U*, T*></ins>
+ default_delete(const default_delete<U>& other);
+</pre></blockquote>
<hr>
-<h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
-<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-02-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3>
+<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-06-13 <b>Last modified:</b> 2009-06-14</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-19.4 [syserr]
+The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so
+obscure that even the class' designer can't deduce it correctly. Several
+people have independently stumbled on this issue.
</p>
-
-<blockquote><pre>namespace posix_error {
- enum posix_errno {
- address_family_not_supported, // EAFNOSUPPORT
- ...
+<p>
+It might be simpler to change the return type to a scoped enum:
+</p>
+<blockquote><pre>enum class timeout { not_reached, reached };
</pre></blockquote>
<p>
-should rather use the new scoped-enum facility (7.2 [dcl.enum]),
-which would avoid the necessity for a new <tt>posix_error</tt>
-namespace, if I understand correctly.
+That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be:
</p>
+<blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached )
+ throw time_out();
+</pre></blockquote>
+
+<p><i>[
+Beman to supply exact wording.
+]</i></p>
+
+
<p><i>[
-Further discussion:
+San Francisco:
]</i></p>
<blockquote>
<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>,
-Strongly Typed Enums, since renamed Scoped Enums.
+There is concern that the enumeration names are just as confusing, if
+not more so, as the bool. You might have awoken because of a signal or a
+spurious wakeup, for example.
</p>
<p>
-Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
+Group feels that this is a defect that needs fixing.
</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.
+Group prefers returning an enum over a void return.
</p>
<p>
-The wording for the Proposed resolution was provided by Beman Dawes.
+Howard to provide wording.
</p>
</blockquote>
+<p><i>[
+2009-06-14 Beman provided wording.
+]</i></p>
+
+
<p><b>Proposed resolution:</b></p>
<p>
-Change System error support 19.4 [syserr] as indicated:
+Change Condition variables 30.5 [thread.condition], Header
+condition_variable synopsis, 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 <> struct is_error_condition_enum<<del>posix_error::posix_errno</del> <ins>errc</ins>>
- : public true_type {}
+<blockquote><pre>namespace std {
+ class condition_variable;
+ class condition_variable_any;
-<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>
+ <ins>enum class cv_status { no_timeout, timeout };</ins>
+}
</pre></blockquote>
<p>
-Change System error support 19.4 [syserr] :
+Change Class condition_variable 30.5.1 [thread.condition.condvar] as indicated:
</p>
+<blockquote><pre>class condition_variable {
+public:
+ ...
+ template <class Clock, class Duration>
+ <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock<mutex>& lock,
+ const chrono::time_point<Clock, Duration>& abs_time);
+ template <class Clock, class Duration, class Predicate>
+ bool wait_until(unique_lock<mutex>& lock,
+ const chrono::time_point<Clock, Duration>& abs_time,
+ Predicate pred);
+
+ template <class Rep, class Period>
+ <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock<mutex>& lock,
+ const chrono::duration<Rep, Period>& rel_time);
+ template <class Rep, class Period, class Predicate>
+ bool wait_for(unique_lock<mutex>& lock,
+ const chrono::duration<Rep, Period>& rel_time,
+ Predicate pred);
+ ...
+};
+
+...
+
+template <class Clock, class Duration>
+ <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock<mutex>& lock,
+ const chrono::time_point<Clock, Duration>& abs_time);
+</pre>
<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>
+-15- <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
+</p>
+<ul>
+<li>
+no other thread is waiting on this <tt>condition_variable</tt> object or
+</li>
+<li>
+<tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
+arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
+<tt>wait_for</tt> or <tt>wait_until</tt>.).
+</li>
+</ul>
<p>
-Change System error support 19.4 [syserr] and its subsections:
+-16- <i>Effects:</i>
</p>
-<blockquote>
<ul>
<li>
-remove all occurrences of <tt>posix_error::</tt>
+Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
</li>
<li>
-change all instances of <tt>posix_errno</tt> to <tt>errc</tt>
+When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
</li>
<li>
-change all instances of <tt>posix_category</tt> to <tt>generic_category</tt>
+The function will unblock when signaled by a call to <tt>notify_one()</tt>,
+a call to <tt>notify_all()</tt>, <del>by
+the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() >= abs_time</tt></ins>,
+or spuriously.
</li>
<li>
-change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt>
+If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
+to exiting the function scope.
</li>
</ul>
-</blockquote>
<p>
-Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2:
+-17- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
</p>
-<blockquote>
-<i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual
-functions shall behave as specified for the class <tt>error_category</tt>. The
-object's name virtual function shall return a pointer to the string
-<del>"POSIX"</del> <ins>"GENERIC"</ins>.
-</blockquote>
+<p>
+-18- <i>Returns:</i> <del><tt>Clock::now() < abs_time</tt></del>
+<ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
+was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
+</p>
<p>
-Change 19.4.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated:
+-19- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
+cannot be achieved.
</p>
-<blockquote>
-<pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
-</pre>
+<p>
+-20- <i>Error conditions:</i>
+</p>
-<blockquote>
-<i>Returns:</i> <tt>error_code(<ins>static_cast<int>(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
-</blockquote>
+<ul>
+<li>
+<tt>operation_not_permitted</tt> — if the thread does not own the lock.
+</li>
+<li>
+equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
+</li>
+</ul>
</blockquote>
+<pre>template <class Rep, class Period>
+ <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock<mutex>& lock,
+ const chrono::duration<Rep, Period>& rel_time);
+
+</pre>
+<blockquote>
+<p>
+-21- <i><del>Effects</del> <ins>Returns</ins>:</i>
+</p>
+<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
+</pre></blockquote>
<p>
-Change 19.4.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
+<del>-22- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
+duration specified by <tt>rel_time</tt> has elapsed,
+otherwise <tt>true</tt>.</del>
</p>
-<blockquote>
-<pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
-</pre>
+<p><i>[
+This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> in detail, but does
+not do so in spirit. If both issues are accepted, there is a logical merge.
+]</i></p>
-<blockquote>
-<i>Returns:</i> <tt>error_condition(<ins>static_cast<int>(</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>
+<pre>template <class Clock, class Duration, class Predicate>
+ bool wait_until(unique_lock<mutex>& lock,
+ const chrono::time_point<Clock, Duration>& abs_time,
+ Predicate pred);
+</pre>
-<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>
+<blockquote>
+<p>
+-23- <i>Effects:</i>
+</p>
+<blockquote><pre>while (!pred())
+ if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>)
+ return pred();
+return true;
+</pre></blockquote>
-<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>
+<p>
+-24- <i>Returns:</i> <tt>pred()</tt>.
+</p>
-<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>
+<p>
+-25- [<i>Note:</i>
+The returned value indicates whether the predicate evaluates to
+<tt>true</tt> regardless of whether the timeout was triggered.
+— <i>end note</i>].
+</p>
+</blockquote>
+</blockquote>
-<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>
+<p>
+Change Class condition_variable_any 30.5.2 [thread.condition.condvarany] as indicated:
+</p>
-<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>
+<blockquote><pre>class condition_variable_any {
+public:
+ ...
+ template <class Lock, class Clock, class Duration>
+ <del>bool</del> <ins>cv_status</ins> wait_until(Lock& lock,
+ const chrono::time_point<Clock, Duration>& abs_time);
+ template <class Lock, class Clock, class Duration, class Predicate>
+ bool wait_until(Lock& lock,
+ const chrono::time_point<Clock, Duration>& abs_time,
+ Predicate pred);
+
+ template <class Lock, class Rep, class Period>
+ <del>bool</del> <ins>cv_status</ins> wait_for(Lock& lock,
+ const chrono::duration<Rep, Period>& rel_time);
+ template <class Lock, class Rep, class Period, class Predicate>
+ bool wait_for(Lock& lock,
+ const chrono::duration<Rep, Period>& rel_time,
+ Predicate pred);
+ ...
+};
-<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>
+...
+template <class Lock, class Clock, class Duration>
+ <del>bool</del> <ins>cv_status</ins> wait_until(Lock& lock,
+ const chrono::time_point<Clock, Duration>& abs_time);
+</pre>
+<blockquote>
+<p>
+-13- <i>Effects:</i>
+</p>
+<ul>
+<li>
+Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
+</li>
+<li>
+When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
+</li>
+<li>
+The function will unblock when signaled by a call to <tt>notify_one()</tt>,
+a call to <tt>notify_all()</tt>, <del>by
+the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() >= abs_time</tt></ins>,
+or spuriously.
+</li>
+<li>
+If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
+to exiting the function scope.
+</li>
+</ul>
-<hr>
-<h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
-<p><b>Section:</b> 20.7.11.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-03-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-<tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
+-14- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
</p>
-<blockquote>
-<i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
-</blockquote>
-
<p>
-There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the
-deleter is called with a NULL pointer, and this is probably not what's
-intended (the destructor avoids calling the deleter with 0.)
+-15- <i>Returns:</i> <del><tt>Clock::now() < abs_time</tt></del>
+<ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
+was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
</p>
<p>
-Two, the special check for <tt>get() == p</tt> is generally not needed and such a
-situation usually indicates an error in the client code, which is being
-masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
-self-resets in 2001 and there were no complaints.
+-16- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
+cannot be achieved.
</p>
<p>
-One might think that self-resets are necessary for operator= to work; it's specified to perform
+-17- <i>Error conditions:</i>
</p>
-<blockquote><pre>reset( u.release() );
-</pre></blockquote>
+<ul>
+<li>
+equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
+</li>
+</ul>
+</blockquote>
+<pre>template <class Lock, class Rep, class Period>
+ <del>bool</del> <ins>cv_status</ins> wait_for(Lock& lock,
+ const chrono::duration<Rep, Period>& rel_time);
+
+</pre>
+
+<blockquote>
<p>
-and the self-assignment
+-18- <i><del>Effects</del> <ins>Returns</ins>:</i>
</p>
-
-<blockquote><pre>p = move(p);
+<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
</pre></blockquote>
<p>
-might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
-performed first, zeroing the stored pointer. In other words, <tt>p.reset(
-q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
-is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
-scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
+<del>-19- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
+duration specified by <tt>rel_time</tt> has elapsed,
+otherwise <tt>true</tt>.</del>
</p>
+<p><i>[
+This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> in detail, but does
+not do so in spirit. If both issues are accepted, there is a logical merge.
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 20.7.11.2.5 [unique.ptr.single.modifiers]:
-</p>
+</blockquote>
-<blockquote>
-<pre>void reset(T* p = 0);
+<pre>template <class Lock, class Clock, class Duration, class Predicate>
+ bool wait_until(Lock& lock,
+ const chrono::time_point<Clock, Duration>& <del>rel_time</del> <ins>abs_time</ins>,
+ Predicate pred);
</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>
+-20- <i>Effects:</i>
+</p>
+<blockquote><pre>while (!pred())
+ if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>)
+ return pred();
+return true;
+</pre></blockquote>
<p>
-Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:
+-21- <i>Returns:</i> <tt>pred()</tt>.
</p>
-<blockquote>
-<pre>void reset(T* p = 0);
-</pre>
-<blockquote>
-<p>...</p>
<p>
--2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+-22- [<i>Note:</i>
+The returned value indicates whether the predicate evaluates to
+<tt>true</tt> regardless of whether the timeout was triggered.
+— <i>end note</i>].
</p>
</blockquote>
+
</blockquote>
<hr>
-<h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
-<p><b>Section:</b> 20.4.1.2 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3>
+<p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-06-23 <b>Last modified:</b> 2009-06-14</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
-<p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors. I believe the same throws clause
-should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
-</p>
+<p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>.</p>
-<p><b>Proposed resolution:</b></p>
<p>
-Add to 20.4.1.2 [tuple.cnstr]:
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a>
+says that there is a class named <tt>monotonic_clock</tt>. It also says that this
+name may be a synonym for <tt>system_clock</tt>, and that it's conditionally
+supported. So the actual requirement is that it can be monotonic or not,
+and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at
+all (since it's conditionally supported). Okay, maybe too much
+flexibility, but so be it.
</p>
-
-<blockquote>
<p>
-For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
-or assignment of one of the types in <tt>Types</tt> throws an exception.
+A problem comes up in the threading specification, where several
+variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the
+meaning of an effects clause that says
</p>
-</blockquote>
+<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
+</pre></blockquote>
+<p>
+when <tt>monotonic_clock</tt> is not required to exist?
+</p>
+<p><i>[
+San Francisco:
+]</i></p>
-<hr>
-<h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
-<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
<p>
-p4 (forward) says:
+Nick: maybe instead of saying that chrono::monotonic_clock is
+conditionally supported, we could say that it's always there, but not
+necessarily supported..
</p>
-<blockquote>
-<i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
-</blockquote>
-
<p>
-First of all, lvalue-ness and rvalue-ness are properties of an expression,
-not of a type (see 3.10 [basic.lval]). Thus, the phrasing "Return type" is wrong.
-Second, the phrase says exactly what the core language wording says for
-folding references in 14.3.1 [temp.arg.type]/p4 and for function return values
-in 5.2.2 [expr.call]/p10. (If we feel the wording should be retained, it should
-at most be a note with cross-references to those sections.)
+Beman: I'd prefer a typedef that identifies the best clock to use for
+wait_for locks.
</p>
<p>
-The prose after the example talks about "forwarding as an <tt>int&</tt> (an lvalue)" etc.
-In my opinion, this is a category error: "<tt>int&</tt>" is a type, "lvalue" is a
-property of an expression, orthogonal to its type. (Btw, expressions cannot
-have reference type, ever.)
+Tom: combine the two concepts; create a duration clock type, but keep
+the is_monotonic test.
</p>
<p>
-Similar with move:
+Howard: if we create a duration_clock type, is it a typedef or an
+entirely true type?
</p>
-<blockquote>
-Return type: an rvalue.
-</blockquote>
<p>
-is just wrong and also redundant.
+There was broad preference for a typedef.
</p>
-
-
-<p><b>Proposed resolution:</b></p>
<p>
-Change 20.2.2 [forward] as indicated:
+Move to Open. Howard to provide wording to add a typedef for
+duration_clock and to replace all uses of monotonic_clock in function
+calls and signatures with duration_clock.
</p>
+</blockquote>
+
+<p><i>[
+Howard notes post-San Francisco:
+]</i></p>
-<blockquote>
-<pre>template <class T> T&& forward(typename identity<T>::type&& t);
-</pre>
<blockquote>
-<p>...</p>
<p>
-<del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
+After further thought I do not believe that creating a <tt>duration_clock typedef</tt>
+is the best way to proceed. An implementation may not need to use a
+<tt>time_point</tt> to implement the <tt>wait_for</tt> functions.
</p>
-<p>...</p>
+
<p>
--7- In the first call to <tt>factory</tt>, <tt>A1</tt> is deduced as <tt>int</tt>, so 2 is forwarded to <tt>A</tt>'s constructor
-as <del>an <tt>int&&</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
-as <tt>int&</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&</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&&</tt> (</del>an rvalue<del>)</del>.
+For example, on POSIX systems <tt>sleep_for</tt> can be implemented in terms of
+<tt>nanosleep</tt> which takes only a duration in terms of nanoseconds. The current
+working paper does not describe <tt>sleep_for</tt> in terms of <tt>sleep_until</tt>.
+And paragraph 2 of 30.2.4 [thread.req.timing] has the words strongly encouraging
+implementations to use monotonic clocks for <tt>sleep_for</tt>:
</p>
-</blockquote>
-
-<pre>template <class T> typename remove_reference<T>::type&& move(T&& t);
-</pre>
<blockquote>
-<p>...</p>
+2 The member functions whose names end in <tt>_for</tt> take an argument that
+specifies a relative time. Implementations should use a monotonic clock to
+measure time for these functions.
+</blockquote>
+
<p>
-<del><i>Return type:</i> an rvalue.</del>
+I believe the approach taken in describing the effects of <tt>sleep_for</tt>
+and <tt>try_lock_for</tt> is also appropriate for <tt>wait_for</tt>. I.e. these
+are not described in terms of their <tt>_until</tt> variants.
</p>
-</blockquote>
</blockquote>
-
-
-
-<hr>
-<h3><a name="809"></a>809. std::swap should be overloaded for array types</h3>
-<p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-02-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
<p>
-For the sake of generic programming, the header <code><algorithm></code> should provide an
-overload of <code>std::swap</code> for array types:
-</p><pre>template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
-</pre>
-
+Change 30.5.1 [thread.condition.condvar], p21-22:
+</p>
-<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<class T> class W {
-public:
- T data;
-};
-</pre>
-Clearly <code>W<T></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<T></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<class T> void swap(W<T>& x, W<T>& 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<std::string[8]></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<std::string[8]> 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!!!
+<blockquote>
+<pre>template <class Rep, class Period>
+ bool wait_for(unique_lock<mutex>& lock,
+ const chrono::duration<Rep, Period>& rel_time);
</pre>
+<blockquote>
+<p><ins>
+<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
+</ins></p>
+<ul>
+<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
+<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
+arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
+<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
+</ul>
+<p>
+21 <i>Effects:</i>
+</p>
+<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
+</pre></blockquote>
+<ul>
+<li><ins>
+Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
+</ins></li>
+
+<li><ins>
+When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
+</ins></li>
+
+<li><ins>
+The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call
+to <tt>notify_all()</tt>, by
+the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
+or spuriously.
+</ins></li>
+
+<li><ins>
+If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
+prior to exiting the function scope.
+</ins></li>
+</ul>
-<code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array,
-<code>std::string[8]</code>, which is not supported by the Standard Library.
-This issue is easily solved by providing an overload of <code>std::swap</code> for array types.
-This swap function should be implemented in terms of swapping the elements of the arrays, so that
-it would be non-throwing for arrays whose element types have a non-throwing swap.
+<p><ins>
+<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
+</ins></p>
<p>
-Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
-arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
-means of recursion.
+22 <i>Returns:</i> <tt>false</tt> if the call is returning because the time
+duration specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
</p>
-<p>
-For your information, there was a discussion on this issue at comp.lang.c++.moderated: <a href="http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9341ebd3635c9c74">[Standard
-Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
-</p>
+<p><i>[
+This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a> in detail, but does
+not do so in spirit. If both issues are accepted, there is a logical merge.
+]</i></p>
-<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>.
+<p><ins>
+<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
+</ins></p>
+
+<p><ins>
+<i>Error conditions:</i>
+</ins></p>
+
+<ul>
+<li><ins>
+<tt>operation_not_permitted</tt> -- if the thread does not own the lock.
+</ins></li>
+<li><ins>
+equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
+</ins></li>
+</ul>
+
</blockquote>
+</blockquote>
+
<p>
-Add the following to 25.2.3 [alg.swap]:
+Change 30.5.1 [thread.condition.condvar], p26-p29:
</p>
+
<blockquote>
-<pre>template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
+<pre>template <class Rep, class Period, class Predicate>
+ bool wait_for(unique_lock<mutex>& lock,
+ const chrono::duration<Rep, Period>& rel_time,
+ Predicate pred);
</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>
+<p><ins>
+<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
+</ins></p>
+<ul>
+<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
+<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
+arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
+<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
+</ul>
+<p>
+<i>26 Effects:</i>
+</p>
+<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
+</pre>
+<ul>
+<li><ins>
+Executes a loop: Within the loop the function first evaluates <tt>pred()</tt>
+and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
+</ins></li>
+<li><ins>
+Atomically calls <tt>lock.unlock()</tt>
+and blocks on <tt>*this</tt>.
+</ins></li>
+<li><ins>
+When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
+</ins></li>
+<li><ins>
+The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
+call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
+[thread.req.timing]), or spuriously.
+</ins></li>
+<li><ins>
+If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
+prior to exiting the function scope.
+</ins></li>
+<li><ins>
+The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
+duration specified by <tt>rel_time</tt> has elapsed.
+</ins></li>
+</ul>
</blockquote>
+<p>
+27 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
+even if the timeout has already expired. <i>-- end note</i>]
+</p>
+<p><ins>
+<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
+</ins></p>
-
-
-<hr>
-<h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
-<p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-03-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-The recent draft (as well as the original proposal n2072) uses an
-operational semantic
-for <tt>get_money</tt> ([ext.manip]/3) and <tt>put_money</tt> ([ext.manip]/5), which uses
+28 <i>Returns:</i> <tt>pred()</tt>
</p>
-<blockquote><pre>istreambuf_iterator<charT>
-</pre></blockquote>
-
<p>
-and
+29 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
+<tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
</p>
-<blockquote><pre>ostreambuf_iterator<charT>
-</pre></blockquote>
+<p><ins>
+<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
+</ins></p>
-<p>
-resp, instead of the iterator instances, with explicitly provided
-traits argument (The operational semantic defined by <tt>f</tt> is also traits
-dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
-c'tors expect a <tt>basic_streambuf<charT,traits></tt> as argument.
-</p>
-<p>
-The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic (p.
-7 and p. 9)
-of n2071 incorporated in N2521, where additional to the problem we
-have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
-<tt>istreambuf_iterator</tt>).
-</p>
+<p><ins>
+<i>Error conditions:</i>
+</ins></p>
+<ul>
+<li><ins>
+<tt>operation_not_permitted</tt> -- if the thread does not own the lock.
+</ins></li>
+<li><ins>
+equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
+</ins></li>
+</ul>
+
+</blockquote>
+</blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
-In 27.6.4 [ext.manip]/3 within function <tt>f</tt> replace the first line
+Change 30.5.2 [thread.condition.condvarany], p18-19:
</p>
-<blockquote><pre>template <class charT, class traits, class moneyT>
-void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) {
- typedef istreambuf_iterator<charT<ins>, traits</ins>> Iter;
- ...
-</pre></blockquote>
-
+<blockquote>
+<pre>template <class Lock, class Rep, class Period>
+ bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time);
+</pre>
+<blockquote>
<p>
-In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter:
+18 <i>Effects:</i>
</p>
-
-<blockquote><pre>template <<del>class charT, </del>class moneyT> unspecified put_money(const moneyT& mon, bool intl = false<ins>)</ins>;
+<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
</pre></blockquote>
-<p>
-In 27.6.4 [ext.manip]/5 within function <tt>f</tt> replace the first line
-</p>
+<ul>
+<li><ins>
+Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
+</ins></li>
+
+<li><ins>
+When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
+</ins></li>
+
+<li><ins>
+The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call to
+<tt>notify_all()</tt>, by
+the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
+or spuriously.
+</ins></li>
+
+<li><ins>
+If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
+prior to exiting the function scope.
+</ins></li>
+</ul>
-<blockquote><pre>template <class charT, class traits, class moneyT>
-void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) {
- typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter;
- ...
-</pre></blockquote>
+<p><ins>
+<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
+</ins></p>
<p>
-In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line
+19 <i>Returns:</i> <tt>false</tt> if the call is returning because the time duration
+specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
</p>
-<blockquote><pre>template <class charT, class traits>
-void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) {
- typedef <ins>i</ins>streambuf_iterator<charT<ins>, traits</ins>> Iter;
- ...
-</pre></blockquote>
+<p><ins>
+<i>Throws:</i> <tt>std::system_error</tt> when the returned value, effects,
+or postcondition cannot be achieved.
+</ins></p>
-<p>
-In 27.6.4 [ext.manip]/8 add const:
-</p>
+<p><ins>
+<i>Error conditions:</i>
+</ins></p>
-<blockquote><pre>template <class charT> unspecified put_time(<ins>const</ins> struct tm *tmb, const charT *fmt);
-</pre></blockquote>
+<ul>
+<li><ins>
+equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
+</ins></li>
+</ul>
+</blockquote>
+</blockquote>
<p>
-In 27.6.4 [ext.manip]/9 within function <tt>f</tt> replace the first line
+Change 30.5.2 [thread.condition.condvarany], p23-p26:
</p>
-<blockquote><pre>template <class charT, class traits>
-void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) {
- typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter;
- ...
-</pre></blockquote>
-
+<blockquote>
+<pre>template <class Lock, class Rep, class Period, class Predicate>
+ bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time, Predicate pred);
+</pre>
+<blockquote>
+<p><ins>
+<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
+</ins></p>
+<ul>
+<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
+<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
+arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
+<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
+</ul>
<p>
-Add to the <tt><iomanip></tt> synopsis in 27.6 [iostream.format]
+<i>23 Effects:</i>
</p>
-
-<blockquote><pre>template <class moneyT> unspecified get_money(moneyT& mon, bool intl = false);
-template <class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
-template <class charT> unspecified get_time(struct tm *tmb, const charT *fmt);
-template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-03-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<blockquote><pre>#include <utility>
-
-int main()
-{
- std::pair<char *, char *> p (0,0);
-}
-</pre></blockquote>
+<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
+</pre>
+<ul>
+<li><ins>
+Executes a loop: Within the loop the function first evaluates <tt>pred()</tt>
+and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
+</ins></li>
+<li><ins>
+Atomically calls <tt>lock.unlock()</tt>
+and blocks on <tt>*this</tt>.
+</ins></li>
+<li><ins>
+When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
+</ins></li>
+<li><ins>
+The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
+call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
+[thread.req.timing]), or spuriously.
+</ins></li>
+<li><ins>
+If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
+prior to exiting the function scope.
+</ins></li>
+<li><ins>
+The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
+duration specified by <tt>rel_time</tt> has elapsed.
+</ins></li>
+</ul>
+</blockquote>
<p>
-I just got a bug report about that, because it's valid C++03, but not
-C++0x. The important realization, for me, is that the emplace
-proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
-issue---didn't cause this break in backward compatibility. The break
-actually happened when we added this pair constructor as part of adding
-rvalue references into the language, long before variadic templates or
-emplace came along:
+24 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
+even if the timeout has already expired. <i>-- end note</i>]
</p>
-<blockquote><pre>template<class U, class V> pair(U&& x, V&& y);
-</pre></blockquote>
+<p><ins>
+<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
+</ins></p>
<p>
-Now, concepts will address this issue by constraining that <tt>pair</tt>
-constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
-"second", e.g. (from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
+25 <i>Returns:</i> <tt>pred()</tt>
</p>
-<blockquote><pre>template<class U , class V >
-requires Constructible<T1, U&&> && Constructible<T2, V&&>
-pair(U&& x , V&& y );
-</pre></blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
<p>
+26 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
+<tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
</p>
+<p><ins>
+<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
+</ins></p>
+<p><ins>
+<i>Error conditions:</i>
+</ins></p>
+<ul>
+<li><ins>
+<tt>operation_not_permitted</tt> -- if the thread does not own the lock.
+</ins></li>
+<li><ins>
+equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
+</ins></li>
+</ul>
-
-<hr>
-<h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3>
-<p><b>Section:</b> 25.3.1 [alg.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Paul McKenney <b>Date:</b> 2008-02-27</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Multi-threading is a good thing, but unsolicited multi-threading can
-potentially be harmful. For example, <tt>sort()</tt> performance might be
-greatly increased via a multithreaded implementation. However, such
-a multithreaded implementation could result in concurrent invocations
-of the user-supplied comparator. This would in turn result in problems
-given a caching comparator that might be written for complex sort keys.
-Please note that this is not a theoretical issue, as multithreaded
-implementations of <tt>sort()</tt> already exist.
-</p>
-<p>
-Having a multithreaded <tt>sort()</tt> available is good, but it should not
-be the default for programs that are not explicitly multithreaded.
-Users should not be forced to deal with concurrency unless they have
-asked for it.
-</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>
-
+</blockquote>
+</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
<hr>
-<h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2008-02-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="860"></a>860. Floating-Point State</h3>
+<p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-23 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#numerics">active issues</a> in [numerics].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numerics">issues</a> in [numerics].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Several places in 20.7.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
-However, that term is nowhere defined. The closest thing we have to a
-definition is that the default constructor creates an empty <tt>shared_ptr</tt>
-and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
-other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
-are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
-term or stop using it.
-</p><p>
+There are a number of functions that affect the floating point state.
+These function need to be thread-safe, but I'm unsure of the right
+approach in the standard, as we inherit them from C.
</p>
-One reason it's not good enough to leave this term up to the reader's
-intuition is that, in light of
-<a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
-and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, most readers'
-intuitive understanding is likely to be wrong. Intuitively one might
-expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
-but, whatever the definition is, that isn't it.
-
<p><i>[
-Peter adds:
+San Francisco:
]</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?
+Nick: I think we already say that these functions do not introduce data
+races; see 17.6.5.6/20
</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.
+Pete: there's more to it than not introducing data races; are these
+states maintained per thread?
</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?
+Howard: 21.5/14 says that strtok and strerror are not required to avoid
+data races, and 20.9/2 says the same about asctime, gmtime, ctime, and
+gmtime.
</p>
<p>
-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.
+Nick: POSIX has a list of not-safe functions. All other functions are
+implicitly thread safe.
</p>
-</li>
-
-<li>
<p>
-What are the properties of an empty <tt>shared_ptr</tt>?
+Lawrence is to form a group between meetings to attack this issue. Nick
+and Tom volunteered to work with Lawrence.
</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.
+Move to Open.
</p>
-</li>
+</blockquote>
-<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>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
<p>
-I agree that a clarification that is formally a no-op may add value.
+Hans: Sane oses seem ok. Sensible thing is implementable and makes sense.
</p>
-</li>
-
-<li>
<p>
-However, that term is nowhere defined.
+Nick: Default wording seems to cover this? Hole in POSIX, these
+functions need to be added to list of thread-unsafe functions.
</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:
+Lawrence: Not sufficient, not "thread-safe" per our definition, but
+think of state as a thread-local variable. Need something like "these
+functions only affect state in the current thread."
</p>
-<blockquote><pre>X x;
-X x2(x);
-X f(X x);
-X g(X x1, X x2);
-</pre></blockquote>
<p>
-A default-constructed value is green.<br>
-A copy has the same color as the original.<br>
-<tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br>
-<tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise.
+Hans: Suggest the following wording: "The floating point environment is
+maintained per-thread."
</p>
-
<p>
-Given these definitions, you can determine the color of every instance
-of type <tt>X</tt>, even if you have absolutely no idea what green and red mean.
+Walter: Any other examples of state being thread safe that are not
+already covered elsewhere?
</p>
-
<p>
-Green and red are "nowhere defined" and completely defined at the same time.
+Have thread unsafe functions paper which needs to be updated. Should
+just fold in 26.3 [cfenv] functions.
</p>
-</li>
-</ul>
-
<p>
-Alisdair's wording is fine.
+Recommend Open. Lawrence instead suggests leaving it open until we have
+suitable wording that may or may not include the thread local
+commentary.
</p>
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Append the following sentance to 20.7.12.2 [util.smartptr.shared]
</p>
-<blockquote>
-The <code>shared_ptr</code> class template stores a pointer, usually obtained
-via <code>new</code>. <code>shared_ptr</code> implements semantics of
-shared ownership; the last remaining owner of the pointer is responsible for
-destroying the object, or otherwise releasing the resources associated with
-the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
-a pointer is said to be <i>empty</i>.</ins>
-</blockquote>
<hr>
-<h3><a name="814"></a>814. <tt>vector<bool>::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>
+<h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3>
+<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-06-24 <b>Last modified:</b> 2008-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>
-<tt>vector<bool>::swap(reference, reference)</tt> has no definition.
+Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container
+member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>:
</p>
+<blockquote>
+<tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() &&
+equal(a.begin(), a.end(), b.begin()</tt>
+</blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
+The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function
+by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic.
+</p>
+<p>
+Other parts of the (sequence) container requirements do also depend on
+<tt>size()</tt>, e.g. <tt>empty()</tt>
+or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing
+<tt>EqualityComparable</tt> specification,
+because of the special design choices of <tt>forward_list</tt>.
+</p>
+<p>
+I propose to apply one of the following resolutions, which are described as:
</p>
+<ol type="A">
+<li>
+Provide a definition, which is optimal for this special container without
+previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt>
+with the corresponding container ranges and instead uses a special
+<tt>equals</tt> implementation which takes two container ranges instead of 1 1/2.
+</li>
+<li>
+The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced
+by <tt>distance</tt> with corresponding performance disadvantages.
+</li>
+</ol>
+<p>
+Both proposal choices are discussed, the preferred choice of the author is
+to apply (A).
+</p>
+<p><i>[
+San Francisco:
+]</i></p>
-
-<hr>
-<h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
-<p><b>Section:</b> 20.6.15.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-16</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
<p>
-<tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
-described in the rvalue core proposal.
+There's an Option C: change the requirements table to use distance().
+</p>
+<p>
+LWG found Option C acceptable.
</p>
+<p>
+Martin will draft the wording for Option C.
+</p>
+</blockquote>
<p><i>[
-Sophia Antipolis:
+post San Francisco:
]</i></p>
<blockquote>
-According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect
-forwarding can not be obtained because of type erasure. Not everyone
-agreed with this diagnosis of forwarding.
+Martin provided wording for Option C.
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
+Common part:
</p>
-
-
-
-
-
-<hr>
-<h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3>
-<p><b>Section:</b> 20.6.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-02-08</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<ul>
+<li>
<p>
-Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt>
-should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
+Just betwen 23.3.3.5 [forwardlist.ops] and 23.3.3.6 [forwardlist.spec]
+add a new
+section "forwardlist comparison operators" [forwardlist.compare] (and
+also add the
+new section number to 23.3.3 [forwardlist]/2 in front of "Comparison operators"):
</p>
-<p>
-However, no guarantees are provided for the copy ctor of the functor
-returned by <tt>bind()</tt>. (It's guaranteed to have a copy ctor, which can
-throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
-call wrapper, TR1 3.6.3/2. A forwarding call wrapper is a call wrapper,
-TR1 3.3/4. Every call wrapper shall be CopyConstructible, TR1 3.3/4.
-Everything without an exception-specification may throw
-implementation-defined exceptions unless otherwise specified, C++03
-17.4.4.8/3.)
+<blockquote>
+forwardlist comparison operators [forwardlist.compare]
+</blockquote>
+</li>
+</ul>
+
+<p>
+Option (A):
</p>
+<blockquote>
+<ul>
+<li>
<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?
+Add to the new section [forwardlist.compare] the following paragraphs:
</p>
-<p><i>[
-Howard adds:
-]</i></p>
-
-
<blockquote>
-<tt>tuple</tt> construction should probably have a similar guarantee.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
+<pre>template <class T, class Allocator>
+bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+</pre>
+<blockquote>
<p>
+<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
</p>
-
-
-
-
-
-<hr>
-<h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
-<p><b>Section:</b> 20.6.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-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>.
+<i>Returns:</i> <tt>true</tt> if
</p>
+<ul>
+<li>
<p>
-This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>.
+for every iterator <tt>i</tt> in the range <tt>[x.begin(), E)</tt>, where <tt>E ==
+x.begin() + M</tt> and <tt>M ==
+ min(distance(x.begin(), x.end()), distance(y.begin(), y.end()))</tt>,
+the following condition holds:
</p>
-
-
-<p><b>Proposed resolution:</b></p>
+<blockquote><pre>*i == *(y.begin() + (i - x.begin())).
+</pre></blockquote>
+</li>
+<li>
+if <tt>i == E</tt> then <tt>i == x.end() && (y.begin() + (i - x.begin())) == y.end()</tt>.
+</li>
+<li>
+Otherwise, returns <tt>false</tt>.
+</li>
+</ul>
<p>
+<i>Throws:</i> Nothing unless an exception is thrown by the equality comparison.
</p>
-
-
-
-
-
-<hr>
-<h3><a name="818"></a>818. wording for memory ordering</h3>
-<p><b>Section:</b> 29.1 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-22</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-29.1 [atomics.order] p1 says in the table that
+<i>Complexity:</i> At most <tt>M</tt> comparisons.
</p>
-
+</blockquote>
+<pre>template <class T, class Allocator>
+bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+</pre>
<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>
+<i>Returns:</i> <tt>!(x == y)</tt>.
+</blockquote>
+</blockquote>
+</li>
+</ul>
</blockquote>
<p>
-To my naked eye, that seems to imply that even an atomic read has both
-acquire and release semantics.
+Option (B):
</p>
-
+<blockquote>
+<ul>
+<li>
<p>
-Then, p1 says in the table:
+Add to the new section [forwardlist.compare] the following paragraphs:
</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>
-
+<pre>template <class T, class Allocator>
+bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+</pre>
+<blockquote>
<p>
-So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
-constraints.
+<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
</p>
-
<p>
-I'm then reading p2, where it says:
+<i>Returns:</i> <tt>distance(x.begin(), x.end()) == distance(y.begin(), y.end())
+&& equal(x.begin(), x.end(), y.begin())</tt>.
</p>
-
+</blockquote>
+<pre>template <class T, class Allocator>
+bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+</pre>
<blockquote>
-The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
-on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
-are release operations on the affected locations.
+<i>Returns:</i> <tt>!(x == y)</tt>.
+</blockquote>
</blockquote>
+</li>
-<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>
+</ul>
+</blockquote>
<p>
-Also, the table in p1 contains phrases with "thus" that seem to indicate
-consequences of normative wording in 1.10 [intro.multithread]. That shouldn't be in
-normative text, for the fear of redundant or inconsistent specification with
-the other normative text.
+Option (C):
</p>
-
+<blockquote>
+<ul>
+<li>
<p>
-Double-check 29.4 [atomics.types.operations] that each
-operation clearly says whether it's a load or a store operation, or
-both. (It could be clearer, IMO. Solution not in current proposed resolution.)
+Change Table 91 - Container Requirements in 23.2.1 [container.requirements.general]
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>) like so:
</p>
+<ol>
+<li>
<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.
+Change the text in the <b>Operational Semantics</b> column in
+ the row for <tt>a == b</tt> as follows:
</p>
+<blockquote>
+<tt>==</tt> is an equivalence relation.
+ <tt><ins>distance(a.begin(), a.end())</ins>
+ <del>a.size()</del> ==
+ <ins>distance(b.begin(), b.end())</ins> <del>b.size()</del> &&
+ equal(a.begin(), a.end(), b.begin())</tt>
+</blockquote>
+</li>
+<li>
<p>
-And why does 29.4 [atomics.types.operations] p9 for "load" say:
+Change the text in the <b>Operational Semantics</b> column in
+ the row for <tt>a.max_size()</tt> as follows:
</p>
-
-
<blockquote>
-<i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt>
-nor <tt>memory_order_acq_rel</tt>.
+<tt><ins>distance(a.begin(), a.end())</ins>
+ <del>a.size()</del></tt> of the largest possible container
</blockquote>
+</li>
+<li>
<p>
-(Since this is exactly the same restriction as for "store", it seems to be a typo.)
+Change the text in the <b>Operational Semantics</b> column in
+ the row for <tt>a.empty()</tt> as follows:
</p>
+<blockquote>
+<tt><ins>a.begin() == a.end()</ins>
+ <del>a.size() == 0</del></tt>
+</blockquote>
+</li>
+<li>
<p>
-And then: 29.4 [atomics.types.operations] p12:
+In addition, for consistency, change the text in the
+ <b>Operational Semantics</b> column in the row for <tt>a.size()</tt>
+ as follows:
</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.
+<tt><ins>distance(a.begin(), a.end())</ins>
+ <del>a.end() - a.begin()</del></tt>
+</blockquote>
+</li>
+</ol>
+</li>
+</ul>
</blockquote>
-<p>
-This is redundant with 1.10 [intro.multithread], see above for the reasoning.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of
-1.7 [intro.memory].
-Rephrase the table in as follows (maybe don't use a table):
-</p>
-<blockquote>
-<p>
-For <tt>memory_order_relaxed</tt>, no operation orders memory.
-</p>
+<hr>
+<h3><a name="862"></a>862. Impossible complexity for 'includes'</h3>
+<p><b>Section:</b> 25.5.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-07-02 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#includes">active issues</a> in [includes].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#includes">issues</a> in [includes].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-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.
+In 25.5.5.1 [includes] the complexity is "at most -1 comparisons" if passed
+two empty ranges. I don't know how to perform a negative number of
+comparisions!
</p>
<p>
-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.
+This same issue also applies to:
</p>
-</blockquote>
-<p>
-Rephrase 29.1 [atomics.order] p2:
-</p>
+<ul>
+<li><tt>set_union</tt></li>
+<li><tt>set_intersection</tt></li>
+<li><tt>set_difference</tt></li>
+<li><tt>set_symmetric_difference</tt></li>
+<li><tt>merge</tt></li>
+</ul>
-<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><i>[
+2009-03-30 Beman adds:
+]</i></p>
-<p>
-Rephrase 29.4 [atomics.types.operations] p12 as:
-</p>
<blockquote>
-<i>Effects:</i> Atomically replaces the value pointed to by object or by
-this with desired. Memory is affected according to the value of order.
-These operations are read-modify-write operations <del>in the sense of the
-"synchronizes with" definition</del> (1.10 [intro.multithread])<del>, so both such an operation and the
-evaluation that produced the input value synchronize with any evaluation
-that reads the updated value</del>.
+Suggest NAD. The complexity of empty ranges is -1 in other places in the
+standard. See 25.5.4 [alg.merge] <tt>merge</tt> and
+<tt>inplace_merge</tt>, and <tt>forward_list</tt> merge, for example.
+The time and effort to find and fix all places in the standard where
+empty range[s] result in negative complexity isn't worth the very
+limited benefit.
</blockquote>
-<p>
-Same in p15, p20, p22.
-</p>
-
-
-
-
+<p><i>[
+2009-05-09 Alisdair adds:
+]</i></p>
-<hr>
-<h3><a name="819"></a>819. rethrow_if_nested</h3>
-<p><b>Section:</b> 18.7.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-25</p>
-<p><b>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>
-Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
-got it quite right.
+I'm not happy with NAD if we can find a simple solution.
</p>
-
<p>
-The current wording says:
+How about adding a rider somewhere in clause 17 suggesting that complexities
+that specify a negative number of operations are treated as specifying zero
+operations? That should generically solve the issue without looking for
+further cases.
</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
<blockquote>
-<pre>template <class E> void rethrow_if_nested(const E& 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>
+Pete to provide "straightforward" wording.
+Move to NAD Editorial.
</blockquote>
-<p>
-This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
-derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
-required to be sure. Unfortunately, if <tt>e</tt> is dynamically but not statically
-derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
-</p>
-
<p><b>Proposed resolution:</b></p>
+<p>
+Recommend NAD.
+</p>
<hr>
-<h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
-<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-03-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
-<p><b>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="863"></a>863. What is the state of a stream after close() succeeds</h3>
+<p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2008-07-08 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-As of N2521, the Working Paper appears to be silent about what
-<tt>current_exception()</tt> should do if it tries to copy the currently handled
-exception and its copy constructor throws. 18.7.5 [propagation]/7 says "If the
-function needs to allocate memory and the attempt fails, it returns an
-<tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
-doesn't say anything about what should happen if memory allocation
-succeeds but the actual copying fails.
+Suppose writing to an <tt>[o]fstream</tt> fails and you later close the <tt>stream</tt>.
+The <tt>overflow()</tt> function is called to flush the buffer (if it exists).
+Then the file is unconditionally closed, as if by calling <tt>flcose</tt>.
</p>
-
<p>
-I 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>.
+If either <tt>overflow</tt> or <tt>fclose</tt> fails, <tt>close()</tt> reports failure, and clearly
+the <tt>stream</tt> should be in a failed or bad state.
</p>
-
<p>
-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.
+Suppose the buffer is empty or non-existent (so that <tt>overflow()</tt> does not
+fail), and <tt>fclose</tt> succeeds. The <tt>close()</tt> function reports success, but
+what is the state of the <tt>stream</tt>?
</p>
<p><i>[
-Peter's summary:
+Batavia (2009-05):
]</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.
+Tom's impression is that the issue is about the <tt>failbit</tt>, etc.
</p>
-
<p>
-However, the resolution of core issue 475 may relax this requirement:
+Bill responds that the stream is now closed,
+and any status bits remain unchanged.
</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>
-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.
+See the description of <tt>close()</tt> in 27.9.1.17 [fstream.members].
</p>
-
<p>
-Option (2) cannot be adopted by itself, because a potential infinite
-recursion will need to be terminated by one of the other options.
+We prefer not to add wording to say that nothing changes.
+Move to NAD.
</p>
-
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-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="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
-<p><b>Section:</b> 20.7.11.3.3 [unique.ptr.runtime.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<h3><a name="865"></a>865. More algorithms that throw away information</h3>
+<p><b>Section:</b> 25.4.6 [alg.fill], 25.4.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-07-13 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> I noticed the following:
+In regard to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a> I found some more algorithms which
+unnecessarily throw away information. These are typically algorithms,
+which sequentially write into an <tt>OutputIterator</tt>, but do not return the
+final value of this output iterator. These cases are:
</p>
-<blockquote>
-<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-</pre>
+<ol>
+<li>
+<pre>template<class OutputIterator, class Size, class T>
+void fill_n(OutputIterator first, Size n, const T& value);</pre></li>
+<li>
+<pre>template<class OutputIterator, class Size, class Generator>
+void generate_n(OutputIterator first, Size n, Generator gen);</pre></li>
+</ol>
<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>]
+In both cases the minimum requirements on the iterator are
+<tt>OutputIterator</tt>, which means according to the requirements of
+24.2.3 [output.iterators]/2 that only single-pass iterations are guaranteed.
+So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt>
+available, they have no chance to continue pushing further values
+into it, which seems to be a severe limitation to me.
</p>
-</blockquote>
+<p><i>[
+Post Summit Daniel "conceptualized" the wording.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Alisdair likes the idea, but has concerns about the specific wording
+about the returns clauses.
+</p>
+<p>
+Alan notes this is a feature request.
+</p>
+<p>
+Bill notes we have made similar changes to other algorithms.
+</p>
<p>
-This could be cleaned up by mandating the overload as a public deleted
-function. In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt>
-to be a stronger match than the deleted overload. Words...
+Move to Open.
</p>
+</blockquote>
<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
<p>
-Add to class template definition in 20.7.11.3 [unique.ptr.runtime]
+Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header
+<tt><algorithm></tt> synopsis and in 25.4.6 [alg.fill] by
</p>
-<blockquote>
-<pre>// modifiers
-T* release();
-void reset(T* p = 0);
-<ins>void reset( nullptr_t );</ins>
-<ins>template< typename T > void reset( T ) = delete;</ins>
-void swap(unique_ptr&& u);
-</pre>
-</blockquote>
+<blockquote><pre>template<class Iter, IntegralLike Size, class T>
+ requires OutputIterator<Iter, const T&>
+ <del>void</del><ins>Iter</ins> fill_n(Iter first, Size n, const T& value);
+</pre></blockquote>
<p>
-Update 20.7.11.3.3 [unique.ptr.runtime.modifiers]
+Just after the effects clause p.1 add a new returns clause saying:
</p>
-
<blockquote>
-<pre>void reset(pointer p = pointer());
-<ins>void reset(nullptr_t);</ins>
-</pre>
-
+<i>Returns:</i> For <tt>fill_n</tt> and <tt>n > Size(0)</tt>, returns <tt>first + n</tt>. Otherwise
+returns <tt>first</tt> for <tt>fill_n</tt>.
+</blockquote>
+</li>
+<li>
<p>
-<del>-1- <i>Requires:</i> Does not accept pointer types which are convertible
-to <tt>pointer</tt> (diagnostic
-required). [<i>Note:</i> One implementation technique is to create a private
-templated overload. <i>-- end note</i>]</del>
+Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2, header
+<tt><algorithm></tt> synopsis and in 25.4.7 [alg.generate] by
</p>
+<blockquote><pre>template<class Iter, IntegralLike Size, Callable Generator>
+ requires OutputIterator<Iter, Generator::result_type>
+ && CopyConstructible<Generator>
+ <del>void</del><ins>Iter</ins> generate_n(Iter first, Size n, Generator gen);
+</pre></blockquote>
<p>
-<i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+Just after the effects clause p.1 add a new returns clause saying:
</p>
-<p>...</p>
+<blockquote>
+<i>Returns:</i> For <tt>generate_n</tt> and <tt>n > Size(0)</tt>, returns <tt>first + n</tt>.
+Otherwise returns <tt>first</tt> for <tt>generate_n</tt>.
</blockquote>
-
-<p><i>[
-Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (Ready).
-]</i></p>
-
+</li>
+</ol>
<hr>
-<h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
-<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> James Kanze <b>Date:</b> 2008-04-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="867"></a>867. Valarray and value-initialization</h3>
+<p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-20 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#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#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-I just noticed that the following program is legal in C++03, but
-is forbidden in the current draft:
+From 26.6.2.1 [valarray.cons], paragraph 2:
</p>
-<blockquote><pre>#include <vector>
-#include <iostream>
+<blockquote><pre>explicit valarray(size_t);
+</pre>
+<blockquote>
+The array created by this constructor has a length equal to the value of the argument. The elements
+of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
+</blockquote>
+</blockquote>
-class Toto
-{
-public:
- Toto() {}
- explicit Toto( Toto const& ) {}
-} ;
+<p>
+The problem is that the most obvious <tt>T</tt>s for <tt>valarray</tt> are <tt>float</tt>
+and <tt>double</tt>, they don't have a default constructor. I guess the intent is to value-initialize
+the elements, so I suggest replacing:
+</p>
-int
-main()
-{
- std::vector< Toto > v( 10 ) ;
- return 0 ;
-}
-</pre></blockquote>
+<blockquote>
+The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
+</blockquote>
+<p>
+with
+</p>
+<blockquote>
+The elements of the array are value-initialized.
+</blockquote>
<p>
-Is this change intentional? (And if so, what is the
-justification? I wouldn't call such code good, but I don't see
-any reason to break it unless we get something else in return.)
+There is another reference to the default constructor of <tt>T</tt> in the non-normative note in paragraph 9.
+That reference should also be replaced. (The normative wording in paragraph 8 refers to <tt>T()</tt>
+and so it doesn't need changes).
</p>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to NAD Editorial.
+</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-In 20.1.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
+Change 26.6.2.1 [valarray.cons], paragraph 2:
</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>
+<pre>explicit valarray(size_t);
+</pre>
+<blockquote>
+The array created by this constructor has a length equal to the value of the argument. The elements
+of the array are <del>constructed using the default constructor for the instantiating type <tt>T</tt></del>
+<ins>value-initialized (8.5 [dcl.init])</ins>.
+</blockquote>
</blockquote>
<p>
-In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
+Change 26.6.2.7 [valarray.members], paragraph 9:
</p>
<blockquote>
-<table border="1">
-<tbody><tr>
-<th>expression</th><th>post-condition</th>
-</tr>
-<tr>
-<td><tt>T t<ins>(u)</ins><del> = u</del></tt></td><td>the value of <tt>u</tt> is unchanged and is equivalent to <tt>t</tt></td>
-</tr>
-<tr>
-<td colspan="2" align="center">...</td>
-</tr>
-</tbody></table>
+[<i>Example:</i> If the argument has the value -2, the first two elements of the result will be <del>constructed using the
+default constructor</del>
+<ins>value-initialized (8.5 [dcl.init])</ins>;
+the third element of the result will be assigned the value of the first element of the argument; etc. <i>-- end example</i>]
</blockquote>
+
<hr>
-<h3><a name="823"></a>823. <tt>identity<void></tt> seems broken</h3>
-<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2008-04-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="868"></a>868. default construction and value-initialization</h3>
+<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-22 <b>Last modified:</b> 2008-09-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-N2588 seems to have added an <tt>operator()</tt> member function to the
-<tt>identity<></tt> helper in 20.2.2 [forward]. I believe this change makes it no
-longer possible to instantiate <tt>identity<void></tt>, as it would require
-forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
-</p>
-
-<p>
-Suggested resolution: Specialize <tt>identity<void></tt> so as not to require
-the member function's presence.
+The term "default constructed" is often used in wording that predates
+the introduction of the concept of value-initialization. In a few such
+places the concept of value-initialization is more correct than the
+current wording (for example when the type involved can be a built-in)
+so a replacement is in order. Two of such places are already covered by
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>. This issue deliberately addresses the hopefully
+non-controversial changes in the attempt of being approved more quickly.
+A few other occurrences (for example in <tt>std::tuple</tt>,
+<tt>std::reverse_iterator</tt> and <tt>std::move_iterator</tt>) are left to separate
+issues. For <tt>std::reverse_iterator</tt>, see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>. This issue is
+related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>.
</p>
<p><i>[
-Sophia Antipolis:
+San Francisco:
]</i></p>
<blockquote>
<p>
-Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>.
-</p>
-<p>
-Alisdair: also consider cv-qualified <tt>void</tt>.
+The list provided in the proposed resolution is not complete. James
+Dennett will review the library and provide a complete list and will
+double-check the vocabulary.
</p>
<p>
-Alberto provided proposed wording.
+This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a> tuple construction
</p>
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Change definition of <tt>identity</tt> in 20.2.2 [forward], paragraph 2, to:
+Change X [utility.arg.requirements], paragraph 2:
</p>
-<blockquote><pre>template <class T> struct identity {
- typedef T type;
-
- <ins>requires ReferentType<T></ins>
- const T& operator()(const T& x) const;
- };
-</pre></blockquote>
-<p>...</p>
-<blockquote><pre> <ins>requires ReferentType<T></ins>
- const T& operator()(const T& x) const;
-</pre></blockquote>
-
+<blockquote>
+In general, a default constructor is not required. Certain container class member function signatures specify
+<del>the default constructor</del>
+<ins><tt>T()</tt></ins>
+as a default argument. <tt>T()</tt> shall be a well-defined expression (8.5 [dcl.init]) if one of
+those signatures is called using the default argument (8.3.6 [dcl.fct.default]).
+</blockquote>
-<p><b>Rationale:</b></p>
<p>
-The point here is to able to write <tt>T&</tt> given <tt>T</tt> and <tt>ReferentType</tt> is
-precisely the concept that guarantees so, according to N2677
-(Foundational concepts). Because of this, it seems preferable than an
-explicit check for <tt>cv void</tt> using <tt>SameType/remove_cv</tt> as it was suggested
-in Sophia. In particular, Daniel remarked that there may be types other
-than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?).
+In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized
+(8.5 [dcl.init])":
</p>
+<ul>
+<li>23.3.2.1 [deque.cons] para 2</li>
+<li>23.3.2.2 [deque.capacity] para 1</li>
+<li>23.3.3.1 [forwardlist.cons] para 3</li>
+<li>23.3.3.4 [forwardlist.modifiers] para 21</li>
+<li>23.3.4.1 [list.cons] para 3</li>
+<li>23.3.4.2 [list.capacity] para 1</li>
+<li>23.3.6.1 [vector.cons] para 3</li>
+<li>23.3.6.2 [vector.capacity] para 10</li>
+</ul>
+
<hr>
-<h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
-<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="869"></a>869. Bucket (local) iterators and iterating past end</h3>
+<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Sohail Somani <b>Opened:</b> 2008-07-22 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In the current working paper, the <tt><string></tt> header synopsis at the end of
-21.2 [string.classes] lists a single <tt>operator<<</tt> overload
-for <tt>basic_string</tt>.
-</p>
-
-<blockquote><pre>template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
- operator<<(basic_ostream<charT, traits>&& os,
- const basic_string<charT,traits,Allocator>& str);
-</pre></blockquote>
-
-<p>
-The definition in 21.3.8.9 [string.io] lists two:
+Is there any language in the current draft specifying the behaviour of the following snippet?
</p>
-<blockquote><pre>template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
- operator<<(basic_ostream<charT, traits>& os,
- const basic_string<charT,traits,Allocator>& str);
+<blockquote><pre>unordered_set<int> s;
+unordered_set<int>::local_iterator it = s.end(0);
-template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
- operator<<(basic_ostream<charT, traits>&& os,
- const basic_string<charT,traits,Allocator>& str);
+// Iterate past end - the unspecified part
+it++;
</pre></blockquote>
<p>
-I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two
-signatures in 21.3.8.9 [string.io] should be deleted.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Delete the first of the two signatures in 21.3.8.9 [string.io]:
+I don't think there is anything about <tt>s.end(n)</tt> being considered an
+iterator for the past-the-end value though (I think) it should be.
</p>
-<blockquote><pre><del>template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
- operator<<(basic_ostream<charT, traits>& os,
- const basic_string<charT,traits,Allocator>& str);</del>
-
-template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
- operator<<(basic_ostream<charT, traits>&& os,
- const basic_string<charT,traits,Allocator>& str);
-</pre></blockquote>
-
-
-
-
+<p><i>[
+San Francisco:
+]</i></p>
-<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.7.12.2.8
-[util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3
-[bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9
-[re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Should the following use rvalues references to stream in insert/extract
-operators?
-</p>
-<ul>
-<li>19.4.2.1 [syserr.errcode.overview]</li>
-<li>20.7.12.2.8 [util.smartptr.shared.io]</li>
-<li>22.2.8 [facets.examples]</li>
-<li>23.3.5.3 [bitset.operators]</li>
-<li>26.3.6 [complex.ops]</li>
-<li>Doubled signatures in 27.5 [stream.buffers] for character inserters
-(ref 27.6.2.6.4 [ostream.inserters.character])
-+ definition 27.6.2.6.4 [ostream.inserters.character]</li>
-<li>28.9 [re.submatch]</li>
-</ul>
+<blockquote>
+We believe that this is not a substantive change, but the proposed
+change to the wording is clearer than what we have now.
+</blockquote>
<p><i>[
-Sophia Antipolis
+Post Summit:
]</i></p>
<blockquote>
-Agree with the idea in the issue, Alisdair to provide wording.
+Recommend Tentatively Ready.
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
+Change Table 97 "Unordered associative container requirements" in 23.2.5 [unord.req]:
</p>
+<blockquote>
+<table border="1">
+<caption>Table 97: Unordered associative container requirements</caption>
+<tbody><tr>
+<th>expression</th><th>return type</th><th>assertion/note pre/post-condition</th><th>complexity</th>
+</tr>
+<tr>
+<td><tt>b.begin(n)</tt></td>
+<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
+<td>Pre: n shall be in the range [0,b.bucket_count()). <del>Note: [b.begin(n), b.end(n)) is a
+valid range containing all of the elements in the n<sup>th</sup> bucket.</del>
+<ins><tt>b.begin(n)</tt> returns an iterator referring to the first element in the bucket.
+If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td>
+<td>Constant</td>
+</tr>
+<tr>
+<td><tt>b.end(n)</tt></td>
+<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
+<td>Pre: n shall be in the range <tt>[0, b.bucket_count())</tt>.
+<ins><tt>b.end(n)</tt> returns an iterator which is the past-the-end value for the bucket.</ins></td>
+<td>Constant</td>
+</tr>
+</tbody></table>
+</blockquote>
-<hr>
-<h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
-<p><b>Section:</b> 20.7.12.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-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>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
<hr>
-<h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
-<p><b>Section:</b> 30.3.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="873"></a>873. signed integral type and unsigned integral type are not clearly defined</h3>
+<p><b>Section:</b> 3.9.1 [basic.fundamental] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Travis Vitek <b>Opened:</b> 2008-06-30 <b>Last modified:</b> 2009-03-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>
-[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>
+ Neither the term "signed integral type" nor the term "unsigned
+ integral type" is defined in the core language section of the
+ standard, therefore the library section should avoid its use. The
+ terms <i>signed integer type</i> and <i>unsigned integer type</i> are
+ indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be
+ replaced accordingly.
+ </p>
+
+ <p>
+ Note that the key issue here is that "signed" + "integral type" !=
+ "signed integral type".
+
+ The types <code>bool</code>, <code>char</code>, <code>char16_t</code>,
+ <code>char32_t</code> and <code>wchar_t</code> are all listed as
+ integral types, but are neither of <i>signed integer type</i> or
+ <i>unsigned integer type</i>. According to 3.9 [basic.types] p7, a synonym for
+ integral type is <i>integer type</i>.
+
+ Given this, one may choose to assume that an <i>integral type</i> that
+ can represent values less than zero is a <i>signed integral type</i>.
+ Unfortunately this can cause ambiguities.
+
+ As an example, if <code>T</code> is <code>unsigned char</code>, the
+ expression <code>make_signed<T>::type</code>, is supposed to
+ name a signed integral type. There are potentially two types that
+ satisfy this requirement, namely <code>signed char</code> and
+ <code>char</code> (assuming <code>CHAR_MIN < 0</code>).
+ </p>
<p><i>[
-Sophia Antipolis:
+San Francisco:
]</i></p>
<blockquote>
-<p>
-We believe this is implementable on POSIX, because the initializer-list
-feature and the constexpr feature make this work. Double-check core
-language about static initialization for this case. Ask core for a core
-issue about order of destruction of statically-initialized objects wrt.
-dynamically-initialized objects (should come afterwards). Check
-non-POSIX systems for implementability.
-</p>
-<p>
-If ubiquitous implementability cannot be assured, plan B is to introduce
-another constructor, make this constexpr, which is
-conditionally-supported. To avod ambiguities, this new constructor needs
-to have an additional parameter.
-</p>
+Plum, Sebor to review.
</blockquote>
+<p><i>[
+Post Summit Daniel adds:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 30.3.1.1 [thread.mutex.class]:
-</p>
-
-<blockquote><pre>class mutex {
-public:
- <ins>constexpr</ins> mutex();
- ...
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="829"></a>829. current_exception wording unclear about exception type</h3>
-<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-04-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Consider this code:</p>
<blockquote>
-<pre>exception_ptr xp;</pre>
-<pre>try {do_something(); }
-
-catch (const runtime_error& ) {xp = current_exception();}
-
-...
-
-rethrow_exception(xp);</pre>
+The proposed resolution needs to be "conceptualized". Currently we have
+in 14.10.4 [concept.support] only concept <tt>IntegralType</tt>
+for all "integral types", thus indeed the current <tt>Container</tt>
+concept and Iterator concepts are sufficiently satisfied with "integral
+types". If the changes are applied, we might ask core for concept
+<tt>BilateralIntegerType</tt> and add proper restrictions to the library
+concepts.
</blockquote>
-<p>
-Say <code>do_something()</code> throws an exception object of type <code>
-range_error</code>. What is the type of the exception object thrown by <code>
-rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>;
-if it were of type <code>runtime_error</code> it still isn't possible to
-propagate an exception and the exception_ptr/current_exception/rethrow_exception
-machinery serves no useful purpose.
-</p>
+
-<p>
-Unfortunately, the current wording does not explicitly say that. Different
-people read the current wording and come to different conclusions. While it may
-be possible to deduce the correct type from the current wording, it would be
-much clearer to come right out and explicitly say what the type of the referred
-to exception is.
-</p>
+ <p><b>Proposed resolution:</b></p>
+ <p>
+ I propose to use the terms "signed integer type" and "unsigned integer
+ type" in place of "signed integral type" and "unsigned integral type"
+ to eliminate such ambiguities.
+ </p>
+
+ <p>
+ The proposed change makes it absolutely clear that the difference
+ between two pointers cannot be <tt>char</tt> or <tt>wchar_t</tt>,
+ but could be any of the signed integer types.
+ 5.7 [expr.add] paragraph 6...
+ </p>
+ <blockquote>
+ <p>
+ </p><ol>
+ <li>
+ When two pointers to elements of the same array object are
+ subtracted, the result is the difference of the subscripts of
+ the two array elements. The type of the result is an
+ implementation-defined <del>signed integral
+ type</del><ins>signed integer type</ins>; this type shall be the
+ same type that is defined as <code>std::ptrdiff_t</code> in the
+ <code><cstdint></code> header (18.1)...
+ </li>
+ </ol>
+
+ </blockquote>
-<p><i>[
-Peter adds:
-]</i></p>
+ <p>
+ The proposed change makes it clear that <tt>X::size_type</tt> and
+ <tt>X::difference_type</tt> cannot be <tt>char</tt> or
+ <tt>wchar_t</tt>, but could be one of the signed or unsigned integer
+ types as appropriate.
+ X [allocator.requirements] table 40...
+ </p>
+ <blockquote>
+ Table 40: Allocator requirements
+ <table border="1">
+ <thead>
+ <tr>
+ <th>expression</th>
+ <th>return type</th>
+ <th>assertion/note/pre/post-condition</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><tt>X::size_type</tt></td>
+ <td>
+ <del>unsigned integral type</del>
+ <ins>unsigned integer type</ins>
+ </td>
+ <td>a type that can represent the size of the largest object in
+ the allocation model.</td>
+ </tr>
+ <tr>
+ <td><tt>X::difference_type</tt></td>
+ <td>
+ <del>signed integral type</del>
+ <ins>signed integer type</ins>
+ </td>
+ <td>a type that can represent the difference between any two
+ pointers in the allocation model.</td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
+ <p>
+ The proposed change makes it clear that <tt>make_signed<T>::type</tt>
+ must be one of the signed integer types as defined in 3.9.1. Ditto for
+ <tt>make_unsigned<T>type</tt> and unsigned integer types.
+ 20.6.6.3 [meta.trans.sign] table 48...
+ </p>
+ <blockquote>
+ Table 48: Sign modifications
+ <table border="1">
+ <thead>
+ <tr>
+ <th>Template</th>
+ <th>Comments</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>
+ <tt>template <class T> struct make_signed;</tt>
+ </td>
+ <td>
+ If <code>T</code> names a (possibly cv-qualified) <del>signed
+ integral type</del><ins>signed integer type</ins> (3.9.1) then
+ the member typedef <code>type</code> shall name the type
+ <code>T</code>; otherwise, if <code>T</code> names a (possibly
+ cv-qualified) <del>unsigned integral type</del><ins>unsigned
+ integer type</ins> then <code>type</code> shall name the
+ corresponding <del>signed integral type</del><ins>signed
+ integer type</ins>, with the same cv-qualifiers as
+ <code>T</code>; otherwise, <code>type</code> shall name the
+ <del>signed integral type</del><ins>signed integer type</ins>
+ with the smallest rank (4.13) for which <code>sizeof(T) ==
+ sizeof(type)</code>, with the same cv-qualifiers as
+ <code>T</code>.
-<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>
+ <i>Requires:</i> <code>T</code> shall be a (possibly
+ cv-qualified) integral type or enumeration but not a
+ <code>bool</code> type.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <tt>template <class T> struct make_unsigned;</tt>
+ </td>
+ <td>
+ If <code>T</code> names a (possibly cv-qualified)
+ <del>unsigned integral type</del><ins>unsigned integer
+ type</ins> (3.9.1) then the member typedef <code>type</code>
+ shall name the type <code>T</code>; otherwise, if
+ <code>T</code> names a (possibly cv-qualified) <del>signed
+ integral type</del><ins>signed integer type</ins> then
+ <code>type</code> shall name the corresponding <del>unsigned
+ integral type</del><ins>unsigned integer type</ins>, with the
+ same cv-qualifiers as <code>T</code>; otherwise,
+ <code>type</code> shall name the <del>unsigned integral
+ type</del><ins>unsigned integer type</ins> with the smallest
+ rank (4.13) for which <code>sizeof(T) == sizeof(type)</code>,
+ with the same cv-qualifiers as <code>T</code>.
+ <i>Requires:</i> <code>T</code> shall be a (possibly
+ cv-qualified) integral type or enumeration but not a
+ <code>bool</code> type.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
-<p><b>Proposed resolution:</b></p>
+ <p>
+ Note: I believe that the basefield values should probably be
+ prefixed with <tt>ios_base::</tt> as they are in 22.4.2.2.2 [facet.num.put.virtuals]
-<p>
-After 18.7.5 [propagation] , paragraph 7, add the indicated text:
-</p>
+ The listed virtuals are all overloaded on signed and unsigned integer
+ types, the new wording just maintains consistency.
-<blockquote>
-<pre>exception_ptr current_exception();</pre>
-
-<blockquote>
-<p>
-<i>Returns:</i> <code>exception_ptr</code> object that refers
-to the currently handled exception <ins>(15.3 [except.handle])</ins> or a copy of the currently handled
-exception, or a null <code>exception_ptr</code> object if no exception is being handled. If
-the function needs to allocate memory and the attempt fails, it returns an
-<code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>.
-It is unspecified whether the return values of two successive calls to
-<code>current_exception</code> refer to the same exception object.
-[<i>Note:</i> that is, it
-is unspecified whether <code>current_exception</code>
-creates a new copy each time it is called.
-<i>-- end note</i>]
-</p>
+ 22.4.2.1.2 [facet.num.get.virtuals] table 78...
+ </p>
+ <blockquote>
+ Table 78: Integer Conversions
+ <table border="1">
+ <thead>
+ <tr>
+ <th>State</th>
+ <th><tt>stdio</tt> equivalent</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><tt>basefield == oct</tt></td>
+ <td><tt>%o</tt></td>
+ </tr>
+ <tr>
+ <td><tt>basefield == hex</tt></td>
+ <td><tt>%X</tt></td>
+ </tr>
+ <tr>
+ <td><tt>basefield == 0</tt></td>
+ <td><tt>%i</tt></td>
+ </tr>
+ <tr>
+ <td><del>signed integral type</del><ins>signed integer
+ type</ins></td>
+ <td><tt>%d</tt></td>
+ </tr>
+ <tr>
+ <td><del>unsigned integral type</del><ins>unsigned integer
+ type</ins></td>
+ <td><tt>%u</tt></td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
-<p>
-<i>Throws:</i> nothing.
-</p>
+
+
+ <p>
+ Rationale is same as above.
+ 22.4.2.2.2 [facet.num.put.virtuals] table 80...
+ </p>
+ <blockquote>
+ Table 80: Integer Conversions
+ <table border="1">
+ <thead>
+ <tr>
+ <th>State</th>
+ <th><tt>stdio</tt> equivalent</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><tt>basefield == ios_base::oct</tt></td>
+ <td><tt>%o</tt></td>
+ </tr>
+ <tr>
+ <td><tt>(basefield == ios_base::hex) &&
+ !uppercase</tt></td>
+ <td><tt>%x</tt></td>
+ </tr>
+ <tr>
+ <td><tt>(basefield == ios_base::hex)</tt></td>
+ <td><tt>%X</tt></td>
+ </tr>
+ <tr>
+ <td><tt>basefield == 0</tt></td>
+ <td><tt>%i</tt></td>
+ </tr>
+ <tr>
+ <td>for a <del>signed integral type</del><ins>signed integer
+ type</ins></td>
+ <td><tt>%d</tt></td>
+ </tr>
+ <tr>
+ <td>for a <del>unsigned integral type</del><ins>unsigned integer
+ type</ins></td>
+ <td><tt>%u</tt></td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
-</blockquote>
-</blockquote>
+
+ <p>
+ 23.2 [container.requirements] table 80...
+ </p>
+ <blockquote>
+ Table 89: Container requirements
+ <table border="1">
+ <thead>
+ <tr>
+ <th>expression</th>
+ <th>return type</th>
+ <th>operational semantics</th>
+ <th>assertion/note/pre/post-condition</th>
+ <th>complexity</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><tt>X::difference_type</tt></td>
+ <td><del>signed integral type</del><ins>signed integer type</ins></td>
+ <td> </td>
+ <td>is identical to the difference type of <tt>X::iterator</tt>
+ and <tt>X::const_iterator</tt></td>
+ <td>compile time</td>
+ </tr>
+ <tr>
+ <td><tt>X::size_type</tt></td>
+ <td><del>unsigned integral type</del><ins>unsigned integer type</ins></td>
+ <td> </td>
+ <td><tt>size_type</tt> can represent any non-negative value of
+ <tt>difference_type</tt></td>
+ <td>compile time</td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
+ <p>
+ 24.2 [iterator.concepts] paragraph 1...
+ </p>
+ <blockquote>
+ Iterators are a generalization of pointers that allow a C++ program to
+ work with different data structures (containers) in a uniform manner.
+ To be able to construct template algorithms that work correctly and
+ efficiently on different types of data structures, the library
+ formalizes not just the interfaces but also the semantics and
+ complexity assumptions of iterators. All input iterators
+ <code>i</code> support the expression <code>*i</code>, resulting in a
+ value of some class, enumeration, or built-in type <code>T</code>,
+ called the <i>value type</i> of the iterator. All output iterators
+ support the expression <code>*i = o</code> where <code>o</code> is a
+ value of some type that is in the set of types that are
+ <i>writable</i> to the particular iterator type of <code>i</code>. All
+ iterators <code>i</code> for which the expression <code>(*i).m</code>
+ is well-defined, support the expression <code>i->m</code> with the
+ same semantics as <code>(*i).m</code>. For every iterator type
+ <code>X</code> for which equality is defined, there is a corresponding
+ <del>signed integral type</del> <ins>signed integer type</ins> called
+ the <i>difference type</i> of the iterator.
+ </blockquote>
+
+ <p>
+ I'm a little unsure of this change. Previously this paragraph would
+ allow instantiations of <tt>linear_congruential_engine</tt> on
+ <tt>char</tt>, <tt>wchar_t</tt>, <tt>bool</tt>, and other types. The
+ new wording prohibits this.
+ 26.5.3.1 [rand.eng.lcong] paragraph 2...
+ </p>
+ <blockquote>
+ The template parameter <code>UIntType</code> shall denote an
+ <del>unsigned integral type</del><ins>unsigned integer type</ins>
+ large enough to store values as large as <code>m - 1</code>. If the
+ template parameter <code>m</code> is 0, the modulus <code>m</code>
+ used throughout this section 26.4.3.1 is
+ <code>numeric_limits<result_type>::max()</code> plus 1. [Note:
+ The result need not be representable as a value of type
+ <code>result_type</code>. --end note] Otherwise, the following
+ relations shall hold: <code>a < m</code> and <code>c <
+ m</code>.
+ </blockquote>
+
+ <p>
+ Same rationale as the previous change.
+ X [rand.adapt.xor] paragraph 6...
+ </p>
+ <blockquote>
+ Both <code>Engine1::result_type</code> and
+ <code>Engine2::result_type</code> shall denote (possibly different)
+ <del>unsigned integral types</del><ins>unsigned integer types</ins>.
+ The member <i>result_type</i> shall denote either the type
+ <i>Engine1::result_type</i> or the type <i>Engine2::result_type</i>,
+ whichever provides the most storage according to clause 3.9.1.
+ </blockquote>
+
+ <p>
+ 26.5.7.1 [rand.util.seedseq] paragraph 7...
+ </p>
+ <blockquote>
+ <i>Requires:</i><code>RandomAccessIterator</code> shall meet the
+ requirements of a random access iterator (24.1.5) such that
+ <code>iterator_traits<RandomAccessIterator>::value_type</code>
+ shall denote an <del>unsigned integral type</del><ins>unsigned integer
+ type</ins> capable of accomodating 32-bit quantities.
+ </blockquote>
+ <p>
+ By making this change, integral types that happen to have a signed
+ representation, but are not signed integer types, would no longer be
+ required to use a two's complement representation. This may go against
+ the original intent, and should be reviewed.
+ 29.6 [atomics.types.operations] paragraph 24...
+ </p>
+ <blockquote>
+ <i>Remark:</i> For <del>signed integral types</del><ins>signed integer
+ types</ins>, arithmetic is defined using two's complement
+ representation. There are no undefined results. For address types, the
+ result may be an undefined address, but the operations otherwise have
+ no undefined behavior.
+ </blockquote>
+
+
<hr>
-<h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3>
-<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
+<h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3>
+<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22 <b>Last modified:</b> 2008-09-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>
- Paragraph 4 of 21.1 [char.traits] mentions that this
- section specifies two specializations (<code>char_traits<char></code>
- and (<code>char_traits<wchar_t></code>). However, there are actually
- four specializations provided, i.e. in addition to the two above also
- <code>char_traits<char16_t></code> and <code>char_traits<char32_t></code>).
- I guess this was just an oversight and there is nothing wrong with just
- fixing this.
+During the Sophia Antipolis meeting it was decided to split-off some
+parts of the
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a>
+("Concurrency modifications for <tt>basic_string</tt>")
+proposal into a separate issue, because these weren't actually
+concurrency-related. The here proposed changes refer to the recent
+update document
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a>
+and attempt to take advantage of the
+stricter structural requirements.
</p>
-
-<p><i>[
-Alisdair adds:
-]</i></p>
-
-<blockquote>
-<tt>char_traits< char16/32_t ></tt>
-should also be added to <tt><ios_fwd></tt> in 27.2 [iostream.forward], and all the specializations
-taking a <tt>char_traits</tt> parameter in that header.
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
<p>
-Idea of the issue is ok.
+Indeed there exists some leeway for more guarantees that would be
+very useful for programmers, especially if interaction with transactionary
+or exception-unaware C API code is important. This would also allow
+compilers to take advantage of more performance optimizations, because
+more functions can have throw() specifications. This proposal uses the
+form of "Throws: Nothing" clauses to reach the same effect, because
+there already exists a different issue in progress to clean-up the current
+existing "schizophrenia" of the standard in this regard.
</p>
<p>
-Alisdair to provide wording, once that wording arrives, move to review.
+Due to earlier support for copy-on-write, we find the following
+unnecessary limitations for C++0x:
</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
- Replace paragraph 4 of 21.1 [char.traits] by:
-</p>
-<blockquote>
-<p>
- This subclause specifies a struct template, <code>char_traits<charT></code>,
- and four explicit specializations of it, <code>char_traits<char></code>,
- <code>char_traits<char16_t></code>, <code>char_traits<char32_t></code>, and
- <code>char_traits<wchar_t></code>, all of which appear in the header
- <string> and satisfy the requirements below.
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="832"></a>832. Applying constexpr to System error support</h3>
-<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-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>
-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>
+<ol>
+<li>
+Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
+a pointer to their guts, which is a non-failure operation. This should
+be spelled out. It is also noteworthy to mention that the same
+guarantees should also be given by the size query functions,
+because the combination of pointer to content and the length is
+typically needed during interaction with low-level API.
+</li>
+<li>
+Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
+a pointer to their guts, which is guaranteed O(1). This should be
+spelled out.
+</li>
+<li>
+Missing reading access to the terminating character: Only the
+const overload of <tt>operator[]</tt> allows reading access to the terminator
+char. For more intuitive usage of strings, reading access to this
+position should be extended to the non-const case. In contrast
+to C++03 this reading access should now be homogeneously
+an lvalue access.
+</li>
+</ol>
<p>
-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.
+The proposed resolution is split into a main part (A) and a
+secondary part (B) (earlier called "Adjunct Adjunct Proposal").
+(B) extends (A) by also making access to index position
+size() of the at() overloads a no-throw operation. This was
+separated, because this part is theoretically observable in
+specifically designed test programs.
</p>
<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-On going question of extern pointer vs. inline functions for interface.
-</blockquote>
-
-<p><i>[
-Pre-San Francisco:
+San Francisco:
]</i></p>
<blockquote>
<p>
-Beman Dawes reports that this proposal is unimplementable, and thus NAD.
-</p>
-<p>
-Implementation would require <tt>constexpr</tt> objects of classes derived
-from class <tt>error_category</tt>, which has virtual functions, and that is
-not allowed by the core language. This was determined when trying to
-implement the proposal using a constexpr enabled compiler provided
-by Gabriel Dos Reis, and subsequently verified in discussions with
-Gabriel and Jens Maurer.
+We oppose part 1 of the issue but hope to address <tt>size()</tt> in
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>.
</p>
-
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
<p>
-The proposed wording assumes the LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> proposed wording has been
-applied to the WP, resulting in the former <tt>posix_category</tt> being renamed
-<tt>generic_category</tt>. If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has not been applied, the names in this
-proposal must be adjusted accordingly.
+We do not support part B. 4 of the issue because of the breaking API change.
</p>
-
<p>
-Change 19.4.1.1 [syserr.errcat.overview] Class
-<tt>error_category</tt> overview <tt>error_category</tt> synopsis as
-indicated:
+We support part A. 2 of the issue.
</p>
-
-<blockquote><pre><del>const error_category& get_generic_category();</del>
-<del>const error_category& get_system_category();</del>
-
-<del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
-<del>static</del> <ins>extern</ins> const error_category<del>&</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:
+On support part A. 3 of the issue:
</p>
-
<blockquote>
-<pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
-</pre>
-<p>
-<del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
-to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
-class <tt>error_category</tt>.
-</p>
-
-<p>
-<del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
-functions shall behave as specified for the class <tt>error_category</tt>. The
-object's <tt>name</tt> virtual function shall return a pointer to the string
-<tt>"GENERIC"</tt>.
-</p>
-
-<pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
-</pre>
-
-<p>
-<del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
-to <del>an</del> <ins>a statically
-initialized</ins> object of a type derived from class <tt>error_category</tt>.
-</p>
-
-<p>
-<del><i>Remarks:</i></del> The object's <tt>equivalent</tt> virtual functions shall behave as
-specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
-shall return a pointer to the string <tt>"system"</tt>. The object's
-<tt>default_error_condition</tt> virtual function shall behave as follows:
-</p>
-
-<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>
+Pete's broader comment: now that we know that basic_string will be a
+block of contiguous memory, we should just rewrite its specification
+with that in mind. The expression of the specification will be simpler
+and probably more correct as a result.
+</blockquote>
</blockquote>
-<p>
-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>&</del><ins>*</ins> cat);
- ...
- void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
- ...
- const error_category<del>&</del><ins>*</ins> category() const;
- ...
-private:
- int val_; // exposition only
- const error_category<del>&</del><ins>*</ins> cat_; // exposition only
-</pre></blockquote>
-<p>
-Change 19.4.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
+<p><b>Proposed resolution:</b></p>
+<ol type="A">
+<li>
+<ol>
+<li>
+<p>In 21.4.4 [string.capacity], just after p. 1 add a new paragraph:
</p>
-
<blockquote>
-<pre><ins>constexpr</ins> error_code(int val, const error_category<del>&</del><ins>*</ins> cat);
-</pre>
-<p>
-<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
-</p>
-<p>
<i>Throws:</i> Nothing.
-</p>
</blockquote>
+</li>
+<li>
<p>
-Change 19.4.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers as indicated:
+In 21.4.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs:
</p>
<blockquote>
-<pre>void assign(int val, const error_category<del>&</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:
+<i>Requires:</i> <tt>pos ≤ size()</tt>.
</p>
-
-<blockquote>
-<pre>const error_category<del>&</del><ins>*</ins> category() const;
-</pre>
-
<p>
-<i>Returns:</i> <tt>cat_</tt>.
+<i>Returns:</i> If <tt>pos < size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns
+a reference to a <tt>charT()</tt> that shall not be modified.
</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:
+<i>Complexity:</i> Constant time.
</p>
-
-<blockquote>
-<pre>class error_condition {
-public:
- ...;
- <ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat);
- ...
- void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
- ...
- const error_category<del>&</del><ins>*</ins> category() const;
- ...
-private:
- int val_; // exposition only
- const error_category<del>&</del><ins>*</ins> cat_; // exposition only
-</pre>
</blockquote>
+</li>
+<li>
<p>
-Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
+In 21.4.7.1 [string.accessors] replace the now <em>common</em> returns
+clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs:
</p>
-
<blockquote>
-<pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat);
-</pre>
-<p>
-<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
-</p>
<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
+<i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &operator[](i)</tt> for each <tt>i</tt>
+in <tt>[0, size()]</tt>.
</p>
<p>
<i>Throws:</i> Nothing.
</p>
-</blockquote>
-
-<p>
-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>&</del><ins>*</ins> cat);
-</pre>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
-</p>
<p>
-<i>Throws:</i> Nothing.
+<i>Complexity:</i> Constant time.
</p>
</blockquote>
-
+</li>
+</ol>
+</li>
+<li>
+<ol start="4">
+<li>
<p>
-Change 19.4.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
+In 21.4.5 [string.access] <em>replace</em> p.2 and p.3 by:
</p>
-
<blockquote>
-<pre>const error_category<del>&</del><ins>*</ins> category() const;
-</pre>
<p>
-<i>Returns:</i> <tt>cat_</tt>.
+<i>Requires:</i> <tt>pos ≤ size()</tt>
</p>
<p>
-<i>Throws:</i> Nothing.
+<i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > size()</tt>.
</p>
</blockquote>
+</li>
+</ol>
+</li>
+</ol>
-<p>
-Throughout 19.4 [syserr] System error support, change "<tt>category().</tt>" to "<tt>category()-></tt>".
-Appears approximately six times.
-</p>
-<p>
-<i>[Partially Editorial]</i> In 19.4.4 [syserr.compare] Comparison operators,
-paragraphs 2 and 4, change "<tt>category.equivalent(</tt>" to
-"<tt>category()->equivalent(</tt>".
-</p>
-<p>
-Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated:
-</p>
-<blockquote><pre>public:
- system_error(error_code ec, const string& what_arg);
- system_error(error_code ec);
- system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat,
- const string& what_arg);
- system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat);
-</pre></blockquote>
-<p>
-Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated:
-</p>
-<blockquote>
-<pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat, const string& what_arg);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
-<tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
-</p>
-</blockquote>
+<hr>
+<h3><a name="877"></a>877. to <tt>throw()</tt> or to <i>Throw:</i> Nothing.</h3>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-08-23 <b>Last modified:</b> 2008-09-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+ <p>
-<pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
-<tt>strcmp(runtime_error::what(), "") == 0</tt>.
-</p>
-</blockquote>
-</blockquote>
+Recent changes to
+the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">working
+draft</a> have introduced a gratuitous inconsistency with the C++ 2003
+version of the specification with respect to exception guarantees
+provided by standard functions. While the C++ 2003 standard
+consistenly uses the empty exception specification, <tt>throw()</tt>,
+to declare functions that are guaranteed not to throw exceptions, the
+current working draft contains a number of "<i>Throws:</i> Nothing."
+clause to specify essentially the same requirement. The difference
+between the two approaches is that the former specifies the behavior
+of programs that violate the requirement (<tt>std::unexpected()</tt>
+is called) while the latter leaves the behavior undefined.
+ </p>
+ <p>
+A survey of the working draft reveals that there are a total of 209
+occurrences of <tt>throw()</tt> in the library portion of the spec,
+the majority in clause 18, a couple (literally) in 19, a handful in
+20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9.
+ </p>
+ <p>
+There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered
+throughout the spec.
+ </p>
+ <p>
-<hr>
-<h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
-<p><b>Section:</b> 17.4.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-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>
-
-
-
-
-
-<hr>
-<h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
-<p><b>Section:</b> 20.7.11.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-05-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>) proposes a useful
-extension point for <tt>unique_ptr</tt> by granting support for an optional
-<tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
-(In the following: <tt>pointer</tt>).
-</p>
-<p>
-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>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the
-arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector<T>::iterator</tt>.
-</p>
-<p>
-Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following sentence just at the end of the newly proposed
-20.7.11.2 [unique.ptr.single]/p. 3:
-</p>
-
-<blockquote>
-<tt>unique_ptr<T, D>::pointer</tt>'s operations shall be well-formed, shall have well
-defined behavior, and shall not throw exceptions.
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
-<p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The fix for
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
-now integrated into the working paper, overlooks a couple of minor
-problems.
+While sometimes there are good reasons to use the "<i>Throws:</i>
+Nothing." approach rather than making use of <tt>throw()</tt>, these
+reasons do not apply in most of the cases where this new clause has
+been introduced and the empty exception specification would be a
+better approach.
</p>
<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.
+First, functions declared with the empty exception specification
+permit compilers to generate better code for calls to such
+functions. In some cases, the compiler might even be able to eliminate
+whole chunks of user-written code when instantiating a generic
+template on a type whose operations invoked from the template
+specialization are known not to throw. The prototypical example are
+the <tt>std::uninitialized_copy()</tt>
+and <tt>std::uninitialized_fill()</tt> algorithms where the
+entire <tt>catch(...)</tt> block can be optimized away.
</p>
<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 << std::flush;</code>
+For example, given the following definition of
+the <tt>std::uninitialized_copy</tt> function template and a
+user-defined type <tt>SomeType</tt>:
</p>
<blockquote>
- <pre>#include <iostream>
-
-int main ()
+ <pre>template <class InputIterator, class ForwardIterator>
+ForwardIterator
+uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
{
- std::cout.tie (&std::cerr);
- std::cerr.tie (&std::cout);
- std::cout << "cout\n";
- std::cerr << "cerr\n";
-}
- </pre>
- </blockquote>
-
- <p><b>Proposed resolution:</b></p>
- <p>
+ typedef iterator_traits<ForwardIterator>::value_type ValueType;
-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->tie()</code>
-through <code>tiestr()->tie()->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.
+ ForwardIterator start = res;
- </p>
+ try {
+ for (; first != last; ++first, ++res)
+ ::new (&*res) ValueType (*first);
+ }
+ catch (...) {
+ for (; start != res; --start)
+ (&*start)->~ValueType ();
+ throw;
+ }
+ return res;
+}
+
+struct SomeType {
+ SomeType (const SomeType&) <ins>throw ()</ins>;
+}</pre>
+ </blockquote>
<p>
-Add a <i>Requires</i> clause to 27.4.4.2 [basic.ios.members] withethe following
-text:
+compilers are able to emit the following efficient specialization
+of <tt>std::uninitialized_copy<const SomeType*, SomeType*></tt>
+(note that the <tt>catch</tt> block has been optimized away):
</p>
<blockquote>
+ <pre>template <> SomeType*
+uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
+{
+ for (; first != last; ++first, ++res)
+ ::new (res) SomeType (*first);
-<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->tie()</code>.
-
+ return res;
+}</pre>
</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:
+Another general example is default constructors which, when decorated
+with <tt>throw()</tt>, allow the compiler to eliminate the
+implicit <tt>try</tt> and <tt>catch</tt> blocks that it otherwise must
+emit around each the invocation of the constructor
+in <i>new-expressions</i>.
</p>
- <blockquote>
+ <p>
-If <code>((os.flags() & ios_base::unitbuf) &&
-!uncaught_exception())</code> is true,
-calls <del>os.flush()</del> <ins><code>os.rdbuf()->pubsync()</code></ins>.
+For example, given the following definitions of
+class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two
+statements below:
- </blockquote>
-
+ </p>
+ <blockquote>
+ <pre>struct MayThrow {
+ MayThrow ();
+};
+struct WontThrow {
+ WontThrow () <ins>throw ()</ins>;
+};
+MayThrow *a = new MayThrow [N];
+WontThrow *b = new WontThrow [N];</pre>
-<hr>
-<h3><a name="836"></a>836.
- effects of <code>money_base::space</code> and
- <code>money_base::none</code> on <code>money_get</code>
- </h3>
-<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a></p>
-<p><b>Discussion:</b></p>
+ </blockquote>
<p>
-In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following:
+the compiler generates the following code for the first statement:
</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.
-
+ <pre>MayThrow *a;
+{
+ MayThrow *first = operator new[] (N * sizeof (*a));
+ MayThrow *last = first + N;
+ MayThrow *next = first;
+ try {
+ for ( ; next != last; ++next)
+ new (next) MayThrow;
+ }
+ catch (...) {
+ for ( ; first != first; --next)
+ next->~MayThrow ();
+ operator delete[] (first);
+ throw;
+ }
+ a = first;
+}</pre>
</blockquote>
<p>
-This requirement can be (and has been) interpreted two mutually
-exclusive ways by different readers. One possible interpretation
-is that:
+but it is can generate much more compact code for the second statement:
</p>
<blockquote>
- <ol>
- <li>
-
-where <code>money_base::space</code> appears in the format, at least
-one space is required, and
+ <pre>WontThrow *b = operator new[] (N * sizeof (*b));
+WontThrow *last = b + N;
+for (WontThrow *next = b; next != last; ++next)
+ new (next) WontThrow;
+</pre>
+ </blockquote>
+ <p>
- </li>
- <li>
+Second, in order for users to get the maximum benefit out of the new
+<tt>std::has_nothrow_xxx</tt> traits when using standard library types
+it will be important for implementations to decorate all non throwing
+copy constructors and assignment operators with <tt>throw()</tt>. Note
+that while an optimizer may be able to tell whether a function without
+an explicit exception specification can throw or not based on its
+definition, it can only do so when it can see the source code of the
+definition. When it can't it must assume that the function may
+throw. To prevent violating the One Definition Rule,
+the <tt>std::has_nothrow_xxx</tt> trait must return the most
+pessimistic guess across all translation units in the program, meaning
+that <tt>std::has_nothrow_xxx<T>::value</tt> must evaluate to
+<tt>false</tt> for any <tt>T</tt> whose <tt>xxx</tt>
+(where <tt>xxx</tt> is default or copy ctor, or assignment operator)
+is defined out-of-line.
-where <code>money_base::none</code> appears in the format, space is
-allowed but not required.
+ </p>
+ <p>
- </li>
- </ol>
- </blockquote>
+<b>Counterarguments:</b>
+
+ </p>
<p>
-The other is that:
+During the discussion of this issue
+on <a href="mailto:c++std-lib@accu.org">c++std-lib@accu.org</a>
+(starting with post <tt>c++std-lib-21950</tt>) the following arguments
+in favor of the "<i>Throws:</i> Nothing." style have been made.
</p>
- <blockquote>
+ <p>
+ </p><ol>
+ <li>
-where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
+Decorating functions that cannot throw with the empty exception
+specification can cause the compiler to generate suboptimal code for
+the implementation of the function when it calls other functions that
+aren't known to the compiler not to throw (i.e., that aren't decorated
+with <tt>throw()</tt> even if they don't actually throw). This is a
+common situation when the called function is a C or POSIX function.
- </blockquote>
-
+ </li>
+ <li>
+
+Alternate, proprietary mechanisms exist (such as
+GCC <a href="http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#index-g_t_0040code_007bnothrow_007d-function-attribute-2160"><tt>__attribute__((nothrow))</tt></a>
+or Visual
+C++ <a href="http://msdn.microsoft.com/en-us/library/49147z04%28VS.80%29.aspx"><tt>__declspec(nothrow)</tt></a>)
+that let implementers mark up non-throwing functions, often without
+the penalty mentioned in (1) above. The C++ standard shouldn't
+preclude the use of these potentially more efficient mechanisms.
+
+ </li>
+ <li>
+
+There are functions, especially function templates, that invoke
+user-defined functions that may or may not be
+declared <tt>throw()</tt>. Declaring such functions with the empty
+exception specification will cause compilers to generate suboptimal
+code when the user-defined function isn't also declared not to throw.
+
+ </li>
+ </ol>
+
+ <p>
+
+The answer to point (1) above is that implementers can (and some have)
+declare functions with <tt>throw()</tt> to indicate to the compiler
+that calls to the function can safely be assumed not to throw in order
+to allow it to generate efficient code at the call site without also
+having to define the functions the same way and causing the compiler
+to generate suboptimal code for the function definition. That is, the
+function is declared with <tt>throw()</tt> in a header but it's
+defined without it in the source file. The <tt>throw()</tt>
+declaration is suppressed when compiling the definition to avoid
+compiler errors. This technique, while strictly speaking no permitted
+by the language, is safe and has been employed in practice. For
+example, the GNU C library takes this approach. Microsoft Visual C++
+takes a similar approach by simply assuming that no function with C
+language linkage can throw an exception unless it's explicitly
+declared to do so using the language extension <tt>throw(...)</tt>.
+
+ </p>
+ <p>
+
+Our answer to point (2) above is that there is no existing practice
+where C++ Standard Library implementers have opted to make use of the
+proprietary mechanisms to declare functions that don't throw. The
+language provides a mechanism specifically designed for this
+purpose. Avoiding its use in the specification itself in favor of
+proprietary mechanisms defeats the purpose of the feature. In
+addition, making use of the empty exception specification
+inconsistently, in some areas of the standard, while conspicuously
+avoiding it and making use of the "<i>Throws:</i> Nothing." form in
+others is confusing to users.
+
+ </p>
+ <p>
+
+The answer to point (3) is simply to exercise caution when declaring
+functions and especially function templates with the empty exception
+specification. Functions that required not to throw but that may call
+back into user code are poor candidates for the empty exception
+specification and should instead be specified using "<i>Throws:</i>
+Nothing." clause.
+ </p>
+
<p><b>Proposed resolution:</b></p>
<p>
-I propose to change the text to make it clear that the first
-interpretation is intended, that is, to make following change to
-22.2.6.1.2 [locale.money.get.virtuals], p2:
+We propose two possible solutions. Our recommendation is to adopt
+Option 1 below.
</p>
+ <p>
- <blockquote>
+<b>Option 1:</b>
-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() & str.showbase)</code> is <code>false</code>, ...
+ </p>
+ <p>
- </blockquote>
+Except for functions or function templates that make calls back to
+user-defined functions that may not be declared <tt>throw()</tt>
+replace all occurrences of the "<i>Throws:</i> Nothing." clause with
+the empty exception specification. Functions that are required not to
+throw but that make calls back to user code should be specified to
+"<i>Throw:</i> Nothing."
+
+ </p>
+ <p>
+
+<b>Option 2:</b>
+
+ </p>
+ <p>
+
+For consistency, replace all occurrences of the empty exception
+specification with a "<i>Throws:</i> Nothing." clause.
+
+ </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>
+<h3><a name="878"></a>878. <tt>forward_list</tt> preconditions</h3>
+<p><b>Section:</b> 23.3.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-08-23 <b>Last modified:</b> 2009-05-10</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
- <p>
-The <code>basic_ios::copyfmt()</code> member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects:
+<tt>forward_list</tt> member functions that take
+a <tt>forward_list::iterator</tt> (denoted <tt>position</tt> in the
+function signatures) argument have the following precondition:
- </p>
- <blockquote>
+ </p>
-<i>Effects</i>: If <code>(this == &rhs)</code> does
-nothing. Otherwise assigns to the member objects of <code>*this</code>
-the corresponding member objects of <code>rhs</code>, except that
+<i>Requires:</i> <tt>position</tt> is dereferenceable or equal
+to <tt>before_begin()</tt>.
- <ul>
- <li>
+ </blockquote>
+ <p>
-<code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
+I believe what's actually intended is this:
- </li>
- <li>
+ </p>
+ <blockquote>
-<code>exceptions()</code> is altered last by
-calling <code>exceptions(rhs.except)</code>
+<i>Requires:</i> <tt>position</tt> is in the range
+[<tt>before_begin()</tt>, <tt>end()</tt>).
- </li>
- <li>
+ </blockquote>
+ <p>
-the contents of arrays pointed at by <code>pword</code>
-and <code>iword</code> are copied not the pointers themselves
+That is, when it's dereferenceable, <tt>position</tt> must point
+into <tt>*this</tt>, not just any <tt>forward_list</tt> object.
- </li>
- </ul>
- </blockquote>
- <p>
+ </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><i>[
+San Francisco:
+]</i></p>
- </p>
-
- <p><b>Proposed resolution:</b></p>
- <p>
+<blockquote>
+Robert suggested alternate proposed wording which had large support.
+</blockquote>
-I propose to tighten things up by adding a <i>Postcondition</i> clause
-to the function like so:
+<p><i>[
+Post Summit:
+]</i></p>
- </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>
+<blockquote>
+<p>
+Walter: "position is before_begin() or a dereferenceable": add "is" after the "or"
+</p>
+<p>
+With that minor update, Recommend Tentatively Ready.
+</p>
+</blockquote>
-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>
-
+<p><b>Proposed resolution:</b></p>
+ <p>
+Change the <i>Requires</i> clauses
+ [forwardlist] , p21, p24, p26, p29, and,
+23.3.3.5 [forwardlist.ops], p39, p43, p47
+as follows:
-<hr>
-<h3><a name="838"></a>838.
- can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
- </h3>
-<p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
+ </p>
+ <blockquote>
-From message c++std-lib-20003...
+<i>Requires:</i> <tt>position</tt> is <ins><tt>before_begin()</tt> or is a</ins>
+dereferenceable
+<ins>iterator in the range <tt>[begin(), end())</tt></ins>
+<del>or equal to <tt>before_begin()</tt></del>. ...
- </p>
- <p>
+ </blockquote>
+
-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.
+<hr>
+<h3><a name="879"></a>879. Atomic load const qualification</h3>
+<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alexander Chemeris <b>Opened:</b> 2008-08-24 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The <tt>atomic_address</tt> type and <tt>atomic<T*></tt> specialization provide atomic
+updates to pointers. However, the current specification requires
+that the types pointer be to non-const objects. This restriction
+is unnecessary and unintended.
+</p>
- </blockquote>
- <p>
+<p><i>[
+Summit:
+]</i></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 >> value</code>, without checking
-for <code>(in_stream == 0)</code>.
+<blockquote>
+Move to review. Lawrence will first check with Peter whether the
+current examples are sufficient, or whether they need to be expanded to
+include all cases.
+</blockquote>
- </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><b>Proposed resolution:</b></p>
+<p>
+Add const qualification to the pointer values of the <tt>atomic_address</tt>
+and <tt>atomic<T*></tt> specializations. E.g.
+</p>
+
+<blockquote><pre>typedef struct atomic_address {
+ void store(<ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile;
+ void* exchange( <ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile;
+ bool compare_exchange( <ins>const</ins> void*&, <ins>const</ins> void*,
+ memory_order, memory_order) volatile;
+ bool compare_exchange( <ins>const</ins> void*&, <ins>const</ins> void*,
+ memory_order = memory_order_seq_cst ) volatile;
+ void* operator=(<ins>const</ins> void*) volatile;
+} atomic_address;
+
+void atomic_store(volatile atomic_address*, <ins>const</ins> void*);
+void atomic_store_explicit(volatile atomic_address*, <ins>const</ins> void*,
+ memory_order);
+void* atomic_exchange(volatile atomic_address*<ins>, const void*</ins>);
+void* atomic_exchange_explicit(volatile atomic_address*, <ins>const</ins> void*,
+ memory_order);
+bool atomic_compare_exchange(volatile atomic_address*,
+ <ins>const</ins> void**, <ins>const</ins> void*);
+bool atomic_compare_exchange_explicit(volatile atomic_address*,
+ <ins>const</ins> void**, <ins>const</ins> void*,
+ memory_order, memory_order);
+</pre></blockquote>
- </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 << "2 3 ";
- assert (it != eos);
- i = *++it;
- assert (3 == i);
- </pre>
- </blockquote>
- <p>
+<hr>
+<h3><a name="880"></a>880. Missing atomic exchange parameter</h3>
+<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-08-24 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a></p>
+<p><b>Discussion:</b></p>
+<p>
+The <tt>atomic_exchange</tt> and <tt>atomic_exchange_explicit</tt> functions seem to
+be inconsistently missing parameters.
+</p>
-Or is it intended that once an iterator becomes EOS it stays EOS until
-the end of its lifetime?
+<p><i>[
+Post Summit:
+]</i></p>
- </p>
-
- <p><b>Proposed resolution:</b></p>
- <p>
+<blockquote>
+<p>
+Lawrence: Need to write up a list for Pete with details.
+</p>
+<p>
+Detlef: Should not be New, we already talked about in Concurrency group.
+</p>
+<p>
+Recommend Open.
+</p>
+</blockquote>
-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>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the appropriate parameters. For example,
+</p>
-To this end we propose to change 24.5.1 [istream.iterator], p1,
-as follows:
+<blockquote><pre>bool atomic_exchange(volatile atomic_bool*<ins>, bool</ins>);
+bool atomic_exchange_explicit(volatile atomic_bool*, bool<ins>, memory_order</ins>);
+</pre></blockquote>
- </p>
- <blockquote>
-The result of operator-> on an end<ins>-</ins>of<ins>-</ins>stream
-is not defined. For any other iterator value a <code>const T*</code>
-is returned.<ins> Invoking <code>operator++()</code> on
-an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
-to store things into istream iterators...
- </blockquote>
- <p>
-Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
- </p>
- <blockquote>
+<hr>
+<h3><a name="881"></a>881. shared_ptr conversion issue</h3>
+<p><b>Section:</b> 20.8.13.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-08-30 <b>Last modified:</b> 2008-09-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+We've changed <tt>shared_ptr<Y></tt> to not convert to <tt>shared_ptr<T></tt> when <tt>Y*</tt>
+doesn't convert to <tt>T*</tt> by resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>. This only fixed the
+converting copy constructor though.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
+later added move support, and
+the converting move constructor is not constrained.
+</p>
-<pre>istream_iterator();</pre>
+<p><i>[
+San Francisco:
+]</i></p>
-<i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
-<ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
-<pre>istream_iterator(istream_type &s);</pre>
+<blockquote>
+We might be able to move this to NAD, Editorial once shared_ptr is
+conceptualized, but we want to revisit this issue to make sure.
+</blockquote>
-<i>Effects</i>: Initializes <code>in_stream</code> with &s. value
-may be initialized during construction or the first time it is
-referenced.<br>
-<ins><i>Postcondition</i>: <code>in_stream == &s</code>.</ins>
-<pre>istream_iterator(const istream_iterator &x);</pre>
+<p><b>Proposed resolution:</b></p>
+<p>
+We need to change the Requires clause of the move constructor:
+</p>
-<i>Effects</i>: Constructs a copy of <code>x</code>.<br>
-<ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
+<blockquote><pre>shared_ptr(shared_ptr&& r);
+template<class Y> shared_ptr(shared_ptr<Y>&& r);
+</pre>
+<blockquote>
+<i>Requires:</i> <del>For the second constructor <tt>Y*</tt> shall be
+convertible to <tt>T*</tt>.</del>
+<ins>
+The second constructor shall not participate in overload resolution
+unless <tt>Y*</tt> is convertible to <tt>T*</tt>.
+</ins>
+</blockquote>
+</blockquote>
-<pre>istream_iterator& operator++();</pre>
+<p>
+in order to actually make the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a> compile
+(it now resolves to the move constructor).
+</p>
-<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
-<i>Effects</i>: <code>*in_stream >> value</code>.
-<pre>istream_iterator& 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 >> value;
-return tmp;
- </pre>
- </blockquote>
- </blockquote>
-
<hr>
-<h3><a name="839"></a>839. Maps and sets missing splice operation</h3>
-<p><b>Section:</b> 23.3 [associative], 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alan Talbot <b>Date:</b> 2008-05-18</p>
+<h3><a name="883"></a>883. swap circular definition</h3>
+<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-10 <b>Last modified:</b> 2009-03-11</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>
-Splice is a very useful feature of <tt>list</tt>. This functionality is also very
-useful for any other node based container, and I frequently wish it were
-available for maps and sets. It seems like an omission that these
-containers lack this capability. Although the complexity for a splice is
-the same as for an insert, the actual time can be much less since the
-objects need not be reallocated and copied. When the element objects are
-heavy and the compare operations are fast (say a <tt>map<int, huge_thingy></tt>)
-this can be a big win.
-</p>
<p>
-<b>Suggested resolution:</b>
+Note in particular that Table 90 "Container Requirements" gives
+semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>, yet for all
+containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a
+circular definition.
</p>
-<p>
-Add the following signatures to map, set, multimap, multiset, and the unordered associative containers:
-</p>
-<blockquote><pre>
-void splice(list<T,Allocator>&& x);
-void splice(list<T,Allocator>&& x, const_iterator i);
-void splice(list<T,Allocator>&& x, const_iterator first, const_iterator last);
-</pre></blockquote>
+<p><i>[
+San Francisco:
+]</i></p>
-<p>
-Hint versions of these are also useful to the extent hint is useful.
-(I'm looking for guidance about whether hints are in fact useful.)
-</p>
-
-<blockquote><pre>
-void splice(const_iterator position, list<T,Allocator>&& x);
-void splice(const_iterator position, list<T,Allocator>&& x, const_iterator i);
-void splice(const_iterator position, list<T,Allocator>&& x, const_iterator first, const_iterator last);
-</pre></blockquote>
+
+<blockquote>
+Robert to propose a resolution along the lines of "Postcondition: "a =
+b, b = a" This will be a little tricky for the hash containers, since
+they don't have <tt>operator==</tt>.
+</blockquote>
<p><i>[
-Sophia Antipolis:
+Post Summit Anthony Williams provided proposed wording.
]</i></p>
-<blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type.
+In table 80 in section 23.2.1 [container.requirements.general],
+replace the postcondition of <tt>a.swap(b)</tt> with the following:
</p>
-<p>
-<tt>forward_list</tt> already has <tt>splice_after</tt>.
-</p>
-<p>
-Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>?
-</p>
-<p>
-Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s.
-</p>
-<p>
-Howard: <tt>adopt</tt>?
-</p>
-<p>
-Jens: <tt>absorb</tt>?
-</p>
-<p>
-Alan: <tt>subsume</tt>?
-</p>
-<p>
-Robert: <tt>recycle</tt>?
-</p>
-<p>
-Howard: <tt>transfer</tt>? (but no direction)
-</p>
-<p>
-Jens: <tt>transfer_from</tt>. No.
-</p>
-<p>
-Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes.
-</p>
-<p>
-Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow.
-</p>
-</blockquote>
+<blockquote>
+<table border="1">
+<caption>Table 80 -- Container requirements</caption>
+<tbody><tr>
+<th>Expression</th>
+<th>Return type</th>
+<th>Operational semantics</th>
+<th>Assertion/note pre-/post-conidtion</th>
+<th>Complexity</th>
+</tr>
+<tr>
+<td>...</td>
+<td>...</td>
+<td>...</td>
+<td>...</td>
+<td>...</td>
+</tr>
+<tr>
+<td><tt>a.swap(b);</tt></td>
+<td><tt>void</tt></td>
+<td> </td>
+<td><del><tt>swap(a,b)</tt></del>
+<ins>Exchange the contents of <tt>a</tt> and <tt>b</tt> as-if<br>
+<tt>X u=std::move(a);<br>
+a=std::move(b);<br>
+b=std::move(u);</tt></ins></td>
+<td>(Note A)</td>
+</tr>
+</tbody></table>
+</blockquote>
+<p>
+Remove the reference to swap from the paragraph following the table.
+</p>
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+Notes: the algorithms <del><tt>swap()</tt>, </del><tt>equal()</tt> and
+<tt>lexicographical_compare()</tt> are defined in Clause 25. ...
+</blockquote>
<hr>
-<h3><a name="841"></a>841. cstdint.syn inconsistent with C99</h3>
-<p><b>Section:</b> 18.3.1 [cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="884"></a>884. shared_ptr swap</h3>
+<p><b>Section:</b> 20.8.13.2.4 [util.smartptr.shared.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
- <p>
-
-In specifying the names of macros and types defined in
-header <code><stdint.h></code>, C99 makes use of the
-symbol <code><i>N</i></code> to accommodate unusual platforms with
-word sizes that aren't powers of two. C99
-permits <code><i>N</i></code> to take on any positive integer value
-(including, for example, 24).
-
- </p>
- <p>
+<blockquote><pre>#include <memory>
+#include <cassert>
-In cstdint.syn Header <code><cstdint></code>
-synopsis, C++ on the other hand, fixes the value
-of <code><i>N</i></code> to 8, 16, 32, and 64, and specifies only
-types with these exact widths.
+struct A { };
+struct B : A { };
- </p>
- <p>
- </p>
+int main()
+{
+ std::shared_ptr<A> pa(new A);
+ std::shared_ptr<B> pb(new B);
+ std::swap<A>(pa, pb); // N.B. no argument deduction
+ assert( pa.get() == pb.get() );
+ return 0;
+}
+</pre></blockquote>
-In addition, paragraph 1 of the same section makes use of a rather
-informal shorthand notation to specify sets of macros. When
-interpreted strictly, the notation specifies macros such
-as <code>INT_8_MIN</code> that are not intended to be specified.
+<p>
+Is this behaviour correct (I believe it is) and if so, is it
+unavoidable, or not worth worrying about?
+</p>
- <p>
+<p>
+This calls the lvalue/rvalue swap overload for <tt>shared_ptr</tt>:
+</p>
-Finally, the section is missing the usual table of symbols defined
-in that header, making it inconsistent with the rest of the
-specification.
+<blockquote><pre>template<class T> void swap( shared_ptr<T> & a, shared_ptr<T> && b );
+</pre></blockquote>
- </p>
-
- <p><b>Proposed resolution:</b></p>
- <p>
+<p>
+silently converting the second argument from <tt>shared_ptr<B></tt> to
+<tt>shared_ptr<A></tt> and binding the rvalue ref to the produced temporary.
+</p>
-I propose to use the same approach in the C++ spec as C99 uses, that
-is, to specify the header synopsis in terms of "exposition only" types
-that make use of the symbol <code><i>N</i></code> to denote one or
-more of a theoretically unbounded set of widths.
+<p>
+This is not, in my opinion, a <tt>shared_ptr</tt> problem; it is a general issue
+with the rvalue swap overloads. Do we want to prevent this code from
+compiling? If so, how?
+</p>
- </p>
- <p>
+<p>
+Perhaps we should limit rvalue args to swap to those types that would
+benefit from the "swap trick". Or, since we now have <tt>shrink_to_fit()</tt>, just
+eliminate the rvalue swap overloads altogether. The original motivation
+was:
+</p>
-Further, I propose to add a new table to section listing the symbols
-defined in the header using a more formal notation that avoids
-introducing inconsistencies.
+<blockquote><pre>vector<A> v = ...;
+...
+swap(v, vector<A>(v));
+</pre></blockquote>
- </p>
- <p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html#Improved%20swap%20Interface">N1690</a>.
-To this effect, in cstdint.syn
-Header <code><cstdint></code> synopsis, replace both the
-synopsis and paragraph 1 with the following text:
+<p><i>[
+Batavia (2009-05):
+]</i></p>
- </p>
- <blockquote>
- <p>
- </p><ol>
- <li>
-
-In the names defined in the <code><cstdint></code> header, the
-symbol <code><i>N</i></code> represents a positive decimal integer
-with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the
-exception of exact-width types, macros and types for values
-of <code><i>N</i></code> in the set of 8, 16, 32, and 64 are
-required. Exact-width types, and any macros and types for values
-of <code><i>N</i></code> other than 8, 16, 32, and 64 are
-optional. However, if an implementation provides integer types with
-widths of 8, 16, 32, or 64 bits, the corresponding exact-width types
-and macros are required.
-
- </li>
- </ol>
-
- <pre>namespace std {
-
- // required types
-
- // Fastest minimum-width integer types
- typedef <i>signed integer type</i> int_fast8_t;
- typedef <i>signed integer type</i> int_fast16_t;
- typedef <i>signed integer type</i> int_fast32_t;
- typedef <i>signed integer type</i> int_fast64_t;
-
- typedef <i>unsigned integer type</i> uint_fast8_t;
- typedef <i>unsigned integer type</i> uint_fast16_t;
- typedef <i>unsigned integer type</i> uint_fast32_t;
- typedef <i>unsigned integer type</i> uint_fast64_t;
-
- // Minimum-width integer types
- typedef <i>signed integer type</i> int_least8_t;
- typedef <i>signed integer type</i> int_least16_t;
- typedef <i>signed integer type</i> int_least32_t;
- typedef <i>signed integer type</i> int_least64_t;
-
- typedef <i>unsigned integer type</i> uint_least8_t;
- typedef <i>unsigned integer type</i> uint_least16_t;
- typedef <i>unsigned integer type</i> uint_least32_t;
- typedef <i>unsigned integer type</i> uint_least64_t;
-
- // Greatest-width integer types
- typedef <i>signed integer type</i> intmax_t;
- typedef <i>unsigned integer type</i> uintmax_t;
-
- // optionally defined types
-
- // Exact-width integer types
- typedef <i>signed integer type</i> int<i>N</i>_t;
- typedef <i>unsigned integer type</i> uint<i>N</i>_t;
-
- // Fastest minimum-width integer types for values
- // of <i>N</i> other than 8, 16, 32, and 64
- typedef <i>signed integer type</i> uint_fast<i>N</i>_t;
- typedef <i>unsigned integer type</i> uint_fast<i>N</i>_t;
-
- // Minimum-width integer types for values
- // of <i>N</i> other than 8, 16, 32, and 64
- typedef <i>signed integer type</i> uint_least<i>N</i>_t;
- typedef <i>unsigned integer type</i> uint_least<i>N</i>_t;
-
- // Integer types capable of holding object pointers
- typedef <i>signed integer type</i> intptr_t;
- typedef <i>signed integer type</i> intptr_t;
+<blockquote>
+We agree with the proposed resolution.
+Move to NAD Editorial.
+</blockquote>
-}</pre>
- </blockquote>
- <p>
-[Note to editor: Remove all of the existing paragraph 1 from cstdint.syn.]
+<p><b>Proposed resolution:</b></p>
+<p>
+Recommend NAD Editorial, fixed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>.
+</p>
- </p>
- <blockquote>
- Table ??: Header <code><cstdint></code> synopsis
- <table border="1">
- <thead>
- <tr>
- <th>Type</th>
- <th colspan="3">Name(s)</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td rowspan="11"><b>Macros:</b></td>
- <td><tt>INT<i>N</i>_MIN</tt></td>
- <td><tt>INT<i>N</i>_MAX</tt></td>
- <td><tt>UINT<i>N</i>_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>INT_FAST<i>N</i>_MIN</tt></td>
- <td><tt>INT_FAST<i>N</i>_MAX</tt></td>
- <td><tt>UINT_FAST<i>N</i>_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>INT_LEAST<i>N</i>_MIN</tt></td>
- <td><tt>INT_LEAST<i>N</i>_MAX</tt></td>
- <td><tt>UINT_LEAST<i>N</i>_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>INTPTR_MIN</tt></td>
- <td><tt>INTPTR_MAX</tt></td>
- <td><tt>UINTPTR_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>INTMAX_MIN</tt></td>
- <td><tt>INTMAX_MAX</tt></td>
- <td><tt>UINTMAX_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>PTRDIFF_MIN</tt></td>
- <td><tt>PTRDIFF_MAX</tt></td>
- <td><tt>PTRDIFF_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>SIG_ATOMIC_MIN</tt></td>
- <td><tt>SIG_ATOMIC_MAX</tt></td>
- <td><tt>SIZE_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>WCHAR_MIN</tt></td>
- <td><tt>WCHAR_MAX</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>WINT_MIN</tt></td>
- <td><tt>WINT_MAX</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>INT<i>N</i>_C()</tt></td>
- <td><tt>UINT<i>N</i>_C()</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>INTMAX_C()</tt></td>
- <td><tt>UINTMAX_C()</tt></td>
- <td></td>
- </tr>
- <tr>
- <td rowspan="5"><b>Types:</b></td>
- <td><tt>int<i>N</i>_t</tt></td>
- <td><tt>uint<i>N</i>_t</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>int_fast<i>N</i>_t</tt></td>
- <td><tt>uint_fast<i>N</i>_t</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>int_least<i>N</i>_t</tt></td>
- <td><tt>uint_least<i>N</i>_t</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>intptr_t</tt></td>
- <td><tt>uintptr_t</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>intmax_t</tt></td>
- <td><tt>uintmax_t</tt></td>
- <td></td>
- </tr>
- </tbody>
- </table>
- </blockquote>
-
<hr>
-<h3><a name="842"></a>842. ConstructibleAsElement and bit containers</h3>
-<p><b>Section:</b> 23.1 [container.requirements], 23.2.7 [vector.bool], 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="885"></a>885. pair assignment</h3>
+<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-05-25</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
+<blockquote><pre>20.2.3 pairs
+Missing assignemnt operator:
+template<class U , class V>
+ requires CopyAssignable<T1, U> && CopyAssignable<T2, V>
+ pair& operator=(pair<U , V> const & p );
+</pre></blockquote>
+
<p>
-23.1 [container.requirements]/p3 says:
+Well, that's interesting. This assignment operator isn't in the
+current working paper, either. Perhaps we deemed it acceptable to
+build a temporary of type <tt>pair</tt> from <tt>pair<U, V></tt>, then move-assign
+from that temporary?
</p>
-
-<blockquote>
-Objects stored in these components shall be constructed using
-<tt>construct_element</tt> (20.6.9). For each operation that inserts an
-element of type <tt>T</tt> into a container (<tt>insert</tt>,
-<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
-arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
-as described in table 88. [<i>Note:</i> If the component is instantiated
-with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
-<tt>is_scoped_allocator<A>::value</tt> is <tt>true</tt>), then
-<tt>construct_element</tt> may pass an inner allocator argument to
-<tt>T</tt>'s constructor. <i>-- end note</i>]
-</blockquote>
-
<p>
-However <tt>vector<bool, A></tt> (23.2.7 [vector.bool]) and <tt>bitset<N></tt>
-(23.3.5 [template.bitset]) store bits, not <tt>bool</tt>s, and <tt>bitset<N></tt>
-does not even have an allocator. But these containers are governed by this clause. Clearly this
-is not implementable.
+It sounds more like an issue waiting to be opened, unless you want to plug
+it now. As written we risk moving from lvalues.
</p>
+<p><i>[
+San Francisco:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
+
+<blockquote>
+<p>
+Would be NAD if better ctors fixed it.
+</p>
<p>
-Change 23.1 [container.requirements]/p3:
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#811">811</a>.
</p>
+</blockquote>
+
+<p><i>[
+post San Francisco:
+]</i></p>
+
<blockquote>
-Objects stored in these components shall be constructed using
-<tt>construct_element</tt> (20.6.9)<ins>, unless otherwise specified</ins>.
-For each operation that inserts an
-element of type <tt>T</tt> into a container (<tt>insert</tt>,
-<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
-arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
-as described in table 88. [<i>Note:</i> If the component is instantiated
-with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
-<tt>is_scoped_allocator<A>::value</tt> is <tt>true</tt>), then
-<tt>construct_element</tt> may pass an inner allocator argument to
-<tt>T</tt>'s constructor. <i>-- end note</i>]
+Possibly NAD Editorial, solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
</blockquote>
-<p>
-Change 23.2.7 [vector.bool]/p2:
-</p>
+<p><i>[
+2009-05-25 Alisdair adds:
+]</i></p>
+
<blockquote>
-Unless described below, all operations have the same requirements and semantics as the primary <tt>vector</tt> template,
-except that operations dealing with the <tt>bool</tt> value type map to bit values in the container storage<ins>,
-and <tt>construct_element</tt> (23.1 [container.requirements]) is not used to construct these values</ins>.
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a> was something I reported while reviewing the library concepts
+documents ahead of San Francisco. The missing operator was added as part of
+the paper adopted at that meeting
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>)
+and I can confirm this operator is
+present in the current working paper. I recommend NAD.
</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-Move 23.3.5 [template.bitset] to clause 20.
</p>
-
<hr>
-<h3><a name="843"></a>843. Reference Closure</h3>
-<p><b>Section:</b> 20.6.17.1 [func.referenceclosure.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-02</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="886"></a>886. tuple construction</h3>
+<p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-05-05</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The <tt>std::reference_closure</tt> type has a deleted copy assignment operator
-under the theory that references cannot be assigned, and hence the
-assignment of its reference member must necessarily be ill-formed.
+20.5.2.1 [tuple.cnstr]:
+</p>
+<blockquote>
+<i>Effects:</i> Default initializes each element.
+</blockquote>
+
+<p>
+Could be clarified to state each "non-trivial" element. Otherwise
+we have a conflict with Core deinfition of default initialization -
+trivial types do not get initialized (rather than initialization
+having no effect)
+</p>
+
+<p>
+I'm going to punt on this one, because it's not an issue that's
+related to concepts. I suggest bringing it to Howard's attention on
+the reflector.
</p>
+
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
<p>
-However, other types, notably <tt>std::reference_wrapper</tt> and <tt>std::function</tt>
-provide for the "copying of references", and thus the current definition
-of <tt>std::reference_closure</tt> seems unnecessarily restrictive. In particular,
-it should be possible to write generic functions using both <tt>std::function</tt>
-and <tt>std::reference_closure</tt>, but this generality is much harder when
-one such type does not support assignment.
+Text in draft doesn't mean anything, changing to "non-trivial" makes it
+meaningful.
</p>
<p>
-The definition of <tt>reference_closure</tt> does not necessarily imply direct
-implementation via reference types. Indeed, the <tt>reference_closure</tt> is
-best implemented via a frame pointer, for which there is no standard
-type.
+We prefer "value initializes". Present implementations use
+value-initialization. Users who don't want value initialization have
+alternatives.
</p>
<p>
-The semantics of assignment are effectively obtained by use of the
-default destructor and default copy assignment operator via
+Request resolution text from Alisdair.
</p>
-<blockquote><pre>x.~reference_closure(); new (x) reference_closure(y);
-</pre></blockquote>
-
<p>
-So the copy assignment operator generates no significant real burden
-to the implementation.
+This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a> default construction and value-initialization.
</p>
+</blockquote>
+<p><i>[
+2009-05-04 Alisdair provided wording and adds:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
+
+<blockquote>
<p>
-In 20.6.17 [func.referenceclosure] Class template reference_closure,
-replace the <tt>=delete</tt> in the copy assignment operator in the synopsis
-with <tt>=default</tt>.
+Note: This <em>IS</em> a change of semantic from TR1, although one the room agreed
+with during the discussion. To preserve TR1 semantics, this would have been
+worded:
</p>
+<blockquote><pre>requires DefaultConstructible<Types>... tuple();
+</pre>
+<blockquote>
+-2- <i>Effects:</i> Default-initializes each non-trivial element.
+</blockquote>
+</blockquote>
-<blockquote><pre>template<class R , class... ArgTypes >
- class reference_closure<R (ArgTypes...)> {
- public:
- ...
- reference_closure& operator=(const reference_closure&) = <del>delete</del> <ins>default</ins>;
- ...
-</pre></blockquote>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-In 20.6.17.1 [func.referenceclosure.cons] Construct, copy, destroy,
-add the member function description
+Change p2 in Construction 20.5.2.1 [tuple.cnstr]:
</p>
-<blockquote>
-<pre>reference_closure& operator=(const reference_closure& f)
+<blockquote><pre>requires DefaultConstructible<Types>... tuple();
</pre>
<blockquote>
<p>
-<i>Postcondition:</i> <tt>*this</tt> is a copy of <tt>f</tt>.
-</p>
-<p>
-<i>Returns:</i> <tt>*this</tt>.
+-2- <i>Effects:</i> <del>Default</del> <ins>Value-</ins>initializes each element.
</p>
</blockquote>
</blockquote>
-
<hr>
-<h3><a name="844"></a>844. <tt>complex pow</tt> return type is ambiguous</h3>
-<p><b>Section:</b> 26.3.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="887"></a>887. issue with condition::wait_...</h3>
+<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The current working draft is in an inconsistent state.
+The Posix/C++ working group has identified an inconsistency between
+Posix and the C++ working draft in that Posix requires the clock to be
+identified at creation, whereas C++ permits identifying the clock at the
+call to wait. The latter cannot be implemented with the former.
+</p>
+
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+<p>
+Howard recommends NAD with the following explanation:
</p>
<p>
-26.3.8 [complex.transcendentals] says that:
+The intent of the current wording is for the <tt>condtion_variable::wait_until</tt>
+be able to handle user-defined clocks as well as clocks the system knows about.
+This can be done by providing overloads for the known clocks, and another
+overload for unknown clocks which synchs to a known clock before waiting.
+For example:
</p>
-<blockquote>
-<tt>pow(complex<float>(), int())</tt> returns a <tt>complex<float></tt>.
-</blockquote>
+<blockquote><pre>template <class Duration>
+bool
+condition_variable::wait_until(unique_lock<mutex>& lock,
+ const chrono::time_point<chrono::system_clock, Duration>& abs_time)
+{
+ using namespace chrono;
+ nanoseconds d = __round_up<nanoseconds>(abs_time.time_since_epoch());
+ __do_timed_wait(lock.mutex()->native_handle(), time_point<system_clock, nanoseconds>(d));
+ return system_clock::now() < abs_time;
+}
+
+template <class Clock, class Duration>
+bool
+condition_variable::wait_until(unique_lock<mutex>& lock,
+ const chrono::time_point<Clock, Duration>& abs_time)
+{
+ using namespace chrono;
+ typename Clock::time_point c_entry = Clock::now();
+ system_clock::time_point s_entry = system_clock::now();
+ nanoseconds dn = __round_up<nanoseconds>(abs_time.time_since_epoch() -
+ c_entry.time_since_epoch());
+ __do_timed_wait(lock.mutex()->native_handle(), s_entry + dn);
+ return Clock::now() < abs_time;
+}
+</pre></blockquote>
<p>
-26.3.9 [cmplx.over] says that:
+In the above example, <tt>system_clock</tt> is the only clock which the underlying
+condition variable knows how to deal with. One overload just passes that clock
+through. The second overload (approximately) converts the unknown clock into
+a <tt>system_clock time_point</tt> prior to passing it down to the native
+condition variable.
</p>
-<blockquote>
-<tt>pow(complex<float>(), int())</tt> returns a <tt>complex<double></tt>.
+<p>
+On Posix systems vendors are free to add implementation defined constructors which
+take a clock. That clock can be stored in the condition_variable, and converted
+to (or not as necessary) as shown above.
+</p>
+
+<p>
+If an implementation defined constructor takes a clock (for example), then part
+of the semantics for that implementation defined ctor might include that a
+<tt>wait_until</tt> using a clock other than the one constructed with results
+in an error (exceptional condition) instead of a conversion to the stored clock.
+Such a design is up to the vendor as once an implementation defined ctor is used,
+the vendor is free to specifiy the behavior of waits and/or notifies however
+he pleases (when the cv is constructed in an implementation defined manner).
+</p>
</blockquote>
<p><i>[
-Sophia Antipolis:
+Post Summit:
]</i></p>
<blockquote>
<p>
-Since <tt>int</tt> promotes to <tt>double</tt>, and C99 doesn't have an <tt>int</tt>-based
-overload for <tt>pow</tt>, the C99 result is <tt>complex<double></tt>, see also C99
-7.22, see also library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>.
+"POSIX people will review the proposed NAD resolution at their upcoming NY
+meeting.
</p>
+
<p>
-Special note: ask P.J. Plauger.
+See the minutes at: <a href="http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009">http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009</a>.
</p>
-<blockquote>
-Looks fine.
-</blockquote>
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Strike this <tt>pow</tt> overload in 26.3.1 [complex.synopsis] and in 26.3.8 [complex.transcendentals]:
</p>
-<blockquote><pre><del>template<class T> complex<T> pow(const complex<T>& x, int y);</del>
-</pre></blockquote>
-
<hr>
-<h3><a name="845"></a>845. atomics cannot support aggregate initialization</h3>
-<p><b>Section:</b> 29.3 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-06-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types">active issues</a> in [atomics.types].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="888"></a>888. this_thread::yield too strong</h3>
+<p><b>Section:</b> 30.3.2 [thread.thread.this] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The atomic classes (and class templates) are required to support aggregate
-initialization (29.3.1 [atomics.types.integral]p2 / 29.3.2 [atomics.types.address]p1)
-yet also have user declared constructors, so cannot be aggregates.
-</p>
-<p>
-This problem might be solved with the introduction of the proposed
-initialization syntax at Antipolis, but the wording above should be altered.
-Either strike the sentence as redundant with new syntax, or refer to 'brace
-initialization'.
+I never thought I'd say this, but <tt>this_thread::yield</tt> seems to be too
+strong in specification. The issue is that some systems distinguish
+between yielding to another thread in the same process and yielding
+to another process. Given that the C++ standard only talks about
+a single program, one can infer that the specification allows yielding
+only to another thread within the same program. Posix has no
+facility for that behavior. Can you please file an issue to weaken
+the wording. Perhaps "Offers the operating system the opportunity
+to reschedule."
</p>
<p><i>[
-Jens adds:
+Post Summit:
]</i></p>
<blockquote>
-<p>
-Note that
-</p>
-<blockquote><pre>atomic_itype a1 = { 5 };
-</pre></blockquote>
-<p>
-would be aggregate-initialization syntax (now coming under the disguise
-of brace initialization), but would be ill-formed, because the corresponding
-constructor for atomic_itype is explicit. This works, though:
-</p>
-<blockquote><pre>atomic_itype a2 { 6 };
-</pre></blockquote>
-
+Recommend move to Tentatively Ready.
</blockquote>
+
<p><b>Proposed resolution:</b></p>
<p>
-In 29.3.1 [atomics.types.integral], strike the following sentence from paragraph 2:
+Change 30.3.2 [thread.thread.this]/3:
</p>
<blockquote>
-The atomic integral types shall have standard layout. They shall each have a trivial default constructor, a constexpr
-explicit value constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor.
-<del>They shall each support aggregate initialization syntax.</del>
+<pre>void this_thread::yield();
+</pre>
+<blockquote>
+<i>Effects:</i> Offers the <del>operating system</del> <ins>implementation</ins>
+the opportunity to <ins>re</ins>schedule.
+<del>another thread.</del>
</blockquote>
-
-<p><i>[
-2008-08-18, Lawrence adds:
-]</i></p>
-
-<blockquote>
-The syntactic compatibility of initialization with C is important.
-I suggest a different resolution; remove the explicit from the
-constructor. For the same reasons we can have implicit conversions,
-we can also have implicit constructors.
</blockquote>
<hr>
-<h3><a name="846"></a>846. No definition for constructor</h3>
-<p><b>Section:</b> 29.3 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-06-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types">active issues</a> in [atomics.types].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="889"></a>889. thread::id comparisons</h3>
+<p><b>Section:</b> 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-05-24</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.id">issues</a> in [thread.thread.id].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
-<p>
-The atomic classes and class templates (29.3.1 [atomics.types.integral] /
-29.3.2 [atomics.types.address]) have a constexpr
-constructor taking a value of the appropriate type for that atomic.
-However, neither clause provides semantics or a definition for this
-constructor. I'm not sure if the initialization is implied by use of
-constexpr keyword (which restricts the form of a constructor) but even if
-that is the case, I think it is worth spelling out explicitly as the
-inference would be far too subtle in that case.
-</p>
+<p><b>Addresses UK 324</b></p>
-<p><b>Proposed resolution:</b></p>
<p>
+The <tt>thread::id</tt> type supports the full set of comparison operators. This
+is substantially more than is required for the associative containers that
+justified them. Please place an issue against the threads library.
</p>
+<p><i>[
+San Francisco:
+]</i></p>
-
-
-<hr>
-<h3><a name="847"></a>847. string exception safety guarantees</h3>
-<p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Hervé Brönnimann <b>Date:</b> 2008-06-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
<p>
-In March, on comp.lang.c++.moderated, I asked what were the
-string exception safety guarantees are, because I cannot see
-*any* in the working paper, and any implementation I know offers
-the strong exception safety guarantee (string unchanged if a
-member throws exception). The closest the current draft comes to
-offering any guarantees is 21.3 [basic.string], para 3:
+Would depend on proposed extension to POSIX, or non-standard extension.
+What about hash? POSIX discussing op. POSIX not known to be considering
+support needed for hash, op.
</p>
-
-<blockquote>
-The class template <tt>basic_string</tt> conforms to the requirements
-for a Sequence Container (23.1.1), for a Reversible Container (23.1),
-and for an Allocator-aware container (91). The iterators supported by
-<tt>basic_string</tt> are random access iterators (24.1.5).
-</blockquote>
-
<p>
-However, the chapter 23 only says, on the topic of exceptions: 23.1 [container.requirements],
-para 10:
+Group expresses support for putting ids in both unordered and ordered containers.
</p>
+</blockquote>
+
+<p><i>[
+post San Francisco:
+]</i></p>
+
<blockquote>
<p>
-Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following
-additional requirements:
+Howard: It turns out the current working paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
+<i>already has</i> <tt>hash<thread::id></tt>
+(20.7 [function.objects], 20.7.17 [unord.hash]). We simply
+overlooked it in the meeting. It is a good thing we voted in favor of it
+(again). :-)
+</p>
+<p>
+Recommend NAD.
</p>
-<ul>
-<li>if an exception is thrown by...</li>
-</ul>
</blockquote>
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+Recommend to close as NAD. For POSIX, see if we need to add a function to
+convert <tt>pthread_t</tt> to integer.
+</blockquote>
+
+<p><i>[
+Post Summit, Alisdair adds:
+]</i></p>
+
+
+<blockquote>
<p>
-I take it as saying that this paragraph has *no* implication on
-<tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and
-this paragraph does not define a *requirement* of Sequence
-nor Reversible Container, just of the models defined in Clause 23.
-In addition, LWG Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a> proposes to remove 23.1 [container.requirements], para 3.
+The recommendation for LWG-889/UK-324 is NAD, already specified.
</p>
-
<p>
-Finally, the fact that no operation on Traits should throw
-exceptions has no bearing, except to suggest (since the only
-other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>)
-that the strong exception guarantee can be achieved.
+It is not clear to me that the specification is complete.
</p>
-
<p>
-The reaction in that group by Niels Dekker, Martin Sebor, and
-Bo Persson, was all that this would be worth an LWG issue.
+In particular, the synopsis of <tt><functional></tt> in 20.7 [function.objects] does not mention <tt>hash< thread::id
+></tt> nor <tt>hash< error_code ></tt>, although their
+existence is implied by 20.7.17 [unord.hash], p1.
</p>
-
<p>
-A related issue is that <tt>erase()</tt> does not throw. This should be
-stated somewhere (and again, I don't think that the 23.1 [container.requirements], para 1
-applies here).
+I am fairly uncomfortable putting the declaration for the
+<tt>thread_id</tt> specialization into <tt><functional></tt> as
+<tt>id</tt> is a nested class inside <tt>std::thread</tt>, so it implies
+that <tt><functional></tt> would require the definition of the
+<tt>thread</tt> class template in order to forward declared
+<tt>thread::id</tt> and form this specialization.
</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
<p>
-Add a blanket statement in 21.3.1 [string.require]:
+It seems better to me that the dependency goes the other way around
+(<tt><thread></tt> will more typically make use of
+<tt><functional></tt> than vice-versa) and the
+<tt>hash<thread::id></tt> specialization be declared in the
+<tt><thread></tt> header.
</p>
-
-<blockquote>
<p>
-- if any member function or operator of <tt>basic_string<charT, traits, Allocator></tt>
-throws, that function or operator has no effect.
+I think <tt>hash<error_code></tt> could go into either
+<tt><system_error></tt> or <tt><functional></tt> and have no
+immediate preference either way. However, it should clearly appear in
+the synopsis of one of these two.
</p>
<p>
-- no <tt>erase()</tt> or <tt>pop_back()</tt> function throws.
+Recommend moving 889 back to open, and tying in a reference to UK-324.
</p>
</blockquote>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Howard observes that <tt>thread::id</tt> need not be a nested class;
+it could be a <tt>typedef</tt> for a more visible type.
+</blockquote>
+
+<p><i>[
+2009-05-24 Alisdair adds:
+]</i></p>
+
+<blockquote>
+I do not believe this is correct. <tt>thread::id</tt> is explicitly documents as a
+nested class, rather than as an unspecified typedef analogous to an
+iterator. If the intent is that this is not implemented as a nested class
+(under the as-if freedoms) then this is a novel form of standardese.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-As far as I can tell, this is achieved by any implementation. If I made a
-mistake and it is not possible to offer this guarantee, then
-either state all the functions for which this is possible
-(certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>),
-or add paragraphs to Effects clauses wherever appropriate.
+Move to NAD.
</p>
<hr>
-<h3><a name="848"></a>848. missing <tt>std::hash</tt> specializations for <tt>std::bitset/std::vector<bool></tt></h3>
-<p><b>Section:</b> 20.6.16 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-06-05</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="890"></a>890. Improving <tt><system_error></tt> initialization</h3>
+<p><b>Section:</b> 19.5.1 [syserr.errcat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-09-14 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In the current working draft, <tt>std::hash<T></tt> is specialized for builtin
-types and a few other types. Bitsets seems like one that is missing from
-the list, not because it cannot not be done by the user, but because it
-is hard or impossible to write an efficient implementation that works on
-32bit/64bit chunks at a time. For example, <tt>std::bitset</tt> is too much
-encapsulated in this respect.
+The <tt>static const error_category</tt> objects <tt>generic_category</tt> and
+<tt>system_category</tt> in header <tt><system_error></tt> are currently declared:
</p>
+<blockquote><pre>const error_category& get_generic_category();
+const error_category& get_system_category();
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following to the synopsis in 20.6 [function.objects]/2:
-</p>
-
-<blockquote><pre>template<class Allocator> struct hash<std::vector<bool,Allocator>>;
-template<size_t N> struct hash<std::bitset<N>>;
+static const error_category& generic_category = get_generic_category();
+static const error_category& system_category = get_system_category();
</pre></blockquote>
<p>
-Modify the last sentence of 20.6.16 [unord.hash]/1 to end with:
+This formulation has several problems:
</p>
-<blockquote>
-... and <tt>std::string</tt>, <tt>std::u16string</tt>, <tt>std::u32string</tt>, <tt>std::wstring</tt>,
-<tt>std::error_code</tt>, <tt>std::thread::id</tt>, <tt>std::bitset</tt>, <tt>and std::vector<bool></tt>.
-</blockquote>
-
+<ul>
+<li>
+Implementation details are exposed, since initialization is specified in
+the interface. This over-constrains implementations without offsetting
+user benefits. The form of initialization specified may be less than
+maximally efficient on some platforms.
+</li>
+<li>
+Use of the objects is more expensive in terms of number of machine level
+instructions. See <i>Implementation experience</i> below.
+</li>
+<li>
+Depending on the compiler, some cost may be incurred by each translation unit
+that includes the header, even if the objects are not used. This is a
+common scenario in user code, since the header is included by other
+standard library headers. It should be mentioned that at least one
+compilers is able to optimize this cost away, however.
+</li>
+</ul>
+<p>
+IO streams uses a somewhat different formulation for iostream_category, but
+still suffer much the same problems.
+</p>
+<p>
+The original plan was to eliminate these problems by applying the C++0x
+<tt>constexpr</tt> feature. See LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>. However, that approach turned out
+to be unimplementable, since it would require a <tt>constexpr</tt> object of a
+class with virtual functions, and that is not allowed by the core
+language.
+</p>
+<p>
+The proposed resolution was developed as an alternative. It mitigates the above
+problems by removing initialization from the visible interface, allowing
+implementations flexibility.
+</p>
+<p>
+<b>Implementation experience:</b>
+</p>
-<hr>
-<h3><a name="849"></a>849. missing type traits to compute root class and derived class of types in a class hierachy</h3>
-<p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-06-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-The type traits library contains various traits to dealt with
-polymorphic types, e.g. <tt>std::has_virtual_destructor</tt>, <tt>std::is_polymorphic</tt>
-and <tt>std::is_base_of</tt>. However, there is no way to compute the unique
-public base class of a type if such one exists. Such a trait could be
-very useful if one needs to instantiate a specialization made for the
-root class whenever a derived class is passed as parameter. For example,
-imagine that you wanted to specialize <tt>std::hash</tt> for a class
-hierarchy---instead of specializing each class, you could specialize the
-<tt>std::hash<root_class></tt> and provide a partial specialization that worked
-for all derived classes.
+Prototype implementations of the current WP interface and proposed
+resolution interface were tested with recent Codegear, GCC, Intel, and Microsoft
+compilers on Windows. The code generated by the Microsoft compiler was studied
+at length; the WP and proposal versions generated very similar code. For both versions
+the compiler did make use of static
+initialization; apparently the compiler applied an implicit <tt>constexpr</tt>
+where useful, even in cases where <tt>constexpr</tt> would not be permitted by
+the language!
</p>
<p>
-This ability---to specify operations in terms of their equivalent in the
-root class---can be done with e.g. normal functions, but there is,
-AFAIK, no way to do it for class templates. Being able to access
-compile-time information about the type-hierachy can be very powerful,
-and I therefore also suggest traits that computes the directly derived
-class whenever that is possible.
+<b>Acknowledgements:</b>
</p>
<p>
-If the computation can not be done, the traits should fall back on an
-identity transformation. I expect this gives the best overall usability.
+Martin Sebor, Chris Kohlhoff, and John Lakos provided useful ideas and comments on initialization issues.
</p>
+<p><i>[
+San Francisco:
+]</i></p>
+
-<p><b>Proposed resolution:</b></p>
+<blockquote>
<p>
-Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations":
+Martin: prefers not to create more file-scope static objects, and would
+like to see <tt>get_*</tt> functions instead.
</p>
+</blockquote>
+
+
+<p><i>[Pre-Summit:]</i></p>
+
+<blockquote>
-<blockquote><pre>template< class T > struct direct_base_class;
-template< class T > struct direct_derived_class;
-template< class T > struct root_base_class;
-</pre></blockquote>
<p>
-Add three new entries to table 51 (20.5.7 [meta.trans.other]) with the following content
+Beman: The proposed resolution has been reworked to remove the file-scope
+static objects, per Martin's suggestions. The <tt>get_</tt> prefix has been
+eliminated from the function names as no longer necessary and to conform with
+standard library naming practice.
</p>
-<blockquote>
-<table border="1">
-<tbody><tr>
-<th>Template</th><th>Condition</th><th>Comments</th>
-</tr>
-<tr>
-<td><tt>template< class T > struct direct_base_class;</tt></td>
-<td><tt>T</tt> shall be a complete type.</td>
-<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous direct base class of <tt>T</tt>.
-If no such type exists, the member typedef <tt>type</tt> shall equal <tt>T</tt>.</td>
-</tr>
-<tr>
-<td><tt>template< class T > struct direct_derived_class;</tt></td>
-<td><tt>T</tt> shall be a complete type.</td>
-<td>The member typedef <tt>type</tt> shall equal the unambiguous type which has <tt>T</tt>
-as an accessible unambiguous direct base class. If no such type exists, the member typedef
-<tt>type</tt> shall equal <tt>T</tt>.</td>
-</tr>
-<tr>
-<td><tt>template< class T > struct root_base_class;</tt></td>
-<td><tt>T</tt> shall be a complete type.</td>
-<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous most indirect base class of
-<tt>T</tt>. If no such type exists, the member typedef type shall equal <tt>T</tt>.</td>
-</tr>
-</tbody></table>
</blockquote>
+<p><i>[
+Post Summit:
+]</i></p>
+<blockquote>
+Agreement that this is wise and essential, text provided works and has
+been implemented. Seems to be widespread consensus. Move to Tentative Ready.
+</blockquote>
-<hr>
-<h3><a name="850"></a>850. Should <tt>shrink_to_fit</tt> apply to <tt>std::deque</tt>?</h3>
-<p><b>Section:</b> 23.2.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-06-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#deque.capacity">active issues</a> in [deque.capacity].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
+
+<p>Change 17.6.4.12 [value.error.codes] Value of error codes as indicated:</p>
+<blockquote>
+ <p>Certain functions in the C++ standard library report errors via a
+ <tt>std::error_code</tt> (19.4.2.2) object. That object's <tt>category()</tt> member shall
+ return <del>a reference to</del> <code>std::system_category</code><tt><ins><code>()</code></ins></tt> for errors originating from the
+ operating system, or a reference to an implementation-defined error_category
+ object for errors originating elsewhere. The implementation shall define the
+ possible values of value() for each of these error categories. [<i>Example:</i> For
+ operating systems that are based on POSIX, implementations are encouraged to
+ define the <code>std::system_category</code><tt><ins><code>()</code></ins></tt> values as identical to the POSIX <tt>errno</tt> values,
+ with additional values as defined by the operating system's documentation.
+ Implementations for operating systems that are not based on POSIX are
+ encouraged to define values identical to the operating system's values. For
+ errors that do not originate from the operating system, the implementation may
+ provide enums for the associated values --<i>end example</i>]</p>
+</blockquote>
+
<p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a> added a <tt>shrink_to_fit</tt> function to <tt>std::vector</tt> and <tt>std::string</tt>.
-It did not yet deal with <tt>std::deque</tt>, because of the fundamental
-difference between <tt>std::deque</tt> and the other two container types. The
-need for <tt>std::deque</tt> may seem less evident, because one might think that
-for this container, the overhead is a small map, and some number of
-blocks that's bounded by a small constant.
+Change 19.5.1.1 [syserr.errcat.overview] Class <tt>error_category</tt> overview
+<tt>error_category</tt> synopsis as indicated:
</p>
+
+<blockquote>
+<pre>const error_category& <del>get_</del>generic_category();
+const error_category& <del>get_</del>system_category();
+
+<del>static storage-class-specifier const error_category& generic_category = get_generic_category();
+static storage-class-specifier const error_category& system_category = get_system_category();</del>
+</pre>
+</blockquote>
+
<p>
-The container overhead can in fact be arbitrarily large (i.e. is not
-necessarily O(N) where N is the number of elements currently held by the
-<tt>deque</tt>). As Bill Plauger noted in a reflector message, unless the map of
-block pointers is shrunk, it must hold at least maxN/B pointers where
-maxN is the maximum of N over the lifetime of the <tt>deque</tt> since its
-creation. This is independent of how the map is implemented
-(<tt>vector</tt>-like circular buffer and all), and maxN bears no relation to N,
-the number of elements it currently holds.
+Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
</p>
+
+<blockquote>
+<pre>const error_category& <del>get_</del>generic_category();
+</pre>
+
+<blockquote>
+
<p>
-Hervé Brönnimann reports a situation where a <tt>deque</tt> of requests grew very
-large due to some temporary backup (the front request hanging), and the
-map of the <tt>deque</tt> grew quite large before getting back to normal. Just
-to put some color on it, assuming a <tt>deque</tt> with 1K pointer elements in
-steady regime, that held, at some point in its lifetime, maxN=10M
-pointers, with one block holding 128 elements, the spine must be at
-least (maxN / 128), in that case 100K. In that case, shrink-to-fit
-would allow to reuse about 100K which would otherwise never be reclaimed
-in the lifetime of the <tt>deque</tt>.
+<i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.
</p>
+
<p>
-An added bonus would be that it *allows* implementations to hang on to
-empty blocks at the end (but does not care if they do or not). A
-<tt>shrink_to_fit</tt> would take care of both shrinks, and guarantee that at
-most O(B) space is used in addition to the storage to hold the N
-elements and the N/B block pointers.
+<i>Remarks:</i> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
+functions shall behave as specified for the class <tt>error_category</tt>. The
+object's <tt>name</tt> virtual function shall return a pointer to the string
+<tt>"GENERIC"</tt>.
</p>
+</blockquote>
+<pre>const error_category& <del>get_</del>system_category();
+</pre>
-<p><b>Proposed resolution:</b></p>
+<blockquote>
<p>
-To Class template deque 23.2.2 [deque] synopsis, add:
+<i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.
</p>
-<blockquote><pre>void shrink_to_fit();
-</pre></blockquote>
<p>
-To deque capacity 23.2.2.2 [deque.capacity], add:
+<i>Remarks:</i> 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>
-<blockquote><pre>void shrink_to_fit();
-</pre>
+<blockquote>
+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<ins>()</ins>)</tt>. Otherwise, the
+function shall return <tt>error_condition(ev, system_category<ins>()</ins>)</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>]
+</blockquote>
+</blockquote>
+
+</blockquote>
+<p>Change 19.5.2.3 [syserr.errcode.constructors] Class error_code constructors
+as indicated:</p>
+<blockquote>
+ <pre>error_code();</pre>
+ <blockquote>
+ <p><i>Effects:</i> Constructs an object of type error_code.</p>
+ <p><i>Postconditions:</i> <code>val_ == 0 </code>and <code>cat_ == &system_category</code><tt><ins>()</ins></tt>.</p>
+ </blockquote>
+</blockquote>
+<p>Change 19.5.2.4 [syserr.errcode.modifiers] Class error_code modifiers as
+indicated:</p>
+<blockquote>
+ <pre>void clear();</pre>
+ <blockquote>
+ <p>Postconditions: <code>value() == 0</code> and <code>category() ==
+ system_category</code><tt><ins>()</ins></tt>.</p>
+ </blockquote>
+</blockquote>
+<p>Change 19.5.2.6 [syserr.errcode.nonmembers] Class error_code non-member
+functions as indicated:</p>
+<blockquote>
+ <pre>error_code make_error_code(errc e);</pre>
+ <blockquote>
+ <p><i>Returns:</i> <code>error_code(static_cast<int>(e), generic_category</code><tt><ins>()</ins></tt><code>)</code>.</p>
+ </blockquote>
+</blockquote>
+<p>Change 19.5.3.3 [syserr.errcondition.constructors] Class error_condition
+constructors as indicated:</p>
+<blockquote>
+ <pre>error_condition();</pre>
+ <blockquote>
+ <p><i>Effects:</i> Constructs an object of type <code>error_condition</code>.</p>
+ <p><i>Postconditions:</i> <code>val_ == 0</code> and <code>cat_ == &generic_category</code><tt><ins>()</ins></tt>.</p>
+ </blockquote>
+</blockquote>
+<p>Change 19.5.3.4 [syserr.errcondition.modifiers] Class error_condition
+modifiers as indicated:</p>
<blockquote>
-<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce memory
-use. [<i>Note:</i> The request is non-binding to allow latitude for
-implementation-specific optimizations. -- <i>end note</i>]
+ <pre>void clear();</pre>
+ <blockquote>
+ <p><i>Postconditions:</i> <code>value() == 0</code> and <code>category() ==
+ generic_category</code><tt><ins>()</ins></tt>.</p>
+ </blockquote>
</blockquote>
+<p>Change 19.5.3.6 [syserr.errcondition.nonmembers] Class error_condition
+non-member functions as indicated:</p>
+<blockquote>
+ <pre>error_condition make_error_condition(errc e);</pre>
+ <blockquote>
+ <p><i>Returns:</i> <tt>error_condition(static_cast<int>(e), generic_category<ins>()</ins>)</tt>.</p>
+ </blockquote>
+</blockquote>
+ <p>Change 27.5 [iostreams.base] Iostreams base classes, Header <ios>
+ synopsis as indicated:</p>
+<blockquote>
+ <pre>concept_map ErrorCodeEnum<io_errc> { };
+error_code make_error_code(io_errc e);
+error_condition make_error_condition(io_errc e);
+<del>storage-class-specifier</del> const error_category& iostream_category<ins>()</ins>;</pre>
+</blockquote>
+<p>Change 27.5.2.1.1 [ios::failure] Class ios_base::failure, paragraph 2 as
+indicated:</p>
+<blockquote>
+<p>When throwing ios_base::failure exceptions, implementations should provide
+values of ec that identify the specific reason for the failure. [ Note: Errors
+arising from the operating system would typically be reported as <tt>
+system_category</tt><tt><ins>()</ins></tt> errors with an error value of the
+error number reported by the operating system. Errors arising from within the
+stream library would typically be reported as <tt>error_code(io_errc::stream,
+iostream_category<ins>()</ins>)</tt>. --end note ]</p>
+</blockquote>
+<p>Change 27.5.5.5 [error.reporting] Error reporting as indicated:</p>
+<blockquote>
+ <pre>error_code make_error_code(io_errc e);</pre>
+ <blockquote>
+ <p><i>Returns:</i> <code>error_code(static_cast<int>(e), iostream_category</code><ins>()</ins><code>)</code>.</p>
+ </blockquote>
+ <pre>error_condition make_error_condition(io_errc e);</pre>
+ <blockquote>
+ <p><i>Returns:</i> <code>error_condition(static_cast<int>(e),
+ iostream_category</code><ins>()</ins><code>)</code>.</p>
+ </blockquote>
+ <pre><del>storage-class-specifier</del> const error_category& iostream_category<ins>()</ins>;</pre>
+ <blockquote>
+ <del><p>The implementation shall initialize iostream_category. Its storage-class-specifier
+ may be static or extern. It is unspecified whether initialization is static
+ or dynamic (3.6.2). If initialization is dynamic, it shall occur before
+ completion of the dynamic initialization of the first translation unit
+ dynamically initialized that includes header <system_error>.</p></del>
+<p>
+<ins><i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.</ins>
+</p>
+<p><i>Remarks:</i> The object's default_error_condition and equivalent virtual functions shall
+behave as specified for the class error_category. The object's name virtual
+function shall return a pointer to the string "iostream".</p>
+ </blockquote>
</blockquote>
+
+
<hr>
-<h3><a name="851"></a>851. simplified array construction</h3>
-<p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Benjamin Kosnik <b>Date:</b> 2008-06-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<h3><a name="891"></a>891. std::thread, std::call_once issue</h3>
+<p><b>Section:</b> 30.3.1.2 [thread.thread.constr], 30.4.5.2 [thread.once.callonce] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-This is an issue that came up on the libstdc++ list, where a
-discrepency between "C" arrays and C++0x's <tt>std::array</tt> was pointed
-out.
+I notice that the vararg overloads of <tt>std::thread</tt> and <tt>std::call_once</tt>
+(N2723 30.3.1.2 [thread.thread.constr] and 30.4.5.2 [thread.once.callonce]) are no longer specified in terms of
+<tt>std::bind</tt>; instead, some of the <tt>std::bind</tt> wording has been inlined into
+the specification.
</p>
-
<p>
-In "C," this array usage is possible:
+There are two problems with this.
</p>
-
-<blockquote><pre>int ar[] = {1, 4, 6};
-</pre></blockquote>
-
<p>
-But for C++,
+First, the specification (and implementation) in terms of <tt>std::bind</tt> allows, for example:
</p>
-<blockquote><pre>std::array<int> a = { 1, 4, 6 }; // error
+<blockquote><pre>std::thread th( f, 1, std::bind( g ) );
</pre></blockquote>
<p>
-Instead, the second parameter of the <tt>array</tt> template must be
-explicit, like so:
+which executes <tt>f( 1, g() )</tt> in a thread. This can be useful. The
+"inlined" formulation changes it to execute <tt>f( 1, bind(g) )</tt> in a thread.
</p>
-
-<blockquote><pre>std::array<int, 3> a = { 1, 4, 6 };
-</pre></blockquote>
-
<p>
-Doug Gregor proposes the following solution, that assumes
-generalized initializer lists.
+Second, assuming that we don't want the above, the specification has copied the wording
</p>
-<blockquote><pre>template<typename T, typename... Args>
-inline array<T, sizeof...(Args)>
-make_array(Args&&... args)
-{ return { std::forward<Args>(args)... }; }
-</pre></blockquote>
+<blockquote>
+<tt>INVOKE(func, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid
+expression for some values <tt>w1, w2, ..., wN</tt>
+</blockquote>
<p>
-Then, the way to build an <tt>array</tt> from a list of unknown size is:
+but this is not needed since we know that our argument list is args; it should simply be
</p>
-<blockquote><pre>auto a = make_array<T>(1, 4, 6);
-</pre></blockquote>
+<blockquote>
+<tt>INVOKE(func, args...)</tt> (20.6.2) shall be a valid expression
+</blockquote>
+<p><i>[
+Summit:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to the <tt>array</tt> synopis in 23.2 [sequences]:
-</p>
+<blockquote>
+Move to open.
+</blockquote>
-<blockquote><pre>template<typename T, typename... Args>
- requires Convertible<Args, T>...
- array<T, sizeof...(Args)>
- make_array(Args&&... args);
-</pre></blockquote>
+<p><i>[
+Post Summit Anthony provided proposed wording.
+]</i></p>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-Append after 23.2.1.6 [array.tuple] Tuple interface to class template <tt>array</tt> the
-following new section.
+Change paragraph 4 of 30.3.1.2 [thread.thread.constr] to:
</p>
<blockquote>
+<pre>template <class F> explicit thread(F f);
+template <class F, class ...Args> thread(F&& f, Args&&... args);
+</pre>
+<blockquote>
+-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt>
+shall be <tt>CopyConstructible</tt> if an lvalue and otherwise
+<tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(f, <del>w1, w2, ..., wN</del> <ins>args...</ins>)</tt>
+(20.6.2) shall be a valid expression<del> for some values <i>w1, w2, ...,
+wN</i>, where <tt>N == sizeof...(Args)</tt></del>.
+</blockquote>
+</blockquote>
+
<p>
-23.2.1.7 Convenience interface to class template <tt>array</tt> [array.tuple]
+Change paragraph 1 of 30.4.5.2 [thread.once.callonce] to:
</p>
-<pre>template<typename T, typename... Args>
- requires Convertible<Args, T>...
- array<T, sizeof...(Args)>
- make_array(Args&&... args);
+<blockquote><pre>template<class Callable, class ...Args>
+ void call_once(once_flag& flag, Callable func, Args&&... args);
</pre>
-
<blockquote>
-<p>
-<i>Returns:</i> <tt>{std::forward<Args>(args)...}</tt>
-</p>
+-1- <i>Requires:</i> The template parameters <tt>Callable></tt> and each
+<tt>Ti</tt> in <tt>Args</tt> shall be <tt>CopyConstructible</tt> if an
+lvalue and otherwise <tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(func,
+<del>w1, w2, ..., wN</del> <ins>args...</ins>)</tt> (20.6.2) shall be a
+valid expression<del> for some values <i>w1, w2, ..., wN</i>, where
+<tt>N == sizeof...(Args)</tt></del>.
</blockquote>
</blockquote>
<hr>
-<h3><a name="852"></a>852. unordered containers <tt>begin(n)</tt> mistakenly <tt>const</tt></h3>
-<p><b>Section:</b> 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Robert Klarer <b>Date:</b> 2008-06-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
+<h3><a name="893"></a>893. std::mutex issue</h3>
+<p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.class">active issues</a> in [thread.mutex.class].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a></p>
<p><b>Discussion:</b></p>
<p>
-In 3 of the four unordered containers the local <tt>begin</tt> member is mistakenly declared <tt>const</tt>:
+30.4.1.1 [thread.mutex.class]/27 (in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
+says that the behavior is undefined if:
+</p>
+<ul>
+<li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or
+<tt>try_lock()</tt> on that object</li>
+</ul>
+<p>
+I don't believe that this is right. Calling <tt>lock()</tt> or <tt>try_lock()</tt> on a
+locked <tt>mutex</tt> is well defined in the general case. <tt>try_lock()</tt> is required
+to fail and return <tt>false</tt>. <tt>lock()</tt> is required to either throw an
+exception (and is allowed to do so if it detects deadlock) or to block
+until the <tt>mutex</tt> is free. These general requirements apply regardless of
+the current owner of the <tt>mutex</tt>; they should apply even if it's owned by
+the current thread.
+</p>
+<p>
+Making double <tt>lock()</tt> undefined behavior probably can be justified (even
+though I'd still disagree with the justification), but <tt>try_lock()</tt> on a
+locked <tt>mutex</tt> must fail.
</p>
-<blockquote><pre>local_iterator begin(size_type n) const;
-</pre></blockquote>
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+<p>
+Move to open. Proposed resolution:
+</p>
+<ul>
+<li>
+In 30.4.1 [thread.mutex.requirements] paragraph 12, change the error
+condition for <tt>resource_deadlock_would_occur</tt> to: "if the implementation
+detects that a deadlock would occur"
+</li>
+<li>
+Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex object
+calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or"
+</li>
+</ul>
+</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Change the synopsis in 23.4.1 [unord.map], 23.4.2 [unord.multimap], and 23.4.4 [unord.multiset]:
+In 30.4.1 [thread.mutex.requirements] paragraph 12 change:
</p>
-<blockquote><pre>local_iterator begin(size_type n)<del> const</del>;
-</pre></blockquote>
+<blockquote>
+<ul>
+<li>...</li>
+<li>
+<tt>resource_deadlock_would_occur</tt> -- if the <del>current thread already owns the mutex and is able
+to detect it</del> <ins>implementation detects that a deadlock would occur</ins>.
+</li>
+<li>...</li>
+</ul>
+</blockquote>
+
+<p>
+Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2:
+</p>
+<blockquote>
+<p>
+-3- The behavior of a program is undefined if:
+</p>
+<ul>
+<li>...</li>
+<li>
+<del>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</del>
+</li>
+<li>...</li>
+</ul>
+</blockquote>
+
+
<hr>
-<h3><a name="853"></a>853. <tt>to_string</tt> needs updating with <tt>zero</tt> and <tt>one</tt></h3>
-<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="895"></a>895. "Requires:" on std::string::at et al</h3>
+<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> James Dennett <b>Opened:</b> 2008-09-16 <b>Last modified:</b> 2009-03-11</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</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>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a> adds defaulted arguments to the <tt>to_string</tt> member, but neglects to update
-the three newer <tt>to_string</tt> overloads.
+Per discussion, we need an issue open to cover looking at "Requires"
+clauses which are not constraints on user code, such as that on
+<tt>std::basic_string::at</tt>.
</p>
<p><b>Proposed resolution:</b></p>
<p>
-Change the synopsis in 23.3.5 [template.bitset], and the signatures in 23.3.5.2 [bitset.members] to:
</p>
-<blockquote><pre>template <class charT, class traits>
- basic_string<charT, traits, allocator<charT> > to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
-template <class charT>
- basic_string<charT, char_traits<charT>, allocator<charT> > to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
-basic_string<char, char_traits<char>, allocator<char> > to_string(<ins>char zero = '0', char one = '1'</ins>) const;
-</pre></blockquote>
-
<hr>
-<h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3>
-<p><b>Section:</b> 20.7.11.1.1 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="896"></a>896. Library thread safety issue</h3>
+<p><b>Section:</b> 20.8.13.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-09-16 <b>Last modified:</b> 2008-09-25</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template.
-</p>
-<p>
-Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor<T></tt>;
-the latter should also become a concept.
+It is unclear whether <tt>shared_ptr</tt> is thread-safe in the sense that
+multiple threads may simultaneously copy a <tt>shared_ptr</tt>. However this
+is a critical piece of information for the client, and it has significant
+impact on usability for many applications. (Detlef Vollman thinks it
+is currently clear that it is not thread-safe. Hans Boehm thinks
+it currently requires thread safety, since the <tt>use_count</tt> is not an
+explicit field, and constructors and assignment take a const reference
+to an existing <tt>shared_ptr</tt>.)
</p>
+
<p>
-Rules out cross-casting.
+Pro thread-safety:
</p>
<p>
-The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter.
+Many multi-threaded usages are impossible. A thread-safe version can
+be used to destroy an object when the last thread drops it, something
+that is often required, and for which we have no other easy mechanism.
</p>
-
-
-<p><b>Proposed resolution:</b></p>
<p>
-Change 20.7.11.1.1 [unique.ptr.dltr.dflt]:
+Against thread-safety:
</p>
-
-<blockquote><pre>namespace std {
- template <class T> struct default_delete {
- default_delete();
- template <class U>
- <ins>requires Convertible<U*, T*> && HasVirtualDestructor<T></ins>
- default_delete(const default_delete<U>&);
- void operator()(T*) const;
- };
-}
-</pre></blockquote>
-
<p>
-...
+The thread-safe version is well-known to be far more expensive, even
+if used by a single thread. Many applications, including all single-threaded
+ones, do not care.
</p>
-<blockquote><pre>template <class U>
- <ins>requires Convertible<U*, T*> && HasVirtualDestructor<T></ins>
- default_delete(const default_delete<U>& other);
-</pre></blockquote>
-
-
-
-
+<p><i>[
+San Francisco:
+]</i></p>
-<hr>
-<h3><a name="855"></a>855. capacity() and reserve() for deque?</h3>
-<p><b>Section:</b> 23.2.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Hervé Brönnimann <b>Date:</b> 2008-06-11</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#deque.capacity">active issues</a> in [deque.capacity].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The main point is that <tt>capacity</tt> can be viewed as a mechanism to
-guarantee the validity of <tt>iterators</tt> when only <tt>push_back/pop_back</tt>
-operations are used. For <tt>vector</tt>, this goes with reallocation. For
-<tt>deque</tt>, this is a bit more subtle: <tt>capacity()</tt> of a <tt>deque</tt> may shrink,
-whereas that of <tt>vector</tt> doesn't. In a circular buffer impl. of the
-map, as Howard did, there is very similar notion of capacity: as long
-as <tt>size()</tt> is less than <tt>B * (</tt>total size of the map <tt>- 2)</tt>, it is
-guaranteed that no <tt>iterator</tt> is invalidated after any number of
-<tt>push_front/back</tt> and <tt>pop_front/back</tt> operations. But this does not
-hold for other implementations.
-</p>
+<blockquote>
<p>
-Still, I believe, <tt>capacity()</tt> can be defined by <tt>size() +</tt> how many
-<tt>push_front/back</tt> minus <tt>pop_front/back</tt> that can be performed before
-terators are invalidated. In a classical impl., <tt>capacity() = size()
-+ </tt> the min distance to either "physical" end of the deque (i.e.,
-counting the empty space in the last block plus all the blocks until
-the end of the map of block pointers). In Howard's circular buffer
-impl., <tt>capacity() = B * (</tt>total size of the map <tt>- 2)</tt> still works with
-this definition, even though the guarantee could be made stronger.
+Beman: this is a complicated issue, and would like to move this to Open
+and await comment from Peter Dimov; we need very careful and complete
+rationale for any decision we make; let's go slow
</p>
<p>
-A simple picture of a deque:
+Detlef: I think that <tt>shared_ptr</tt> should not be thread-safe.
</p>
-<blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z
-</pre></blockquote>
<p>
-(A,Z mark the beginning/end, | the block boundaries, F=front, B=back,
-and - are uninitialized, + are initialized)
-In that picture: <tt>capacity = size() + min(dist(A,F),dist(B,Z)) = min
-(dist(A,B),dist(F,Z))</tt>.
+Hans: When you create a thread with a lambda, it in some cases makes it
+very difficult for the lambda to reference anything in the heap. It's
+currently ambiguous as to whether you can use a <tt>shared_ptr</tt> to get at an
+object.
</p>
<p>
-<tt>Reserve(n)</tt> can grow the map of pointers and add possibly a number of
-empty blocks to it, in order to guarantee that the next <tt>n-size()
-push_back/push_front</tt> operations will not invalidate iterators, and
-also will not allocate (i.e. cannot throw). The second guarantee is
-not essential and can be left as a QoI. I know well enough existing
-implementations of <tt>deque</tt> (sgi/stl, roguewave, stlport, and
-dinkumware) to know that either can be implemented with no change to
-the existing class layout and code, and only a few modifications if
-blocks are pre-allocated (instead of always allocating a new block,
-check if the next entry in the map of block pointers is not zero).
+Leave in Open. Detlef will submit an alternative proposed resolution
+that makes <tt>shared_ptr</tt> explicitly unsafe.
</p>
<p>
-Due to the difference with <tt>vector</tt>, wording is crucial. Here's a
-proposed wording to make things concrete; I tried to be reasonably
-careful but please double-check me:
+A third option is to support both threadsafe and non-safe share_ptrs,
+and to let the programmer decide which behavior they want.
</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
<p>
-Add new signatures to synopsis in 23.2.2 [deque]:
+Beman: Peter, do you support the PR?
</p>
-<blockquote><pre>size_type capacity() const;
-bool reserve(size_type n);
-</pre></blockquote>
-
<p>
-Add new signatures to 23.2.2.2 [deque.capacity]:
+Peter:
</p>
-
-<blockquote>
-<pre>size_type capacity() const;
-</pre>
<blockquote>
<p>
-1 <i>Returns:</i> An upper bound on <tt>n + max(n_f - m_f, n_b - m_b)</tt> such
-that, for any sequence of <tt>n_f push_front</tt>, <tt>m_f pop_front</tt>, <tt>n_b
-push_back</tt>, and <tt>m_b pop_back</tt> operations, interleaved in any order,
-starting with the current <tt>deque</tt> of size <tt>n</tt>, the <tt>deque</tt> does not
-invalidate any of its iterators except to the erased elements.
+Yes, I support the proposed resolution, and I certainly oppose any
+attempts to <tt>make shared_ptr</tt> thread-unsafe.
</p>
<p>
-2 <i>Remarks:</i> Unlike a <tt>vector</tt>'s capacity, the capacity of a <tt>deque</tt> can
-decrease after a sequence of insertions at both ends, even if none of
-the operations caused the <tt>deque</tt> to invalidate any of its iterators
-except to the erased elements.
+I'd mildly prefer if
</p>
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>bool reserve(size_type n);
-</pre>
<blockquote>
+[<i>Note:</i> This is true in spite of that fact that such functions often
+modify <tt>use_count()</tt> <i>--end note</i>]
+</blockquote>
<p>
-2 <i>Effects:</i> A directive that informs a <tt>deque</tt> of a planned sequence of
-<tt>push_front</tt>, <tt>pop_front</tt>, <tt>push_back</tt>, and <tt>pop_back</tt> operations, so that it
-can manage iterator invalidation accordingly. After <tt>reserve()</tt>,
-<tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt> if this
-operation returns <tt>true</tt>; and equal to the previous value of <tt>capacity()</tt>
-otherwise. If an exception is thrown, there are no effects.
-</p>
-<p>
-3 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this
-operation, and false otherwise.
+is changed to
</p>
+<blockquote>
+[<i>Note:</i> This is true in spite of that fact that such functions often
+cause a change in <tt>use_count()</tt> <i>--end note</i>]
+</blockquote>
<p>
-4 <i>Complexity:</i> It does not change the size of the sequence and takes
-at most linear time in <tt>n</tt>.
+(or something along these lines) to emphasise that <tt>use_count()</tt> is not,
+conceptually, a variable, but a return value.
</p>
+</blockquote>
+
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-5 <i>Throws:</i> <tt>length_error</tt> if <tt>n > max_size()</tt>.
+Make it explicitly thread-safe, in this weak sense, as I believe was intended:
</p>
<p>
-6 <i>Remarks:</i> It is guaranteed that no invalidation takes place during a
-sequence of <tt>insert</tt> or <tt>erase</tt> operations at either end that happens
-after a call to <tt>reserve()</tt> except to the erased elements, until the
-time when an insertion would make <tt>max(n_f-m_f, n_b-m_b)</tt> larger than
-<tt>capacity()</tt>, where <tt>n_f</tt> is the number of <tt>push_front</tt>, <tt>m_f</tt> of <tt>pop_front</tt>,
-<tt>n_b</tt> of <tt>push_back</tt>, and <tt>m_b</tt> of <tt>pop_back</tt> operations since the call to
-<tt>reserve()</tt>.
+Insert in 20.8.13.2 [util.smartptr.shared], before p5:
</p>
+<blockquote>
<p>
-7 An implementation is free to pre-allocate buffers so as to
-offer the additional guarantee that no exception will be thrown
-during such a sequence other than by the element constructors.
+For purposes of determining the presence of a data race,
+member functions do not modify <tt>const shared_ptr</tt> and
+const <tt>weak_ptr</tt> arguments, nor any objects they
+refer to. [<i>Note:</i> This is true in spite of that fact that such functions often
+cause a change in <tt>use_count()</tt> <i>--end note</i>]
</p>
</blockquote>
-</blockquote>
-
<p>
-And 23.2.2.3 [deque.modifiers] para 1, can be enhanced:
+On looking at the text, I'm not sure we need a similar disclaimer
+anywhere else, since nothing else has the problem with the modified
+<tt>use_count()</tt>. I think Howard arrived at a similar conclusion.
</p>
-<blockquote>
-1 <i>Effects:</i> An insertion in the middle of the deque invalidates all the iterators and references to elements of the
-deque. An insertion at either end of the deque invalidates all the iterators to the deque,
-<ins>unless provisions have been made with reserve,</ins>
-but has no effect on the validity of references to elements of the deque.
-</blockquote>
-
<hr>
-<h3><a name="856"></a>856. Removal of <tt>aligned_union</tt></h3>
-<p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-06-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="897"></a>897. Forward_list issues... Part 2</h3>
+<p><b>Section:</b> 23.3.3.4 [forwardlist.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-09-22 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-With the arrival of extended unions
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf">N2544</a>),
-there is no
-known use of <tt>aligned_union</tt> that couldn't be handled by
-the "extended unions" core-language facility.
+This issue was split off from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a> at the request of the LWG.
</p>
+<p><i>[
+San Francisco:
+]</i></p>
+
-<p><b>Proposed resolution:</b></p>
+<blockquote>
<p>
-Remove the following signature from 20.5.2 [meta.type.synop]:
+This issue is more complicated than it looks.
</p>
-<blockquote><pre>template <std::size_t Len, class... Types> struct aligned_union;
-</pre></blockquote>
-
<p>
-Remove the second row from table 51 in 20.5.7 [meta.trans.other],
-starting with:
+paragraph 47: replace each <tt>(first, last) with (first, last]</tt>
</p>
-
-<blockquote><pre>template <std::size_t Len,
-class... Types>
-struct aligned_union;
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3>
-<p><b>Section:</b> 30.4.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-06-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so
-obscure that even the class' designer can't deduce it correctly. Several
-people have independently stumbled on this issue.
+add a statement after paragraph 48 that complexity is O(1)
</p>
<p>
-It might be simpler to change the return type to a scoped enum:
+remove the complexity statement from the first overload of splice_after
</p>
-<blockquote><pre>enum class timeout { not_reached, reached };
-</pre></blockquote>
+<p>
+We may have the same problems with other modifiers, like erase_after.
+Should it require that all iterators in the range (position, last] be
+dereferenceable?
+</p>
+</blockquote>
<p>
-That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be:
+There are actually 3 issues here:
</p>
-<blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached )
- throw time_out();
+<ol>
+<li>
+<p>
+What value should <tt>erase_after</tt> return? With <tt>list</tt>, code often
+looks like:
+</p>
+<blockquote><pre>for (auto i = l.begin(); i != l.end();)
+{
+ // inspect *i and decide if you want to erase it
+ // ...
+ if (I want to erase *i)
+ i = l.erase(i);
+ else
+ ++i;
+}
</pre></blockquote>
-
-<p><i>[
-Beman to supply exact wording.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="858"></a>858. Wording for Minimal Support for Garbage Collection</h3>
-<p><b>Section:</b> X [garbage.collection] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2008-06-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-The first sentence of the Effects clause for <tt>undeclare_reachable</tt> seems
-to be missing some words. I can't parse
+I.e. the iterator returned from <tt>erase</tt> is useful for setting up the
+logic for operating on the next element. For <tt>forward_list</tt> this might
+look something like:
</p>
-<blockquote>
-... for all non-null <tt>p</tt> referencing the argument is no longer declared reachable...
-</blockquote>
+<blockquote><pre>auto i = fl.before_begin();
+auto ip1 = i;
+for (++ip1; ip1 != fl.end(); ++ip1)
+{
+ // inspect *(i+1) and decide if you want to erase it
+ // ...
+ if (I want to erase *(i+1))
+ i = fl.erase_after(i);
+ else
+ ++i;
+ ip1 = i;
+}
+</pre></blockquote>
<p>
-I take it the intent is that <tt>undeclare_reachable</tt> should be called only
-when there has been a corresponding call to <tt>declare_reachable</tt>. In
-particular, although the wording seems to allow it, I assume that code
-shouldn't call <tt>declare_reachable</tt> once then call <tt>undeclare_reachable</tt>
-twice.
+In the above example code, it is convenient if <tt>erase_after</tt> returns
+the element <i>prior</i> to the erased element (range) instead of the element
+<i>after</i> the erase element (range).
</p>
<p>
-I don't know what "shall be live" in the Requires clause means.
+Existing practice:
</p>
+<ul>
+<li>SGI slist returns an iterator referencing the element <i>after</i> the erased range.</li>
+<li>CodeWarrior slist returns an iterator referencing the element <i>before</i> the erased range.</li>
+</ul>
<p>
-In the final Note for <tt>undeclare_reachable</tt>, what does "cannot be
-deallocated" mean? Is this different from "will not be able to collect"?
+There is not a strong technical argument for either solution over the other.
</p>
+</li>
+<li>
<p>
-For the wording on nesting of <tt>declare_reachable</tt> and
-<tt>undeclare_reachable</tt>, the words for locking and unlocking recursive
-mutexes probably are a good model.
+With all other containers, operations always work on the range
+<tt>[first, last)</tt> and/or <i>prior to</i> the given <tt>position</tt>.
</p>
-
-
-<p><b>Proposed resolution:</b></p>
<p>
+With <tt>forward_list</tt>, operations sometimes work on the range
+<tt>(first, last]</tt> and/or <i>after</i> the given <tt>position</tt>.
</p>
-
-
-
-
-
-<hr>
-<h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3>
-<p><b>Section:</b> X [datetime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2008-06-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a>
-says that there is a class named <tt>monotonic_clock</tt>. It also says that this
-name may be a synonym for <tt>system_clock</tt>, and that it's conditionally
-supported. So the actual requirement is that it can be monotonic or not,
-and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at
-all (since it's conditionally supported). Okay, maybe too much
-flexibility, but so be it.
+This is simply due to the fact that in order to operate on
+<tt>*first</tt> (with <tt>forward_list</tt>) one needs access to
+<tt>*(first-1)</tt>. And that's not practical with
+<tt>forward_list</tt>. So the operating range needs to start with <tt>(first</tt>,
+not <tt>[first</tt> (as the current working paper says).
</p>
<p>
-A problem comes up in the threading specification, where several
-variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the
-meaning of an effects clause that says
+Additionally, if one is interested in splicing the range <tt>(first, last)</tt>,
+then (with <tt>forward_list</tt>), one needs practical (constant time) access to
+<tt>*(last-1)</tt> so that one can set the <i>next</i> field in this node to
+the proper value. As this is not possible with <tt>forward_list</tt>, one must
+specify the last element of interest instead of one past the last element of
+interest. The syntax for doing this is to pass <tt>(first, last]</tt> instead
+of <tt>(first, last)</tt>.
</p>
-
-<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
+<p>
+With <tt>erase_after</tt> we have a choice of either erasing the range
+<tt>(first, last]</tt> <em>or</em> <tt>(first, last)</tt>. Choosing the latter
+enables:
+</p>
+<blockquote><pre>x.erase_after(pos, x.end());
</pre></blockquote>
<p>
-when <tt>monotonic_clock</tt> is not required to exist?
+With the former, the above statement is inconvenient or expensive due to the lack
+of constant time access to <tt>x.end()-1</tt>. However we could introduce:
</p>
+<blockquote><pre>iterator erase_to_end(const_iterator position);
+</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
+to compensate.
</p>
+<p>
+The advantage of the former (<tt>(first, last]</tt>) for <tt>erase_after</tt>
+is a consistency with <tt>splice_after</tt> which uses <tt>(first, last]</tt>
+as the specified range. But this either requires the addition of <tt>erase_to_end</tt>
+or giving up such functionality.
+</p>
+</li>
+<li>
+As stated in the discussion of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>, and reienforced by point 2 above,
+a <tt>splice_after</tt> should work on the source range <tt>(first, last]</tt>
+if the operation is to be <i>Ο</i>(1). When splicing an entire list <tt>x</tt> the
+algorithm needs <tt>(x.before_begin(), x.end()-1]</tt>. Unfortunately <tt>x.end()-1</tt>
+is not available in constant time unless we specify that it must be. In order to
+make <tt>x.end()-1</tt> available in constant time, the implementation would have
+to dedicate a pointer to it. I believe the design of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm">N2543</a>
+intended a nominal overhead of <tt>foward_list</tt> of 1 pointer. Thus splicing
+one <i>entire</i> <tt>forward_list</tt> into another can not be <i>Ο</i>(1).
+</li>
+</ol>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
-<hr>
-<h3><a name="860"></a>860. Floating-Point State</h3>
-<p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
<p>
-There are a number of functions that affect the floating point state.
-These function need to be thread-safe, but I'm unsure of the right
-approach in the standard, as we inherit them from C.
+We agree with the proposed resolution.
+</p>
+<p>
+Move to Review.
</p>
+</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
+Wording below assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a> is accepted, but this issue is
+independent of that issue.
</p>
-
-
-
-
-<hr>
-<h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-06-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container
-member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>:
+Change 23.3.3.4 [forwardlist.modifiers]:
</p>
<blockquote>
-<tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() &&
-equal(a.begin(), a.end(), b.begin()</tt>
-</blockquote>
-
+<pre>iterator erase_after(const_iterator position);
+</pre>
+<blockquote>
<p>
-The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function
-by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic.
+<i>Requires:</i> The iterator following <tt>position</tt> is dereferenceable.
</p>
<p>
-Other parts of the (sequence) container requirements do also depend on
-<tt>size()</tt>, e.g. <tt>empty()</tt>
-or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing
-<tt>EqualityComparable</tt> specification,
-because of the special design choices of <tt>forward_list</tt>.
+<i>Effects:</i> Erases the element pointed to by the iterator following <tt>position</tt>.
</p>
<p>
-I propose to apply one of the following resolutions, which are described as:
+<i>Returns:</i> <del>An iterator pointing to the element following the one that was erased, or <tt>end()</tt> if no such
+element exists</del>
+<ins>An iterator equal to <tt>position</tt></ins>.
</p>
+</blockquote>
-<ol type="A">
-<li>
-Provide a definition, which is optimal for this special container without
-previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt>
-with the corresponding container ranges and instead uses a special
-<tt>equals</tt> implementation which takes two container ranges instead of 1 1/2.
-</li>
-<li>
-The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced
-by <tt>distance</tt> with corresponding performance disadvantages.
-</li>
-</ol>
+
+<pre>iterator erase_after(const_iterator position, <ins>const_</ins>iterator last);
+</pre>
+<blockquote>
<p>
-Both proposal choices are discussed, the preferred choice of the author is
-to apply (A).
+<i>Requires:</i> All iterators in the range
+<tt><del>[</del><ins>(</ins>position,last)</tt>
+are dereferenceable.
</p>
-
-
-<p><b>Proposed resolution:</b></p>
<p>
-Common part:
+<i>Effects:</i> Erases the elements in the range
+<tt><del>[</del><ins>(</ins>position,last)</tt>.
</p>
-<ul>
-<li>
<p>
-Just betwen 23.2.3.5 [forwardlist.ops] and 23.2.3.6 [forwardlist.spec]
-add a new
-section "forwardlist comparison operators" [forwardlist.compare] (and
-also add the
-new section number to 23.2.3 [forwardlist]/2 in front of "Comparison operators"):
+<i>Returns:</i> <ins>An iterator equal to <tt>position</tt></ins> <del><tt>last</tt></del>
</p>
-<blockquote>
-forwardlist comparison operators [forwardlist.compare]
</blockquote>
-</li>
-</ul>
+</blockquote>
<p>
-Option (A):
-</p>
-<blockquote>
-<ul>
-<li>
-<p>
-Add to the new section [forwardlist.compare] the following paragraphs:
+Change 23.3.3.5 [forwardlist.ops]:
</p>
<blockquote>
-<pre>template <class T, class Allocator>
-bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+<pre>void splice_after(const_iterator position, forward_list<T,Allocator>&& x);
</pre>
<blockquote>
<p>
-<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
-</p>
-<p>
-<i>Returns:</i> <tt>true</tt> if
+<i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a
+dereferenceable iterator in the range <tt>[begin(), end))</tt>. <tt>&x != this</tt>.
</p>
-<ul>
-<li>
<p>
-for every iterator <tt>i</tt> in the range <tt>[x.begin(), E)</tt>, where <tt>E ==
-x.begin() + M</tt> and <tt>M ==
- min(distance(x.begin(), x.end()), distance(y.begin(), y.end()))</tt>,
-the following condition holds:
+<i>Effects:</i> Inserts the contents of <tt>x</tt> after <tt>position</tt>, and
+<tt>x</tt> becomes empty. Pointers and references to
+the moved elements of <tt>x</tt> now refer to those same elements but as members of <tt>*this</tt>.
+Iterators referring to the moved elements will continue to refer to their elements,
+but they now behave as iterators into <tt>*this</tt>, not into <tt>x</tt>.
</p>
-<blockquote><pre>*i == *(y.begin() + (i - x.begin())).
-</pre></blockquote>
-</li>
-<li>
-if <tt>i == E</tt> then <tt>i == x.end() && (y.begin() + (i - x.begin())) == y.end()</tt>.
-</li>
-<li>
-Otherwise, returns <tt>false</tt>.
-</li>
-</ul>
<p>
-<i>Throws:</i> Nothing unless an exception is thrown by the equality comparison.
+<i>Throws:</i> Nothing.
</p>
<p>
-<i>Complexity:</i> At most <tt>M</tt> comparisons.
+<i>Complexity:</i> <del><i>Ο</i>(1)</del> <ins><i>Ο</i>(<tt>distance(x.begin(), x.end())</tt>)</ins>
</p>
</blockquote>
-<pre>template <class T, class Allocator>
-bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
-</pre>
-<blockquote>
-<i>Returns:</i> <tt>!(x == y)</tt>.
-</blockquote>
-</blockquote>
-</li>
-</ul>
-</blockquote>
-<p>
-Option (B):
-</p>
+<p>...</p>
+
+<pre>void splice_after(const_iterator position, forward_list<T,Allocator>&& x,
+ const_iterator first, const_iterator last);
+</pre>
<blockquote>
-<ul>
-<li>
<p>
-Add to the new section [forwardlist.compare] the following paragraphs:
+<i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a
+dereferenceable iterator in the range <tt>[begin(), end))</tt>.
+<tt>(first,last<ins>]</ins><del>)</del></tt> is a valid range in
+<tt>x</tt>, and all iterators in the range
+<tt>(first,last<ins>]</ins><del>)</del></tt> are dereferenceable.
+<tt>position</tt> is not an iterator in the range <tt>(first,last<ins>]</ins><del>)</del></tt>.
</p>
-<blockquote>
-<pre>template <class T, class Allocator>
-bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
-</pre>
-<blockquote>
<p>
-<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
+<i>Effects:</i> Inserts elements in the range <tt>(first,last<ins>]</ins><del>)</del></tt>
+after <tt>position</tt> and removes the elements from <tt>x</tt>.
+Pointers and references to the moved elements of <tt>x</tt> now refer to
+those same elements but as members of <tt>*this</tt>. Iterators
+referring to the moved elements will continue to refer to their
+elements, but they now behave as iterators into <tt>*this</tt>, not into
+<tt>x</tt>.
</p>
<p>
-<i>Returns:</i> <tt>distance(x.begin(), x.end()) == distance(y.begin(), y.end())
-&& equal(x.begin(), x.end(), y.begin())</tt>.
+<ins><i>Complexity:</i> <i>Ο</i>(1).</ins>
</p>
</blockquote>
-<pre>template <class T, class Allocator>
-bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
-</pre>
-<blockquote>
-<i>Returns:</i> <tt>!(x == y)</tt>.
-</blockquote>
-</blockquote>
-</li>
-</ul>
+
</blockquote>
+
<hr>
-<h3><a name="862"></a>862. Impossible complexity for 'includes'</h3>
-<p><b>Section:</b> 25.3.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-07-02</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="898"></a>898. Small contradiction in n2723 to forward to committee</h3>
+<p><b>Section:</b> 23.3.3.5 [forwardlist.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Arch Robison <b>Opened:</b> 2008-09-08 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In 25.3.5.1 [includes] the complexity is "at most -1 comparisons" if passed
-two empty ranges. I don't know how to perform a negative number of
-comparisions!
+I ran across a small contradiction in working draft n2723.
</p>
-
+<blockquote>
<p>
-This same issue also applies to:
+23.3.3 [forwardlist]p2: A <tt>forward_list</tt> satisfies all of the
+requirements of a container (table 90), except that the <tt>size()</tt> member
+function is not provided.
</p>
-
-<ul>
-<li><tt>set_union</tt></li>
-<li><tt>set_intersection</tt></li>
-<li><tt>set_difference</tt></li>
-<li><tt>set_symmetric_difference</tt></li>
-<li><tt>merge</tt></li>
-</ul>
-
-
-<p><b>Proposed resolution:</b></p>
<p>
+23.3.3.5 [forwardlist.ops]p57: <i>Complexity:</i> At most <tt>size() + x.size() - 1</tt>
+comparisons.
+</p>
+</blockquote>
+<p>
+Presumably 23.3.3.5 [forwardlist.ops]p57 needs to be rephrased to not use
+<tt>size()</tt>, or note that it is used there only for sake of notational convenience.
</p>
+<p><i>[
+2009-03-29 Beman provided proposed wording.
+]</i></p>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
-
-<hr>
-<h3><a name="863"></a>863. What is the state of a stream after close() succeeds</h3>
-<p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 2008-07-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Suppose writing to an <tt>[o]fstream</tt> fails and you later close the <tt>stream</tt>.
-The <tt>overflow()</tt> function is called to flush the buffer (if it exists).
-Then the file is unconditionally closed, as if by calling <tt>flcose</tt>.
-</p>
+<blockquote>
<p>
-If either <tt>overflow</tt> or <tt>fclose</tt> fails, <tt>close()</tt> reports failure, and clearly
-the <tt>stream</tt> should be in a failed or bad state.
+We agree with the proposed resolution.
</p>
<p>
-Suppose the buffer is empty or non-existent (so that <tt>overflow()</tt> does not
-fail), and <tt>fclose</tt> succeeds. The <tt>close()</tt> function reports success, but
-what is the state of the <tt>stream</tt>?
+Move to Tentatively Ready.
</p>
+</blockquote>
<p><b>Proposed resolution:</b></p>
-<p>
-</p>
+<p><i>Change 23.3.3.5 [forwardlist.ops],
+forward_list operations, paragraph 19, merge complexity as indicated:
+</i></p>
+<blockquote><i>Complexity:</i> At most <tt><del>size() + x.size()</del>
+<ins>distance(begin(), end()) + distance(x.begin(), x.end())</ins> - 1</tt>
+comparisons.
+</blockquote>
<hr>
-<h3><a name="864"></a>864. Defect in atomic wording</h3>
-<p><b>Section:</b> 29.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Anthony Williams <b>Date:</b> 2008-07-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="899"></a>899. Adjusting <tt>shared_ptr</tt> for <tt>nullptr_t</tt></h3>
+<p><b>Section:</b> 20.8.13.2.2 [util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-18 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.dest">issues</a> in [util.smartptr.shared.dest].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-There's an error in 29.4 [atomics.types.operations]/p9:
+James Dennett, message c++std-lib-22442:
</p>
-
<blockquote>
-<pre>C atomic_load(const volatile A * object);
-C atomic_load_explicit(const volatile A * object, memory_order);
-C A ::load(memory_order order = memory_order_seq_cst) const volatile;
-</pre>
-<blockquote>
-<p>
-<i>Requires:</i> The <tt>order</tt> argument shall not be <tt>memory_order_acquire</tt> nor
-<tt>memory_order_acq_rel</tt>.
-</p>
+The wording below addresses one case of this, but opening an
+issue to address the need to sanity check uses of the term "pointer"
+in 20.8.13.2 [util.smartptr.shared] would be a good thing.
</blockquote>
-</blockquote>
-
<p>
-I believe that this should state
+There's one more reference, in <tt>~shared_ptr;</tt> we can apply your suggested change to it, too. That is:
</p>
-<blockquote>
-shall not be <tt>memory_order_release</tt>.
-</blockquote>
-
<p>
-There's also an error in 29.4 [atomics.types.operations]/p17:
+Change 20.8.13.2.2 [util.smartptr.shared.dest]/1 second bullet from:
</p>
-
<blockquote>
-... When only one <tt>memory_order</tt> argument is supplied, the value of success
-is <tt>order</tt>, and
-the value of failure is <tt>order</tt> except that a value of
-<tt>memory_order_acq_rel</tt> shall be replaced by the value
-<tt>memory_order_require</tt> ...
+Otherwise, if *this owns a pointer p and a deleter d, d(p) is called.
</blockquote>
<p>
-I believe this should state
+to:
</p>
<blockquote>
-shall be replaced by the value <tt>memory_order_acquire</tt> ...
+Otherwise, if *this owns an object p and a deleter d, d(p) is called.
</blockquote>
+<p><i>[
+Post Summit:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 29.4 [atomics.types.operations]/p9:
-</p>
<blockquote>
-<pre>C atomic_load(const volatile A * object);
-C atomic_load_explicit(const volatile A * object, memory_order);
-C A ::load(memory_order order = memory_order_seq_cst) const volatile;
-</pre>
+Recommend Review.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
<blockquote>
<p>
-<i>Requires:</i> The <tt>order</tt> argument shall not be <del><tt>memory_order_acquire</tt></del>
-<ins><tt>memory_order_release</tt></ins> nor <tt>memory_order_acq_rel</tt>.
+Peter Dimov notes the analogous change has already been made
+to "the new nullptr_t taking constructors
+in 20.8.13.2.1 [util.smartptr.shared.const] p9-13."
+</p>
+<p>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
</p>
</blockquote>
-</blockquote>
+
+<p><b>Proposed resolution:</b></p>
<p>
-Change 29.4 [atomics.types.operations]/p17:
+Change 20.8.13.2.2 [util.smartptr.shared.dest]/1 second bullet:
</p>
-
<blockquote>
-... When only one <tt>memory_order</tt> argument is supplied, the value of success
-is <tt>order</tt>, and
-the value of failure is <tt>order</tt> except that a value of
-<tt>memory_order_acq_rel</tt> shall be replaced by the value
-<del><tt>memory_order_require</tt></del> <ins><tt>memory_order_acquire</tt></ins> ...
+<ul>
+<li>...</li>
+<li>
+Otherwise, if <tt>*this</tt> <i>owns</i> <del>a pointer</del>
+<ins>an object</ins> <tt>p</tt> and a
+deleter <tt>d</tt>, <tt>d(p)</tt> is called.
+</li>
+</ul>
</blockquote>
-
<hr>
-<h3><a name="865"></a>865. More algorithms that throw away information</h3>
-<p><b>Section:</b> 25.2.6 [alg.fill], 25.2.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-07-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="900"></a>900. stream move-assignment</h3>
+<p><b>Section:</b> 27.9.1.8 [ifstream.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-09-20 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In regard to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a> I found some more algorithms which
-unnecessarily throw away information. These are typically algorithms,
-which sequentially write into an <tt>OutputIterator</tt>, but do not return the
-final value of this output iterator. These cases are:
+It
+appears that we have an issue similar to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> regarding the move-assignment of
+stream types. For example, when assigning to an <tt>std::ifstream</tt>,
+<tt>ifstream1</tt>, it seems preferable to close the file originally held by
+<tt>ifstream1</tt>:
</p>
-<ol>
-<li>
-<pre>template<class OutputIterator, class Size, class T>
-void fill_n(OutputIterator first, Size n, const T& value);</pre></li>
+<blockquote><pre>ifstream1 = std::move(ifstream2);
+</pre></blockquote>
-<li>
-<pre>template<class OutputIterator, class Size, class Generator>
-void generate_n(OutputIterator first, Size n, Generator gen);</pre></li>
-</ol>
<p>
-In both cases the minimum requirements on the iterator are
-<tt>OutputIterator</tt>, which means according to the requirements of
-24.1.2 [output.iterators]/2 that only single-pass iterations are guaranteed.
-So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt>
-available, they have no chance to continue pushing further values
-into it, which seems to be a severe limitation to me.
+The current Draft
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
+specifies that the move-assignment of
+stream types like <tt>ifstream</tt> has the same effect as a swap:
</p>
-
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
+<blockquote>
<p>
-Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header
-<tt><algorithm></tt> synopsis and in 25.2.6 [alg.fill] by
+Assign and swap 27.9.1.8 [ifstream.assign]
</p>
+<pre>basic_ifstream& operator=(basic_ifstream&& rhs);
+</pre>
+<blockquote>
+<i>Effects:</i> <tt>swap(rhs)</tt>.
+</blockquote>
+</blockquote>
-<blockquote><pre>template<class OutputIterator, class Size, class T>
-<del>void</del> <ins>OutputIterator</ins> fill_n(OutputIterator first, Size n, const T& value);
-</pre></blockquote>
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
<p>
-Just after the effects clause p.2 add a new returns clause saying:
+Howard agrees with the analysis and the direction proposed.
</p>
-<blockquote>
-<i>Returns:</i> <tt>first + n</tt> for <tt>fill_n</tt>.
-</blockquote>
-</li>
-<li>
<p>
-Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2, header
-<tt><algorithm></tt> synopsis and in 25.2.7 [alg.generate] by
+Move to Open pending specific wording to be supplied by Howard.
</p>
-<blockquote><pre>template<class OutputIterator, class Size, class Generator>
-<del>void</del> <ins>OutputIterator</ins> generate_n(OutputIterator first, Size n, Generator gen);
-</pre></blockquote>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-Just after the effects clause p.1 add a new returns clause saying:
</p>
-<blockquote>
-<i>Returns:</i> <tt>first + n</tt> for <tt>generate_n</tt>.
-</blockquote>
-</li>
-</ol>
<hr>
-<h3><a name="866"></a>866. Qualification of placement new-expressions</h3>
-<p><b>Section:</b> 20.7.10 [specialized.algorithms], 20.7.12.2.6 [util.smartptr.shared.create] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="901"></a>901. insert iterators can move from lvalues</h3>
+<p><b>Section:</b> 24.7.5 [insert.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-24 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
+<p><b>Addresses UK 282</b></p>
+
<p>
-LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> replaced "<tt>new</tt>" with "<tt>::new</tt>" in the placement
-new-expression in 20.7.5.1 [allocator.members]. I believe the rationale
-given in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> applies also to the following other contexts:
+The requires clause on the <tt>const T &</tt> overloads in
+<tt>back_insert_iterator/front_insert_iterator/insert_iterator</tt> mean that the
+assignment operator will implicitly move from lvalues of a move-only type.
</p>
-<ul>
-<li>
<p>
-in 20.7.10 [specialized.algorithms], all four algorithms <tt>unitialized_copy</tt>,
-<tt>unitialized_copy_n</tt>, <tt>unitialized_fill</tt> and <tt>unitialized_fill_n</tt> use
-the unqualified placement new-expression in some variation of the form:
+Suggested resolutions are:
</p>
-<blockquote><pre>new (static_cast<void*>(&*result)) typename iterator_traits<ForwardIterator>::value_type(*first);
-</pre></blockquote>
+<ol type="a">
+<li>
+Add another overload with a negative constraint on copy-constructible
+and flag it "= delete".
</li>
<li>
-<p>
-in 20.7.12.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
-</p>
-<blockquote><pre>new (pv) T(std::forward<Args>(args)...),
-</pre></blockquote>
+Drop the copy-constructible overload entirely and rely on perfect
+forwarding to catch move issues one level deeper.
</li>
-</ul>
+<li>
+This is a fundamental problem in move-syntax that relies on the
+presence of two overloads, and we need to look more deeply into this
+area as a whole - do not solve this issue in isolation.
+</li>
+</ol>
+
+<p><i>[
+Post Summit, Alisdair adds:
+]</i></p>
+
+
+<blockquote>
<p>
-I suggest to add qualification in all those places. As far as I know,
-these are all the remaining places in the whole library that explicitly
-use a placement new-expression. Should other uses come out, they should
-be qualified as well.
+Both comment and issue have been resolved by the adoption of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
+(rvalue references safety fix) at the last meeting.
</p>
+
<p>
-As an aside, a qualified placement new-expression does not need
-additional requirements to be compiled in a constrained context. By
-adding qualification, the <tt>HasPlacementNew</tt> concept introduced recently in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2677.pdf">N2677 (Foundational Concepts)</a>
-would no longer be needed by library and
-should therefore be removed.
+Suggest resolve as NAD Editorial with a reference to the paper.
</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree that this has been resolved in the latest Working Draft.
+Move to NAD.
+</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Replace "<tt>new</tt>" with "<tt>::new</tt>" in:
+Recommend NAD, addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>.
</p>
-<ul>
-<li>
-20.7.10.1 [uninitialized.copy], paragraphs 1 and 3
-</li>
-<li>
-20.7.10.2 [uninitialized.fill] paragraph 1
-</li>
-<li>
-20.7.10.3 [uninitialized.fill.n] paragraph 1
-</li>
-<li>
-20.7.12.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2.
-</li>
-</ul>
-
<hr>
-<h3><a name="867"></a>867. Valarray and value-initialization</h3>
-<p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="902"></a>902. Regular is the wrong concept to constrain numeric_limits</h3>
+<p><b>Section:</b> 18.3.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-24 <b>Last modified:</b> 2009-03-11</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
-<p>
-From 26.5.2.1 [valarray.cons], paragraph 2:
-</p>
-<blockquote><pre>explicit valarray(size_t);
-</pre>
-<blockquote>
-The array created by this constructor has a length equal to the value of the argument. The elements
-of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
-</blockquote>
-</blockquote>
+<p><b>Addresses FR 32 and DE 16</b></p>
<p>
-The problem is that the most obvious <tt>T</tt>s for <tt>valarray</tt> are <tt>float</tt>
-and <tt>double</tt>, they don't have a default constructor. I guess the intent is to value-initialize
-the elements, so I suggest replacing:
+<tt>numeric_limits</tt> has functions specifically designed to return NaNs, which
+break the model of <tt>Regular</tt> (via its axioms.) While floating point types
+will be acceptible in many algorithms taking <tt>Regular</tt> values, it is not
+appopriate for this specific API and we need a less refined constraint.
</p>
+<p>FR 32:</p>
+
<blockquote>
-The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
+The definition of <tt>numeric_limits<></tt> as requiring a regular
+type is both conceptually wrong and operationally illogical. As we
+pointed before, this mistake needs to be corrected. For example, the
+template can be left unconstrained. In fact this reflects a much more
+general problem with concept_maps/axioms and their interpretations. It
+appears that the current text heavily leans toward experimental academic
+type theory.
</blockquote>
-<p>
-with
-</p>
+
+<p>DE 16:</p>
+
<blockquote>
-The elements of the array are value-initialized.
+The class template <tt>numeric_limits</tt> should not specify the Regular concept
+requirement for its template parameter, because it contains functions
+returning NaN values for floating-point types; these values violate the
+semantics of EqualityComparable.
</blockquote>
-<p>
-There is another reference to the default constructor of <tt>T</tt> in the non-normative note in paragraph 9.
-That reference should also be replaced. (The normative wording in paragraph 8 refers to <tt>T()</tt>
-and so it doesn't need changes).
-</p>
-
+<p><i>[
+Summit:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.5.2.1 [valarray.cons], paragraph 2:
-</p>
<blockquote>
-<pre>explicit valarray(size_t);
-</pre>
-<blockquote>
-The array created by this constructor has a length equal to the value of the argument. The elements
-of the array are <del>constructed using the default constructor for the instantiating type <tt>T</tt></del>
-<ins>value-initialized (8.5 [dcl.init])</ins>.
-</blockquote>
+Move to Open. Alisdair and Gaby will work on a solution, along with the new
+treatment of axioms in clause 14.
</blockquote>
-<p>
-Change 26.5.2.7 [valarray.members], paragraph 9:
-</p>
-<blockquote>
-[<i>Example:</i> If the argument has the value -2, the first two elements of the result will be <del>constructed using the
-default constructor</del>
-<ins>value-initialized (8.5 [dcl.init])</ins>;
-the third element of the result will be assigned the value of the first element of the argument; etc. <i>-- end example</i>]
-</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
<hr>
-<h3><a name="868"></a>868. default construction and value-initialization</h3>
-<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="903"></a>903. <tt>back_insert_iterator</tt> issue</h3>
+<p><b>Section:</b> 24.7.1 [back.insert.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2008-09-19 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The term "default constructed" is often used in wording that predates
-the introduction of the concept of value-initialization. In a few such
-places the concept of value-initialization is more correct than the
-current wording (for example when the type involved can be a built-in)
-so a replacement is in order. Two of such places are already covered by
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>. This issue deliberately addresses the hopefully
-non-controversial changes in the attempt of being approved more quickly.
-A few other occurrences (for example in <tt>std::tuple</tt>,
-<tt>std::reverse_iterator</tt> and <tt>std::move_iterator</tt>) are left to separate
-issues. For <tt>std::reverse_iterator</tt>, see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>. This issue is
-related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>.
+I just noticed this; don't know how far the problem(?) extends or
+whether it's new or existing: <tt>back_insert_iterator</tt>'s <tt>operator*</tt> is not
+<tt>const</tt>, so you can't dereference a <tt>const</tt> one.
</p>
+<p><i>[
+Post Summit Daniel adds:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.1.1 [utility.arg.requirements], paragraph 2:
-</p>
<blockquote>
-In general, a default constructor is not required. Certain container class member function signatures specify
-<del>the default constructor</del>
-<ins><tt>T()</tt></ins>
-as a default argument. <tt>T()</tt> shall be a well-defined expression (8.5 [dcl.init]) if one of
-those signatures is called using the default argument (8.3.6 [dcl.fct.default]).
-</blockquote>
-
<p>
-In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized
-(8.5 [dcl.init])":
+If done, this change should be applied for <tt>front_insert_iterator</tt>,
+<tt>insert_iterator</tt>, <tt>ostream_iterator</tt>, and <tt>ostreambuf_iterator</tt> as well.
</p>
+</blockquote>
-<ul>
-<li>23.2.2.1 [deque.cons] para 2</li>
-<li>23.2.2.2 [deque.capacity] para 1</li>
-<li>23.2.3.1 [forwardlist.cons] para 3</li>
-<li>23.2.3.4 [forwardlist.modifiers] para 21</li>
-<li>23.2.4.1 [list.cons] para 3</li>
-<li>23.2.4.2 [list.capacity] para 1</li>
-<li>23.2.6.1 [vector.cons] para 3</li>
-<li>23.2.6.2 [vector.capacity] para 10</li>
-</ul>
-
-
-
-
+<p><i>[
+Batavia (2009-05):
+]</i></p>
-<hr>
-<h3><a name="869"></a>869. Bucket (local) iterators and iterating past end</h3>
-<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Sohail Somani <b>Date:</b> 2008-07-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
+<blockquote>
<p>
-Is there any language in the current draft specifying the behaviour of the following snippet?
+Alisdair notes that these all are output iterators.
+Howard points out that <tt>++*i</tt>
+would no longer work if we made this change.
</p>
-
-<blockquote><pre>unordered_set<int> s;
-unordered_set<int>::local_iterator it = s.end(0);
-
-// Iterate past end - the unspecified part
-it++;
-</pre></blockquote>
-
<p>
-I don't think there is anything about <tt>s.end(n)</tt> being considered an
-iterator for the past-the-end value though (I think) it should be.
+Move to NAD.
</p>
+</blockquote>
+<p><i>[
+2009-05-25 Daniel adds:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change Table 97 "Unordered associative container requirements" in 23.1.5 [unord.req]:
-</p>
-<blockquote>
-<table border="1">
-<caption>Table 97: Unordered associative container requirements</caption>
-<tbody><tr>
-<th>expression</th><th>return type</th><th>assertion/note pre/post-condition</th><th>complexity</th>
-</tr>
-<tr>
-<td><tt>b.begin(n)</tt></td>
-<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
-<td>Pre: n shall be in the range [0,b.bucket_count()). <del>Note: [b.begin(n), b.end(n)) is a
-valid range containing all of the elements in the n<sup>th</sup> bucket.</del>
-<ins><tt>b.begin(n)</tt> returns an iterator referring to the first element in the bucket.
-If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td>
-<td>Constant</td>
-</tr>
-<tr>
-<td><tt>b.end(n)</tt></td>
-<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
-<td>Pre: n shall be in the range <tt>[0, b.bucket_count())</tt>.
-<ins><tt>b.end(n)</tt> returns an iterator which is the past-the-end value for the bucket.</ins></td>
-<td>Constant</td>
-</tr>
-</tbody></table>
-</blockquote>
+<ol>
+<li>
+If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a> is accepted, <tt>OutputIterator</tt> does no longer support post increment.
+</li>
+<li>
+To support backward compatibility a second overload of <tt>operator*</tt>
+can be added.
+Note that the <tt>HasDereference</tt> concept (and the <tt>HasDereference</tt> part of concept
+<tt>Iterator</tt>) was specifically refactored to cope with optional const
+qualification and
+to properly reflect the dual nature of built-in <tt>operator*</tt> as of
+13.5.8 [over.literal]/6.
+</li>
+</ol>
+
+<p><b>Proposed resolution:</b></p>
<hr>
-<h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3>
-<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="904"></a>904. result_of argument types</h3>
+<p><b>Section:</b> 20.7.4 [func.ret] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2008-09-10 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Good ol' associative containers allow both function pointers and
-function objects as feasible
-comparators, as described in 23.1.4 [associative.reqmts]/2:
+The WP and TR1 have the same text regarding the argument types of a
+<tt>result_of</tt> expression:
</p>
-
<blockquote>
-Each associative container is parameterized on <tt>Key</tt> and an ordering
-relation <tt>Compare</tt> that
-induces a strict weak ordering (25.3) on elements of Key. [..]. The
-object of type <tt>Compare</tt> is
-called the comparison object of a container. This comparison object
-may be a pointer to
-function or an object of a type with an appropriate function call operator.[..]
+The values <tt>ti</tt> are lvalues when the corresponding type <tt>Ti</tt> is a
+reference type, and rvalues otherwise.
</blockquote>
-
<p>
-The corresponding wording for unordered containers is not so clear,
-but I read it to disallow
-function pointers for the hasher and I miss a clear statement for the
-equality predicate, see
-23.1.5 [unord.req]/3+4+5:
+I read this to mean that this compiles:
</p>
-
-<blockquote>
+<blockquote><pre>typedef int (*func)(int&);
+result_of<func(int&&)>::type i = 0;
+</pre></blockquote>
<p>
-Each unordered associative container is parameterized by <tt>Key</tt>, by a
-function object <tt>Hash</tt> that
-acts as a hash function for values of type <tt>Key</tt>, and by a binary
-predicate <tt>Pred</tt> that induces an
-equivalence relation on values of type <tt>Key</tt>.[..]
+even though this doesn't:
</p>
+<blockquote><pre>int f(int&);
+f( std::move(0) );
+</pre></blockquote>
<p>
-A hash function is a function object that takes a single argument of
-type <tt>Key</tt> and returns a
-value of type <tt>std::size_t</tt>.
+Should the text be updated to say "when <tt>Ti</tt> is an lvalue-reference
+type" or am I missing something?
</p>
<p>
-Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the
-container's equality function object
-returns <tt>true</tt> when passed those values.[..]
+I later came up with this self-contained example which won't compile,
+but I think it should:
</p>
-</blockquote>
+<blockquote><pre>struct X {
+ void operator()(int&);
+ int operator()(int&&);
+} x;
+
+std::result_of< X(int&&) >::type i = x(std::move(0));
+</pre></blockquote>
+
+<p><i>[
+Post Summit:
+]</i></p>
-<p>
-and table 97 says in the column "assertion...post-condition" for the
-expression X::hasher:
-</p>
<blockquote>
-<tt>Hash</tt> shall be a unary function object type such that the expression
-<tt>hf(k)</tt> has type <tt>std::size_t</tt>.
+Recommend Tentatively Ready.
</blockquote>
-<p>
-Note that 20.6 [function.objects]/1 defines as "Function objects are
-objects with an <tt>operator()</tt> defined.[..]"
-</p>
-<p>
-Does this restriction exist by design or is it an oversight? If an
-oversight, I suggest that to apply
-the following
-</p>
<p><b>Proposed resolution:</b></p>
<p>
-In 23.1.5 [unord.req]/3, just after the second sentence which is written as
-</p>
-
-<blockquote>
-Additionally, <tt>unordered_map</tt> and <tt>unordered_multimap</tt> associate an
-arbitrary mapped type <tt>T</tt> with the <tt>Key</tt>.
-</blockquote>
-
-<p>
-add one further sentence:
+Change 20.7.4 [func.ret], p1:
</p>
<blockquote>
-Both <tt>Hash</tt> and <tt>Pred</tt> may be pointers to function or objects of a type
-with an appropriate function call operator.
+... The values <tt>ti</tt> are lvalues
+when the corresponding type <tt>Ti</tt> is a<ins>n</ins> <ins>lvalue-</ins>reference type,
+and rvalues otherwise.
</blockquote>
-<p>
-[Note1: Since the detailed requirements for <tt>Pred</tt> and <tt>Hash</tt> are given in
-p.4 and p.5, it an alternative resolution
-would be to insert a new paragraph just after p.5, which contains the
-above proposed sentence]
-</p>
-<p>
-[Note2: I do not propose a change of above quoted element in table 97,
-because the mis-usage of the
-notion of "function object" seems already present in the standard at
-several places, even if it includes
-function pointers, see e.g. 25 [algorithms]/7. The important point is
-that in those places a statement is
-given that the actually used symbol, like "Predicate" applies for
-function pointers as well]
-</p>
-
<hr>
-<h3><a name="871"></a>871. Iota's requirements on T are too strong</h3>
-<p><b>Section:</b> 26.6.5 [numeric.iota] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="906"></a>906. <tt>ObjectType</tt> is the wrong concept to constrain <tt>initializer_list</tt></h3>
+<p><b>Section:</b> 18.9 [support.initlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-According to the recent WP
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>,
-26.6.5 [numeric.iota]/1, the requires clause
-of <tt>std::iota</tt> says:
+The currently proposed constraint on <tt>initializer_list</tt>'s element type
+<tt>E</tt> is that is has to meet <tt>ObjectType</tt>. This is an underspecification,
+because both core language and library part of <tt>initializer_list</tt>
+make clear, that it references an implicitly allocated array:
+</p>
+<p>
+8.5.4 [dcl.init.list]/4:
</p>
-
<blockquote>
-<tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and
-shall be convertible to <tt>ForwardIterator</tt>'s value type.[..]
+When an initializer list is implicitly converted to a
+<tt>std::initializer_list<E></tt>, the object passed is constructed as if the
+implementation allocated an array of N elements of type <tt>E</tt>, where
+N is the number of elements in the initializer list.[..]
</blockquote>
<p>
-Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt>
-seems to be the correct choice. I guess the current wording resulted as an
-artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>.
+18.9 [support.initlist]/2.
</p>
+<blockquote>
+An object of type <tt>initializer_list<E></tt> provides access to an array of
+objects of type <tt>const E</tt>.[..]
+</blockquote>
+
<p>
-Note: If this function will be conceptualized, the here proposed
-<tt>MoveConstructible</tt>
-requirement can be removed, because this is an implied requirement of
-function arguments, see
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet.
+Therefore, <tt>E</tt> needs to fulfill concept <tt>ValueType</tt> (thus excluding
+abstract class types). This stricter requirement should be added
+to prevent deep instantiation errors known from the bad old times,
+as shown in the following example:
</p>
+<blockquote><pre>// Header A: (Should concept-check even in stand-alone modus)
+template <DefaultConstructible T>
+requires MoveConstructible<T>
+void generate_and_do_3(T a) {
+ std::initializer_list<T> list{T(), std::move(a), T()};
+ ...
+}
-<p><b>Proposed resolution:</b></p>
+void do_more();
+void do_more_or_less();
-<p>
-Change the first sentence of 26.6.5 [numeric.iota]/1:
-</p>
+template <DefaultConstructible T>
+requires MoveConstructible<T>
+void more_generate_3() {
+ do_more();
+ generate_and_do_3(T());
+}
-<blockquote>
-<i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of
-<tt>CopyConstructible</tt> and <tt>Assignable</tt> types,</del>
-<ins>
-be <tt>MoveConstructible</tt> (Table 34)
-</ins>
-and shall be
-convertible to <tt>ForwardIterator</tt>'s value type. [..]
-</blockquote>
+template <DefaultConstructible T>
+requires MoveConstructible<T>
+void something_and_generate_3() {
+ do_more_or_less();
+ more_generate_3();
+}
+// Test.cpp
+#include "A.h"
+class Abstract {
+public:
+ virtual ~Abstract();
+ virtual void foo() = 0; // abstract type
+ Abstract(Abstract&&){} // MoveConstructible
+ Abstract(){} // DefaultConstructible
+};
+int main() {
+ // The restricted template *accepts* the argument, but
+ // causes a deep instantiation error in the internal function
+ // generate_and_do_3:
+ something_and_generate_3<Abstract>();
+}
+</pre></blockquote>
+<p>
+The proposed stricter constraint does not minimize the aim to
+support more general containers for which <tt>ObjectType</tt> would be
+sufficient. If such an extended container (lets assume it's still a
+class template) provides a constructor that accepts an <tt>initializer_list</tt>
+only <em>this</em> constructor would need to be restricted on <tt>ValueType</tt>:
+</p>
-<hr>
-<h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3>
-<p><b>Section:</b> 24.4.3.3.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-08-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<blockquote><pre>template<ObjectType T>
+class ExtContainer {
+public:
+ requires ValueType<T>
+ ExtContainer(std::initializer_list<T>);
+ ...
+};
+</pre></blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Tentatively Ready.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+In 18.9 [support.initlist]/p.1 replace in "header <tt><initializer_list></tt> synopsis"
+the constraint "<tt>ObjectType</tt>" in the template parameter list by the
+constraint "<tt>ValueType</tt>".
+</li>
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="907"></a>907. Bitset's immutable element retrieval is inconsistently defined</h3>
+<p><b>Section:</b> 20.3.6.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-<tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as:
+The current standard 14882::2003(E) as well as the current draft
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
+have in common a contradiction of the operational semantics
+of member function test 20.3.6.2 [bitset.members]/56-58 and the immutable
+member <tt>operator[]</tt> overload 20.3.6.2 [bitset.members]/64-66 (all references
+are defined in terms of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>):
+</p>
+
+<ol>
+<li><pre>bool test(size_t pos) const;
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> <tt>pos</tt> is valid
+</p>
+<p>
+<i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond
+to a valid bit position.
+</p>
+<p>
+<i>Returns:</i> <tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
+has the value one.
+</p>
+</blockquote>
+</li>
+<li><pre>constexpr bool operator[](size_t pos) const;
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> <tt>pos</tt> shall be valid.
+</p>
+<p>
+<i>Throws:</i> nothing.
+</p>
+<p>
+<i>Returns:</i> <tt>test(pos)</tt>.
+</p>
+</blockquote>
+</li>
+</ol>
+
+<p>
+Three interpretations:
+</p>
+
+<ol type="A">
+<li>
+The <tt>operator[]</tt> overload is indeed allowed to throw an exception
+(via <tt>test()</tt>, if <tt>pos</tt> corresponds to an invalid bit position) which does
+not leave the call frame. In this case this function cannot be a
+<tt>constexpr</tt> function, because <tt>test()</tt> is not, due to
+5.19 [expr.const]/2, last bullet.
+</li>
+<li>
+The intend was not to throw an exception in <tt>test</tt> in case of an
+invalid bit position. There is only little evidence for this interpretation.
+</li>
+<li>
+The intend was that <tt>operator[]</tt> should not throw any exception,
+but that <tt>test</tt> has the contract to do so, if the provided bit position
+is invalid.
+</li>
+</ol>
+
+<p>
+The problem became worse, because issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
+recently voted into WP argued that member <tt>test</tt> logically must be
+a <tt>constexpr</tt> function, because it was used to define the semantics
+of another <tt>constexpr</tt> function (the <tt>operator[]</tt> overload).
+</p>
+
+<p>
+Three alternatives are proposed, corresponding to the three bullets
+(A), (B), and (C), the author suggests to follow proposal (C).
+</p>
+
+<b>
+Proposed alternatives:
+</b>
+
+<ol type="A">
+<li>
+<p>
+Remove the <tt>constexpr</tt> specifier in front of <tt>operator[]</tt> overload and
+undo that of member <tt>test</tt> (assuming <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a> is accepted) in both the
+class declaration 20.3.6 [template.bitset]/1 and in the member description
+before 20.3.6.2 [bitset.members]/56 and before /64 to read:
+</p>
+<blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
+..
+<del>constexpr</del> bool operator[](size_t pos) const;
+</pre></blockquote>
+
+<p>
+Change the throws clause of p. 65 to read:
+</p>
+
+<blockquote>
+<i>Throws:</i> <del>nothing</del>
+<ins><tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit
+position</ins>.
+</blockquote>
+</li>
+<li>
+<p>
+Replace the throws clause p. 57 to read:
+</p>
+
+<blockquote>
+<i>Throws:</i> <del><tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit
+position</del> <ins>nothing</ins>.
+</blockquote>
+</li>
+<li>
+<p>
+Undo the addition of the <tt>constexpr</tt> specifier to the <tt>test</tt> member
+function in both class declaration 20.3.6 [template.bitset]/1 and in the
+member description before 20.3.6.2 [bitset.members]/56, assuming that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
+was applied.
</p>
-<blockquote><pre>reference operator[](difference_type n) const;
+<blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
</pre></blockquote>
<p>
-This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to
-have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the
-implicit conversion to <tt>value_type&&</tt> could end up referencing a temporary
-that has already been destroyed. This is essentially the same issue that
-we dealt with for <tt>reverse_iterator</tt> in DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>.
+Change the returns clause p. 66 to read:
+</p>
+
+<blockquote>
+<i>Returns:</i> <del><tt>test(pos)</tt></del> <ins><tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
+has the value one, otherwise <tt>false</tt></ins>.
+</blockquote>
+</li>
+</ol>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Lawrence: proposed resolutions A, B, C are mutually exclusive.
+</p>
+<p>
+Recommend Review with option C.
</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
<p><b>Proposed resolution:</b></p>
+
+<ol ,="" start="3" type="A">
+<li>
<p>
-In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the declaration of
-<tt>move_iterator</tt>'s <tt>operator[]</tt> to:
+Undo the addition of the <tt>constexpr</tt> specifier to the <tt>test</tt> member
+function in both class declaration 20.3.6 [template.bitset]/1 and in the
+member description before 20.3.6.2 [bitset.members]/56, assuming that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
+was applied.
</p>
-<blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const;
+<blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
</pre></blockquote>
+<p>
+Change the returns clause p. 66 to read:
+</p>
+
+<blockquote>
+<i>Returns:</i> <del><tt>test(pos)</tt></del> <ins><tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
+has the value one, otherwise <tt>false</tt></ins>.
+</blockquote>
+</li>
+</ol>
+
<hr>
-<h3><a name="873"></a>873. signed integral type and unsigned integral type are not clearly defined</h3>
-<p><b>Section:</b> 3.9.1 [basic.fundamental] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Travis Vitek <b>Date:</b> 2008-06-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<h3><a name="908"></a>908. Deleted assignment operators for atomic types must be volatile</h3>
+<p><b>Section:</b> 29.5 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
- <p>
- Neither the term "signed integral type" nor the term "unsigned
- integral type" is defined in the core language section of the
- standard, therefore the library section should avoid its use. The
- terms <i>signed integer type</i> and <i>unsigned integer type</i> are
- indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be
- replaced accordingly.
- </p>
- <p>
- Note that the key issue here is that "signed" + "integral type" !=
- "signed integral type".
-
- The types <code>bool</code>, <code>char</code>, <code>char16_t</code>,
- <code>char32_t</code> and <code>wchar_t</code> are all listed as
- integral types, but are neither of <i>signed integer type</i> or
- <i>unsigned integer type</i>. According to 3.9 [basic.types] p7, a synonym for
- integral type is <i>integer type</i>.
-
- Given this, one may choose to assume that an <i>integral type</i> that
- can represent values less than zero is a <i>signed integral type</i>.
- Unfortunately this can cause ambiguities.
-
- As an example, if <code>T</code> is <code>unsigned char</code>, the
- expression <code>make_signed<T>::type</code>, is supposed to
- name a signed integral type. There are potentially two types that
- satisfy this requirement, namely <code>signed char</code> and
- <code>char</code> (assuming <code>CHAR_MIN < 0</code>).
- </p>
-
+<p><b>Addresses US 90</b></p>
- <p><b>Proposed resolution:</b></p>
- <p>
- I propose to use the terms "signed integer type" and "unsigned integer
- type" in place of "signed integral type" and "unsigned integral type"
- to eliminate such ambiguities.
- </p>
-
- <p>
- The proposed change makes it absolutely clear that the difference
- between two pointers cannot be <tt>char</tt> or <tt>wchar_t</tt>,
- but could be any of the signed integer types.
- 5.7 [expr.add] paragraph 6...
- </p>
- <blockquote>
- <p>
- </p><ol>
- <li>
- When two pointers to elements of the same array object are
- subtracted, the result is the difference of the subscripts of
- the two array elements. The type of the result is an
- implementation-defined <del>signed integral
- type</del><ins>signed integer type</ins>; this type shall be the
- same type that is defined as <code>std::ptrdiff_t</code> in the
- <code><cstdint></code> header (18.1)...
- </li>
- </ol>
-
- </blockquote>
+<p>
+The deleted copy-assignment operators for the atomic types are not
+marked as volatile in N2723, whereas the assignment operators from the
+associated non-atomic types are. e.g.
+</p>
+<blockquote><pre>atomic_bool& operator=(atomic_bool const&) = delete;
+atomic_bool& operator=(bool) volatile;
+</pre></blockquote>
- <p>
- The proposed change makes it clear that <tt>X::size_type</tt> and
- <tt>X::difference_type</tt> cannot be <tt>char</tt> or
- <tt>wchar_t</tt>, but could be one of the signed or unsigned integer
- types as appropriate.
- 20.1.2 [allocator.requirements] table 40...
- </p>
- <blockquote>
- Table 40: Allocator requirements
- <table border="1">
- <thead>
- <tr>
- <th>expression</th>
- <th>return type</th>
- <th>assertion/note/pre/post-condition</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td><tt>X::size_type</tt></td>
- <td>
- <del>unsigned integral type</del>
- <ins>unsigned integer type</ins>
- </td>
- <td>a type that can represent the size of the largest object in
- the allocation model.</td>
- </tr>
- <tr>
- <td><tt>X::difference_type</tt></td>
- <td>
- <del>signed integral type</del>
- <ins>signed integer type</ins>
- </td>
- <td>a type that can represent the difference between any two
- pointers in the allocation model.</td>
- </tr>
- </tbody>
- </table>
- </blockquote>
+<p>
+This leads to ambiguity when assigning a non-atomic value to a
+non-volatile instance of an atomic type:
+</p>
+<blockquote><pre>atomic_bool b;
+b=false;
+</pre></blockquote>
- <p>
- The proposed change makes it clear that <tt>make_signed<T>::type</tt>
- must be one of the signed integer types as defined in 3.9.1. Ditto for
- <tt>make_unsigned<T>type</tt> and unsigned integer types.
- 20.5.6.3 [meta.trans.sign] table 48...
- </p>
- <blockquote>
- Table 48: Sign modifications
- <table border="1">
- <thead>
- <tr>
- <th>Template</th>
- <th>Comments</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>
- <tt>template <class T> struct make_signed;</tt>
- </td>
- <td>
- If <code>T</code> names a (possibly cv-qualified) <del>signed
- integral type</del><ins>signed integer type</ins> (3.9.1) then
- the member typedef <code>type</code> shall name the type
- <code>T</code>; otherwise, if <code>T</code> names a (possibly
- cv-qualified) <del>unsigned integral type</del><ins>unsigned
- integer type</ins> then <code>type</code> shall name the
- corresponding <del>signed integral type</del><ins>signed
- integer type</ins>, with the same cv-qualifiers as
- <code>T</code>; otherwise, <code>type</code> shall name the
- <del>signed integral type</del><ins>signed integer type</ins>
- with the smallest rank (4.13) for which <code>sizeof(T) ==
- sizeof(type)</code>, with the same cv-qualifiers as
- <code>T</code>.
+<p>
+Both assignment operators require a standard conversions: the
+copy-assignment operator can use the implicit <tt>atomic_bool(bool)</tt>
+conversion constructor to convert <tt>false</tt> to an instance of
+<tt>atomic_bool</tt>, or <tt>b</tt> can undergo a qualification conversion in order to
+use the assignment from a plain <tt>bool</tt>.
+</p>
- <i>Requires:</i> <code>T</code> shall be a (possibly
- cv-qualified) integral type or enumeration but not a
- <code>bool</code> type.
- </td>
- </tr>
- <tr>
- <td>
- <tt>template <class T> struct make_unsigned;</tt>
- </td>
- <td>
- If <code>T</code> names a (possibly cv-qualified)
- <del>unsigned integral type</del><ins>unsigned integer
- type</ins> (3.9.1) then the member typedef <code>type</code>
- shall name the type <code>T</code>; otherwise, if
- <code>T</code> names a (possibly cv-qualified) <del>signed
- integral type</del><ins>signed integer type</ins> then
- <code>type</code> shall name the corresponding <del>unsigned
- integral type</del><ins>unsigned integer type</ins>, with the
- same cv-qualifiers as <code>T</code>; otherwise,
- <code>type</code> shall name the <del>unsigned integral
- type</del><ins>unsigned integer type</ins> with the smallest
- rank (4.13) for which <code>sizeof(T) == sizeof(type)</code>,
- with the same cv-qualifiers as <code>T</code>.
+<p>
+This is only a problem once issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a> is applied.
+</p>
- <i>Requires:</i> <code>T</code> shall be a (possibly
- cv-qualified) integral type or enumeration but not a
- <code>bool</code> type.
- </td>
- </tr>
- </tbody>
- </table>
- </blockquote>
+<p><i>[
+Summit:
+]</i></p>
+<blockquote>
+Move to open. Assign to Lawrence. Related to US 90 comment.
+</blockquote>
- <p>
- Note: I believe that the basefield values should probably be
- prefixed with <tt>ios_base::</tt> as they are in 22.2.2.2.2 [facet.num.put.virtuals]
- The listed virtuals are all overloaded on signed and unsigned integer
- types, the new wording just maintains consistency.
+<p><b>Proposed resolution:</b></p>
+<p>
+Add volatile qualification to the deleted copy-assignment operator of
+all the atomic types:
+</p>
- 22.2.2.1.2 [facet.num.get.virtuals] table 78...
- </p>
- <blockquote>
- Table 78: Integer Conversions
- <table border="1">
- <thead>
- <tr>
- <th>State</th>
- <th><tt>stdio</tt> equivalent</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td><tt>basefield == oct</tt></td>
- <td><tt>%o</tt></td>
- </tr>
- <tr>
- <td><tt>basefield == hex</tt></td>
- <td><tt>%X</tt></td>
- </tr>
- <tr>
- <td><tt>basefield == 0</tt></td>
- <td><tt>%i</tt></td>
- </tr>
- <tr>
- <td><del>signed integral type</del><ins>signed integer
- type</ins></td>
- <td><tt>%d</tt></td>
- </tr>
- <tr>
- <td><del>unsigned integral type</del><ins>unsigned integer
- type</ins></td>
- <td><tt>%u</tt></td>
- </tr>
- </tbody>
- </table>
- </blockquote>
+<blockquote><pre>atomic_bool& operator=(atomic_bool const&) <ins>volatile</ins> = delete;
+atomic_itype& operator=(atomic_itype const&) <ins>volatile</ins> = delete;
+</pre></blockquote>
-
-
- <p>
- Rationale is same as above.
- 22.2.2.2.2 [facet.num.put.virtuals] table 80...
- </p>
- <blockquote>
- Table 80: Integer Conversions
- <table border="1">
- <thead>
- <tr>
- <th>State</th>
- <th><tt>stdio</tt> equivalent</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td><tt>basefield == ios_base::oct</tt></td>
- <td><tt>%o</tt></td>
- </tr>
- <tr>
- <td><tt>(basefield == ios_base::hex) &&
- !uppercase</tt></td>
- <td><tt>%x</tt></td>
- </tr>
- <tr>
- <td><tt>(basefield == ios_base::hex)</tt></td>
- <td><tt>%X</tt></td>
- </tr>
- <tr>
- <td><tt>basefield == 0</tt></td>
- <td><tt>%i</tt></td>
- </tr>
- <tr>
- <td>for a <del>signed integral type</del><ins>signed integer
- type</ins></td>
- <td><tt>%d</tt></td>
- </tr>
- <tr>
- <td>for a <del>unsigned integral type</del><ins>unsigned integer
- type</ins></td>
- <td><tt>%u</tt></td>
- </tr>
- </tbody>
- </table>
- </blockquote>
+<p>
+etc.
+</p>
+<p>
+This will mean that the deleted copy-assignment operator will require
+<i>two</i> conversions in the above example, and thus be a worse match than
+the assignment from plain <tt>bool</tt>.
+</p>
-
- <p>
- 23.1 [container.requirements] table 80...
- </p>
- <blockquote>
- Table 89: Container requirements
- <table border="1">
- <thead>
- <tr>
- <th>expression</th>
- <th>return type</th>
- <th>operational semantics</th>
- <th>assertion/note/pre/post-condition</th>
- <th>complexity</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td><tt>X::difference_type</tt></td>
- <td><del>signed integral type</del><ins>signed integer type</ins></td>
- <td> </td>
- <td>is identical to the difference type of <tt>X::iterator</tt>
- and <tt>X::const_iterator</tt></td>
- <td>compile time</td>
- </tr>
- <tr>
- <td><tt>X::size_type</tt></td>
- <td><del>unsigned integral type</del><ins>unsigned integer type</ins></td>
- <td> </td>
- <td><tt>size_type</tt> can represent any non-negative value of
- <tt>difference_type</tt></td>
- <td>compile time</td>
- </tr>
- </tbody>
- </table>
- </blockquote>
- <p>
- 24.1 [iterator.requirements] paragraph 1...
- </p>
- <blockquote>
- Iterators are a generalization of pointers that allow a C++ program to
- work with different data structures (containers) in a uniform manner.
- To be able to construct template algorithms that work correctly and
- efficiently on different types of data structures, the library
- formalizes not just the interfaces but also the semantics and
- complexity assumptions of iterators. All input iterators
- <code>i</code> support the expression <code>*i</code>, resulting in a
- value of some class, enumeration, or built-in type <code>T</code>,
- called the <i>value type</i> of the iterator. All output iterators
- support the expression <code>*i = o</code> where <code>o</code> is a
- value of some type that is in the set of types that are
- <i>writable</i> to the particular iterator type of <code>i</code>. All
- iterators <code>i</code> for which the expression <code>(*i).m</code>
- is well-defined, support the expression <code>i->m</code> with the
- same semantics as <code>(*i).m</code>. For every iterator type
- <code>X</code> for which equality is defined, there is a corresponding
- <del>signed integral type</del> <ins>signed integer type</ins> called
- the <i>difference type</i> of the iterator.
- </blockquote>
-
- <p>
- I'm a little unsure of this change. Previously this paragraph would
- allow instantiations of <tt>linear_congruential_engine</tt> on
- <tt>char</tt>, <tt>wchar_t</tt>, <tt>bool</tt>, and other types. The
- new wording prohibits this.
- 26.4.3.1 [rand.eng.lcong] paragraph 2...
- </p>
- <blockquote>
- The template parameter <code>UIntType</code> shall denote an
- <del>unsigned integral type</del><ins>unsigned integer type</ins>
- large enough to store values as large as <code>m - 1</code>. If the
- template parameter <code>m</code> is 0, the modulus <code>m</code>
- used throughout this section 26.4.3.1 is
- <code>numeric_limits<result_type>::max()</code> plus 1. [Note:
- The result need not be representable as a value of type
- <code>result_type</code>. --end note] Otherwise, the following
- relations shall hold: <code>a < m</code> and <code>c <
- m</code>.
- </blockquote>
-
- <p>
- Same rationale as the previous change.
- 26.4.4.4 [rand.adapt.xor] paragraph 6...
- </p>
- <blockquote>
- Both <code>Engine1::result_type</code> and
- <code>Engine2::result_type</code> shall denote (possibly different)
- <del>unsigned integral types</del><ins>unsigned integer types</ins>.
- The member <i>result_type</i> shall denote either the type
- <i>Engine1::result_type</i> or the type <i>Engine2::result_type</i>,
- whichever provides the most storage according to clause 3.9.1.
- </blockquote>
-
- <p>
- 26.4.7.1 [rand.util.seedseq] paragraph 7...
- </p>
- <blockquote>
- <i>Requires:</i><code>RandomAccessIterator</code> shall meet the
- requirements of a random access iterator (24.1.5) such that
- <code>iterator_traits<RandomAccessIterator>::value_type</code>
- shall denote an <del>unsigned integral type</del><ins>unsigned integer
- type</ins> capable of accomodating 32-bit quantities.
- </blockquote>
- <p>
- By making this change, integral types that happen to have a signed
- representation, but are not signed integer types, would no longer be
- required to use a two's complement representation. This may go against
- the original intent, and should be reviewed.
- 29.4 [atomics.types.operations] paragraph 24...
- </p>
- <blockquote>
- <i>Remark:</i> For <del>signed integral types</del><ins>signed integer
- types</ins>, arithmetic is defined using two's complement
- representation. There are no undefined results. For address types, the
- result may be an undefined address, but the operations otherwise have
- no undefined behavior.
- </blockquote>
-
-
+
+
+<hr>
+<h3><a name="909"></a>909. <tt>regex_token_iterator</tt> should use <tt>initializer_list</tt></h3>
+<p><b>Section:</b> 28.13.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 319</b></p>
+<p>
+Construction of a <tt>regex_token_iterator</tt> (28.13.2 [re.tokiter]/6+) usually
+requires the provision of a sequence of integer values, which
+can currently be done via a <tt>std::vector<int></tt> or
+a C array of <tt>int</tt>. Since the introduction of <tt>initializer_list</tt> in the
+standard it seems much more reasonable to provide a
+corresponding constructor that accepts an <tt>initializer_list<int></tt>
+instead. This could be done as a pure addition or one could
+even consider replacement. The author suggests the
+replacement strategy (A), but provides an alternative additive
+proposal (B) as a fall-back, because of the handiness of this
+range type:
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We strongly recommend alternative B of the proposed resolution
+in order that existing code not be broken.
+With that understanding, move to Tentatively Ready.
+</blockquote>
+
+<p><b>Original proposed wording:</b></p>
+
+<ol type="A">
+<li><br>
+<ol>
+<li>
+<p>
+In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 change the
+constructor declaration:
+</p>
+
+<blockquote><pre><del>template <std::size_t N></del>
+regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
+ const regex_type& re,
+ <del>const int (&submatches)[N]</del> <ins>initializer_list<int> submatches</ins>,
+ regex_constants::match_flag_type m =
+ regex_constants::match_default);
+</pre></blockquote>
+</li>
+
+<li>
+<p>
+In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence
+</p>
+
+<blockquote>
+The third constructor initializes the member <tt>subs</tt> to hold
+a copy of the sequence of integer values pointed to by the
+iterator range <tt>[<del>&</del>submatches<ins>.begin()</ins>,
+<del>&</del>submatches<ins>.end()</ins> <del>+ N</del>)</tt>.
+</blockquote>
+</li>
+</ol>
+</li>
+
+<li><br>
+<ol>
+<li>
+<p>
+In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 <em>insert</em> the
+following constructor declaration between the already existing ones
+accepting a <tt>std::vector</tt> and a C array of <tt>int</tt>, resp.:
+</p>
+
+<blockquote><pre>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
+ const regex_type& re,
+ initializer_list<int> submatches,
+ regex_constants::match_flag_type m =
+ regex_constants::match_default);
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence
+</p>
+
+<blockquote>
+The third <ins>and fourth</ins> constructor initialize<del>s</del> the member <tt>subs</tt>
+to hold a copy of the sequence of integer values pointed to
+by the iterator range <tt>[&submatches,&submatches + N)</tt>
+<ins>and <tt>[submatches.begin(),submatches.end())</tt>, respectively</ins>.
+</blockquote>
+</li>
+</ol>
+</li>
+
+</ol>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<ol start="2" type="A">
+
+<li><br>
+<ol>
+<li>
+<p>
+In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 <em>insert</em> the
+following constructor declaration between the already existing ones
+accepting a <tt>std::vector</tt> and a C array of <tt>int</tt>, resp.:
+</p>
+
+<blockquote><pre>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
+ const regex_type& re,
+ initializer_list<int> submatches,
+ regex_constants::match_flag_type m =
+ regex_constants::match_default);
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence
+</p>
+
+<blockquote>
+The third <ins>and fourth</ins> constructor initialize<del>s</del> the member <tt>subs</tt>
+to hold a copy of the sequence of integer values pointed to
+by the iterator range <tt>[&submatches,&submatches + N)</tt>
+<ins>and <tt>[submatches.begin(),submatches.end())</tt>, respectively</ins>.
+</blockquote>
+</li>
+</ol>
+</li>
+
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="910"></a>910. Effects of MoveAssignable</h3>
+<p><b>Section:</b> 20.2.9 [concept.copymove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses UK 150</b></p>
+
+<p>
+The description of the effect of <tt>operator=</tt> in the <tt>MoveAssignable</tt>
+concept, given in paragraph 7 is:
+</p>
+
+<blockquote><pre>result_type T::operator=(T&& rv); // inherited from HasAssign<T, T&&>
+</pre>
+
+<blockquote>
+<i>Postconditions:</i> the constructed <tt>T</tt> object is equivalent to the value of
+<tt>rv</tt> before the assignment. [<i>Note:</i> there is no
+requirement on the value of <tt>rv</tt> after the assignment. <i>--end note</i>]
+</blockquote>
+</blockquote>
+
+<p>
+The sentence contains a typo (what is the "constructed <tt>T</tt> object"?)
+probably due to a cut&paste from <tt>MoveConstructible</tt>. Moreover, the
+discussion of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> shows that the postcondition is too generic
+and might not reflect the user expectations. An implementation of the
+move assignment that just calls <tt>swap()</tt> would always fulfill the
+postcondition as stated, but might have surprising side-effects in case
+the source rvalue refers to an object that is not going to be
+immediately destroyed. See LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a> for another example. Due to
+the sometimes intangible nature of the "user expectation", it seems
+difficult to have precise normative wording that could cover all cases
+without introducing unnecessary restrictions. However a non-normative
+clarification could be a very helpful warning sign that swapping is not
+always the correct thing to do.
+</p>
+
+<p><i>[
+2009-05-09 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Issue 910 is exactly the reason BSI advanced the Editorial comment UK-150.
+</p>
+<p>
+The post-conditions after assignment are at a minimum that the object
+referenced by rv must be safely destructible, and the transaction should not
+leak resources. Ideally it should be possible to simply assign rv a new
+valid state after the call without invoking undefined behaviour, but any
+other use of the referenced object would depend upon additional guarantees
+made by that type.
+</p>
+</blockquote>
+
+<p><i>[
+2009-05-09 Howard adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+The intent of the rvalue reference work is that the moved from <tt>rv</tt> is
+a valid object. Not one in a singular state. If, for example, the moved from
+object is a <tt>vector</tt>, one should be able to do anything on that moved-from
+<tt>vector</tt> that you can do with any other <tt>vector</tt>. However you would
+first have to query it to find out what its current state is. E.g. it might have <tt>capacity</tt>,
+it might not. It might have a non-zero <tt>size</tt>, it might not. But regardless,
+you can <tt>push_back</tt> on to it if you want.
+</p>
+
+<p>
+That being said, most standard code is now conceptized. That is, the concepts
+list the only operations that can be done with templated types - whether or not
+the values have been moved from.
+</p>
+
+<p>
+Here is user-written code which must be allowed to be legal:
+</p>
+<blockquote><pre>#include <vector>
+#include <cstdio>
+
+template <class Allocator>
+void
+inspect(std::vector<double, Allocator>&& v)
+{
+ std::vector<double, Allocator> result(move(v));
+ std::printf("moved from vector has %u size and %u capacity\n", v.size(), v.capacity());
+ std::printf("The contents of the vector are:\n");
+ typedef typename std::vector<double, Allocator>::iterator I;
+ for (I i = v.begin(), e = v.end(); i != e; ++i)
+ printf("%f\n", *i);
+}
+
+int main()
+{
+ std::vector<double> v1(100, 5.5);
+ inspect(move(v1));
+}
+</pre></blockquote>
+
+<p>
+The above program does not treat the moved-from <tt>vector</tt> as singular. It
+only treats it as a <tt>vector</tt> with an unknown value.
+</p>
+<p>
+I believe the current proposed wording is consistent with my view on this.
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree that the proposed resolution
+is an improvement over the current wording.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.2.9 [concept.copymove], replace the postcondition in paragraph 7 with:
+</p>
+
+<blockquote>
+<i>Postconditions:</i> <tt>*this</tt> is equivalent to the value of <tt>rv</tt> before the
+assignment. [<i>Note:</i> there is no requirement on the value of <tt>rv</tt> after the
+assignment, but the
+effect should be unsurprising to the user even in case <tt>rv</tt> is not
+immediately destroyed. This may require that resources previously owned
+by <tt>*this</tt> are released instead of transferred to <tt>rv</tt>. <i>-- end note</i>]
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="911"></a>911. I/O streams and <tt>move/swap</tt> semantic</h3>
+<p><b>Section:</b> 27.7.1 [input.streams], 27.7.2 [output.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Class template <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt>
+implements public move constructors, move assignment operators and <tt>swap</tt>
+method and free functions. This might induce both the user and the
+compiler to think that those types are <tt>MoveConstructible</tt>, <tt>MoveAssignable</tt>
+and <tt>Swappable</tt>. However, those class templates fail to fulfill the user
+expectations. For example:
+</p>
+
+<blockquote><pre>std::ostream os(std::ofstream("file.txt"));
+assert(os.rdbuf() == 0); // buffer object is not moved to os, file.txt has been closed
+
+std::vector<std::ostream> v;
+v.push_back(std::ofstream("file.txt"));
+v.reserve(100); // causes reallocation
+assert(v[0].rdbuf() == 0); // file.txt has been closed!
+
+std::ostream&& os1 = std::ofstream("file1.txt");
+os1 = std::ofstream("file2.txt");
+os1 << "hello, world"; // still writes to file1.txt, not to file2.txt!
+
+std::ostream&& os1 = std::ofstream("file1.txt");
+std::ostream&& os2 = std::ofstream("file2.txt");
+std::swap(os1, os2);
+os1 << "hello, world"; // writes to file1.txt, not to file2.txt!
+</pre></blockquote>
+
+<p>
+This is because the move constructor, the move assignment operator and
+<tt>swap</tt> are all implemented through calls to <tt>std::basic_ios</tt> member
+functions <tt>move()</tt> and <tt>swap()</tt> that do not move nor swap the controlled
+stream buffers. That can't happen because the stream buffers may have
+different types.
+</p>
+
+<p>
+Notice that for <tt>basic_streambuf</tt>, the member function <tt>swap()</tt> is
+protected. I believe that is correct and all of <tt>basic_istream</tt>,
+<tt>basic_ostream</tt>, <tt>basic_iostream</tt> should do the same as the move ctor, move
+assignment operator and swap member function are needed by the derived
+<tt>fstream</tt>s and <tt>stringstream</tt>s template. The free swap functions for
+<tt>basic_(i|o|io)stream</tt> templates should be removed for the same reason.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We note that the rvalue swap functions have already been removed.
+</p>
+<p>
+Bill is unsure about making the affected functions protected;
+he believes they may need to be public.
+</p>
+<p>
+We are also unsure about removing the lvalue swap functions as proposed.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+27.7.1.1 [istream]: make the following member functions protected:
+</p>
+
+<blockquote><pre>basic_istream(basic_istream&& rhs);
+basic_istream& operator=(basic_istream&& rhs);
+void swap(basic_istream&& rhs);
+</pre></blockquote>
+
+<p>
+Ditto: remove the three swap free functions signatures
+</p>
+
+<blockquote><pre><del>// swap:
+template <class charT, class traits>
+ void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>& y);
+template <class charT, class traits>
+ void swap(basic_istream<charT, traits>&& x, basic_istream<charT, traits>& y);
+template <class charT, class traits>
+ void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>&& y);</del>
+</pre></blockquote>
+
+<p>
+27.7.1.1.2 [istream.assign]: remove paragraph 4
+</p>
+
+<blockquote><pre><del>template <class charT, class traits>
+ void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>& y);
+template <class charT, class traits>
+ void swap(basic_istream<charT, traits>&& x, basic_istream<charT, traits>& y);
+template <class charT, class traits>
+ void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>&& y);</del>
+</pre>
+<blockquote>
+<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
+</blockquote>
+</blockquote>
+
+<p>
+27.7.1.5 [iostreamclass]: make the following member function protected:
+</p>
+
+<blockquote><pre>basic_iostream(basic_iostream&& rhs);
+basic_iostream& operator=(basic_iostream&& rhs);
+void swap(basic_iostream&& rhs);
+</pre></blockquote>
+
+<p>
+Ditto: remove the three swap free functions signatures
+</p>
+
+<blockquote><pre><del>template <class charT, class traits>
+ void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>& y);
+template <class charT, class traits>
+ void swap(basic_iostream<charT, traits>&& x, basic_iostream<charT, traits>& y);
+template <class charT, class traits>
+ void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>&& y);</del>
+</pre></blockquote>
+
+<p>
+27.7.1.5.3 [iostream.assign]: remove paragraph 3
+</p>
+
+<blockquote><pre><del>template <class charT, class traits>
+ void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>& y);
+template <class charT, class traits>
+ void swap(basic_iostream<charT, traits>&& x, basic_iostream<charT, traits>& y);
+template <class charT, class traits>
+ void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>&& y);</del>
+</pre>
+<blockquote>
+<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
+</blockquote>
+</blockquote>
+
+<p>
+27.7.2.1 [ostream]: make the following member function protected:
+</p>
+
+<blockquote><pre>basic_ostream(basic_ostream&& rhs);
+basic_ostream& operator=(basic_ostream&& rhs);
+void swap(basic_ostream&& rhs);
+</pre></blockquote>
+
+<p>
+Ditto: remove the three swap free functions signatures
+</p>
+
+<blockquote><pre><del>// swap:
+template <class charT, class traits>
+ void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>& y);
+template <class charT, class traits>
+ void swap(basic_ostream<charT, traits>&& x, basic_ostream<charT, traits>& y);
+template <class charT, class traits>
+ void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>&& y);</del>
+</pre></blockquote>
+
+<p>
+27.7.2.3 [ostream.assign]: remove paragraph 13 (The paragraphs seems to
+be misnumbered in the whole section 27.7.2 [output.streams] in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>.
+The paragraph to
+remove is the one that describes the three <tt>swap</tt> free functions).
+</p>
+
+<blockquote><pre><del>template <class charT, class traits>
+ void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>& y);
+template <class charT, class traits>
+ void swap(basic_ostream<charT, traits>&& x, basic_ostream<charT, traits>& y);
+template <class charT, class traits>
+ void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>&& y);</del>
+</pre>
+<blockquote>
+<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="912"></a>912. Array swap needs to be conceptualized</h3>
+<p><b>Section:</b> 25.4.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-01 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.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#Tentatively%20NAD">Tentatively NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+With the adaption of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>
+we have a new algorithm <tt>swap</tt> for C-arrays, which needs to be conceptualized.
+</p>
+
+<p><i>[
+Post Summit Daniel adds:
+]</i></p>
+
+
+<blockquote>
+Recommend as NAD Editorial: The changes have already been applied to the WP
+<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to NAD; the changes have already been made.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Replace in 25.4.3 [alg.swap] before p. 3 until p. 4 by
+</p>
+
+<blockquote><pre>template <<del>class</del> <ins>ValueType</ins> T, size_t N>
+<ins>requires Swappable<T></ins>
+void swap(T (&a)[N], T (&b)[N]);
+</pre>
+<blockquote>
+<p>
+<del><i>Requires:</i> <tt>T</tt> shall be <tt>Swappable</tt>.</del>
+</p>
+<p>
+<i>Effects:</i> <tt>swap_ranges(a, a + N, b);</tt>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="913"></a>913. Superfluous requirements for replace algorithms</h3>
+<p><b>Section:</b> 25.4.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-03 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.replace">active issues</a> in [alg.replace].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+(A) 25.4.5 [alg.replace]/1:
+</p>
+
+<blockquote>
+<i>Requires:</i> The expression <tt>*first = new_value</tt> shall be valid.
+</blockquote>
+
+<p>
+(B) 25.4.5 [alg.replace]/4:
+</p>
+
+<blockquote>
+<i>Requires:</i> The results of the expressions <tt>*first</tt> and <tt>new_value</tt> shall
+be writable to the result output iterator.[..]
+</blockquote>
+
+<p>
+Since conceptualization, the quoted content of these clauses is covered
+by the existing requirements
+</p>
+
+<p>
+(A) <tt>OutputIterator<Iter, const T&></tt>
+</p>
+
+<p>
+and
+</p>
+
+<p>
+(B) <tt>OutputIterator<OutIter, InIter::reference> && OutputIterator<OutIter, const T&></tt>
+</p>
+
+<p>
+resp, and thus should be removed.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the proposed resolution.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<ol type="A">
+<li>
+<p>
+Remove 25.4.5 [alg.replace]/1.
+</p>
+<blockquote><pre>template<ForwardIterator Iter, class T>
+ requires OutputIterator<Iter, Iter::reference>
+ && OutputIterator<Iter, const T&>
+ && HasEqualTo<Iter::value_type, T>
+ void replace(Iter first, Iter last,
+ const T& old_value, const T& new_value);
+
+template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T>
+ requires OutputIterator<Iter, Iter::reference>
+ && OutputIterator<Iter, const T&>
+ && CopyConstructible<Pred>
+ void replace_if(Iter first, Iter last,
+ Pred pred, const T& new_value);
+</pre>
+<blockquote>
+<del>1 <i>Requires:</i> The expression <tt>*first = new_value</tt> shall be valid.</del>
+</blockquote>
+</blockquote>
+</li>
+<li>
+<p>
+25.4.5 [alg.replace]/4: Remove the sentence "The results of the
+expressions <tt>*first</tt> and
+<tt>new_value</tt> shall be writable to the result output iterator.".
+</p>
+<blockquote><pre>template<InputIterator InIter, typename OutIter, class T>
+ requires OutputIterator<OutIter, InIter::reference>
+ && OutputIterator<OutIter, const T&>
+ && HasEqualTo<InIter::value_type, T>
+ OutIter replace_copy(InIter first, InIter last,
+ OutIter result,
+ const T& old_value, const T& new_value);
+
+template<InputIterator InIter, typename OutIter,
+ Predicate<auto, InIter::value_type> Pred, class T>
+ requires OutputIterator<OutIter, InIter::reference>
+ && OutputIterator<OutIter, const T&>
+ && CopyConstructible<Pred>
+ OutIter replace_copy_if(InIter first, InIter last,
+ OutIter result,
+ Pred pred, const T& new_value);
+</pre>
+<blockquote>
+4 <i>Requires:</i> <del>The results of the expressions <tt>*first</tt> and
+<tt>new_value</tt> shall be writable to the <tt>result</tt> output
+iterator.</del> The ranges <tt>[first,last)</tt> and <tt>[result,result +
+(last - first))</tt> shall not overlap.
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="914"></a>914. Superfluous requirement for unique</h3>
+<p><b>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-03 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+25.4.9 [alg.unique]/2: "Requires: The comparison function shall be an
+equivalence relation."
+</p>
+
+<p>
+The essence of this is already covered by the given requirement
+</p>
+
+<blockquote><pre>EquivalenceRelation<auto, Iter::value_type> Pred
+</pre></blockquote>
+
+<p>
+and should thus be removed.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Remove 25.4.9 [alg.unique]/2
+</p>
+
+<blockquote><pre>template<ForwardIterator Iter>
+ requires OutputIterator<Iter, Iter::reference>
+ && EqualityComparable<Iter::value_type>
+ Iter unique(Iter first, Iter last);
+
+template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred>
+ requires OutputIterator<Iter, RvalueOf<Iter::reference>::type>
+ && CopyConstructible<Pred>
+ Iter unique(Iter first, Iter last,
+ Pred pred);
+</pre>
+<blockquote>
+<p>
+1 <i>Effects:</i> ...
+</p>
+<p>
+<del>2 <i>Requires:</i> The comparison function shall be an equivalence relation.</del>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="915"></a>915. <tt>minmax</tt> with <tt>initializer_list</tt> should return
+<tt>pair</tt> of <tt>T</tt>, not <tt>pair</tt> of <tt>const T&</tt></h3>
+<p><b>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#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#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+It seems that the proposed changes for
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a>
+were not clear enough in
+this point:
+</p>
+
+<blockquote>
+25.5.7 [alg.min.max], before p.23 + p.24 + before p. 27 + p. 28 say that the return
+type of the <tt>minmax</tt> overloads with an <tt>initializer_list</tt> is
+<tt>pair<const T&, const T&></tt>,
+which is inconsistent with the decision for the other <tt>min/max</tt> overloads which take
+a <tt>initializer_list</tt> as argument and return a <tt>T</tt>, not a <tt>const T&</tt>.
+Doing otherwise for <tt>minmax</tt> would easily lead to unexpected life-time
+problems by using <tt>minmax</tt> instead of <tt>min</tt> and <tt>max</tt> separately.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+In 25 [algorithms]/2, header <tt><algorithm></tt> synopsis change as indicated:
+</p>
+
+<blockquote><pre>template<<del>class</del><ins>LessThanComparable</ins> T>
+<ins>requires CopyConstructible<T></ins>
+pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>>
+minmax(initializer_list<T> t);
+
+template<class T, <del>class</del><ins>StrictWeakOrder<auto, T></ins> Compare>
+<ins>requires CopyConstructible<T></ins>
+pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>>
+minmax(initializer_list<T> t, Compare comp);
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 25.5.7 [alg.min.max] change as indicated (Begin: Just before p.20):
+</p>
+<blockquote><pre>template<<del>class</del><ins>LessThanComparable</ins> T>
+ <ins>requires CopyConstructible<T></ins>
+ pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>>
+ minmax(initializer_list<T> t);
+</pre>
+<blockquote>
+<p>
+<del>-20- <i>Requires:</i> <tt>T</tt> is <tt>LessThanComparable</tt> and
+<tt>CopyConstructible</tt>.</del>
+</p>
+<p>
+-21- <i>Returns:</i> <tt>pair<<del>const </del>T<del>&</del>, <del>const
+</del>T<del>&</del>>(x, y)</tt> where <tt>x</tt> is the
+smallest value and <tt>y</tt> the largest value in the <tt>initializer_list</tt>.
+</p>
+</blockquote>
+
+<p>[..]</p>
+<pre>template<class T, <del>class</del><ins>StrictWeakOrder<auto, T></ins> Compare>
+ <ins>requires CopyConstructible<T></ins>
+ pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>>
+ minmax(initializer_list<T> t, Compare comp);
+</pre>
+
+<blockquote>
+<p>
+<del>-24- <i>Requires:</i> type <tt>T</tt> is <tt>LessThanComparable</tt> and <tt>CopyConstructible</tt>.</del>
+</p>
+<p>
+-25- <i>Returns:</i> <tt>pair<<del>const </del>T<del>&</del>, <del>const
+</del>T<del>&</del>>(x, y)</tt> where <tt>x</tt> is the
+smallest value and <tt>y</tt> largest value in the <tt>initializer_list</tt>.
+</p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="916"></a>916. Redundant move-assignment operator of <tt>pair</tt> should be removed</h3>
+<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>.</b></p>
+
+<p>
+The current WP provides the following assignment operators for <tt>pair</tt>
+in 20.3.3 [pairs]/1:
+</p>
+
+<ol>
+<li>
+<pre>template<class U , class V>
+requires HasAssign<T1, const U&> && HasAssign<T2, const V&>
+pair& operator=(const pair<U , V>& p);
+</pre>
+</li>
+<li>
+<pre>requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p );
+</pre>
+</li>
+<li>
+<pre>template<class U , class V>
+requires HasAssign<T1, RvalueOf<U>::type> && HasAssign<T2, RvalueOf<V>::type>
+pair& operator=(pair<U , V>&& p);
+</pre>
+</li>
+</ol>
+
+<p>
+It seems that the functionality of (2) is completely covered by (3), therefore
+(2) should be removed.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Bill believes the extra assignment operators are necessary for resolving
+ambiguities, but that does not mean it needs to be part of the specification.
+</p>
+<p>
+Move to Open.
+We recommend this be looked at in the context of the ongoing work
+related to the pair templates.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<ol type="A">
+<li>
+<p>
+In 20.3.3 [pairs] p. 1, class <tt>pair</tt> and just before p. 13 remove the declaration:
+</p>
+
+<blockquote><pre>requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p );
+</pre></blockquote>
+</li>
+
+<li>
+Remove p.13+p.14
+</li>
+
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="917"></a>917. Redundant move-assignment operator of <tt>tuple</tt> should be removed</h3>
+<p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>.</b></p>
+<p>
+N2770 (and thus now the WP) removed the
+non-template move-assignment operator from tuple's class definition,
+but the latter individual member description does still provide this
+operator. Is this (a) an oversight and can it (b) be solved as part of an
+editorial process?
+</p>
+
+<p><i>[
+Post Summit Daniel provided wording.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We believe that the proposed resolution's part 1 is editorial.
+</p>
+<p>
+Regarding part 2, we either remove the specification as proposed,
+or else add back the declaration to which the specification refers.
+Alisdair and Bill prefer the latter.
+It is not immediately obvious whether the function is intended to be present.
+</p>
+<p>
+We recommend that the Project Editor restore the missing declaration
+and that we keep part 2 of the issue alive.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+In 20.5.2 [tuple.tuple], class <tt>tuple</tt> just before member <tt>swap</tt> please
+change as indicated:
+</p>
+<p><i>[
+This fixes an editorial loss between N2798 to N2800
+]</i></p>
+
+<blockquote><pre>template <class... UTypes>
+requires HasAssign<Types, const UTypes&>...
+<ins>tuple& operator=(const pair<UTypes...>&);</ins>
+
+template <class... UTypes>
+requires HasAssign<Types, RvalueOf<UTypes>::type>...
+<ins>tuple& operator=(pair<UTypes...>&&);</ins>
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 20.5.2.1 [tuple.cnstr], starting just before p. 11 please remove
+as indicated:
+</p>
+
+<blockquote><pre><del>requires MoveAssignable<Types>... tuple& operator=(tuple&& u);</del>
+</pre>
+<blockquote>
+<p>
+<del>-11- <i>Effects:</i> Move-assigns each element of <tt>u</tt> to the corresponding
+element of <tt>*this</tt>.</del>
+</p>
+<p>
+<del>-12- <i>Returns:</i> <tt>*this</tt>.</del>
+</p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="918"></a>918. Swap for tuple needs to be conceptualized</h3>
+<p><b>Section:</b> 20.5.2.6 [tuple.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a> was accepted after <tt>tuple</tt> had been conceptualized,
+therefore this step needs to be completed.
+</p>
+
+<p><i>[
+Post Summit Daniel adds
+]</i></p>
+
+
+<blockquote>
+This is now NAD Editorial (addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>)
+except for item 3 in the proposed wording.
+</blockquote>
+
+<p><i>[
+2009-05-01 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+As of the recent WP
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>),
+this issue is now completely covered by editorial
+changes (including the third bullet), therefore I unconditionally recommend
+NAD.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We observed that all the proposed changes have already been applied to the
+Working Draft, rendering this issue moot.
+</p>
+<p>
+Move to NAD.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+In both 20.5.1 [tuple.general]/2 and 20.5.2.7 [tuple.special] change
+</p>
+
+<blockquote><pre>template <<del>class</del> <ins>Swappable</ins>... Types>
+void swap(tuple<Types...>& x, tuple<Types...>& y);
+</pre></blockquote>
+
+</li>
+
+<li>
+<p>
+In 20.5.2 [tuple.tuple], class <tt>tuple</tt> definition and in
+20.5.2.6 [tuple.swap], change
+</p>
+
+<blockquote><pre><ins>requires Swappable<Types>...</ins>void swap(tuple&);
+</pre></blockquote>
+
+</li>
+
+<li>
+<p>
+In 20.5.2.6 [tuple.swap] remove the current requires-clause, which says:
+</p>
+
+<blockquote>
+<del><i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt></del>
+</blockquote>
+</li>
+
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="919"></a>919. (forward_)list specialized remove algorithms are over constrained</h3>
+<p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-06 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The signatures of <tt>forwardlist::remove</tt> and <tt>list::remove</tt>
+defined in 23.3.3.5 [forwardlist.ops] before 11 + 23.3.4.4 [list.ops] before 15:
+</p>
+
+<blockquote><pre>requires EqualityComparable<T> void remove(const T& value);
+</pre></blockquote>
+
+<p>
+are asymmetric to their predicate variants (which only require
+<tt>Predicate</tt>, <em>not</em> <tt>EquivalenceRelation</tt>) and with the free algorithm
+remove (which only require <tt>HasEqualTo</tt>). Also, nothing in the
+pre-concept WP
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
+implies that <tt>EqualityComparable</tt> should
+be the intended requirement.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the proposed resolution,
+but would like additional input from concepts experts.
+</p>
+<p>
+Move to Review.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<ol type="A">
+<li>
+<p>
+Replace in 23.3.3.5 [forwardlist.ops] before 11 and in 23.3.4.4 [list.ops] before 15
+</p>
+
+<blockquote><pre>requires <del>EqualityComparable<T></del> <ins>HasEqualTo<T, T></ins> void remove(const T& value);
+</pre></blockquote>
+</li>
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="920"></a>920. Ref-qualification support in the library</h3>
+<p><b>Section:</b> 20.7.15 [func.memfn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Bronek Kozicki <b>Opened:</b> 2008-10-06 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Daniel Krügler wrote:
+</p>
+
+<blockquote>
+<p>
+Shouldn't above list be completed for &- and &&-qualified
+member functions This would cause to add:
+</p>
+<blockquote><pre>template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) &);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) const &);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) volatile &);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) const volatile &);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) &&);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) const &&);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) volatile &&);
+template<Returnable R, class T, CopyConstructible... Args>
+unspecified mem_fn(R (T::* pm)(Args...) const volatile &&);
+</pre></blockquote>
+
+</blockquote>
+
+<p>
+yes, absolutely. Thanks for spotting this. Without this change <tt>mem_fn</tt>
+cannot be initialized from pointer to ref-qualified member function. I
+believe semantics of such function pointer is well defined.
+</p>
+
+<p><i>[
+Post Summit Daniel provided wording.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We need to think about whether we really want to go down the proposed path
+of combinatorial explosion.
+Perhaps a Note would suffice.
+</p>
+<p>
+We would really like to have an implementation before proceeding.
+</p>
+<p>
+Move to Open, and recommend this be deferred until after the next
+Committee Draft has been issued.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+In 20.7 [function.objects]/2, header <tt><functional></tt> synopsis, just after
+the section "// 20.6.15, member function adaptors::" add the following
+declarations to the existing list:
+</p>
+<blockquote><pre>template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &&);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &&);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &&);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &&);
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 20.7.15 [func.memfn] add the following declarations to the existing
+list:
+</p>
+<blockquote><pre>template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &&);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &&);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &&);
+template<Returnable R, class T, CopyConstructible... Args>
+ <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &&);
+</pre></blockquote>
+</li>
+</ol>
+<p>
+The following text, most notably p.2 and p.3 which discuss influence
+of the cv-qualification on the definition of the base class's first template
+parameter remains unchanged.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="921"></a>921. Rational Arithmetic should use template aliases</h3>
+<p><b>Section:</b> 20.4.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-07 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.ratio">active issues</a> in [ratio.ratio].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The compile-time functions that operate on <tt>ratio<N,D></tt> require the
+cumbersome and error-prone "evaluation" of a <tt>type</tt> member using a
+meta-programming style that predates the invention of template aliases.
+Thus, multiplying three ratios <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> requires the expression:
+</p>
+
+<blockquote><pre>ratio_multiply<a, ratio_multiply<b, c>::type>::type
+</pre></blockquote>
+
+<p>
+The simpler expression:
+</p>
+
+<blockquote><pre>ratio_multiply<a, ratio_multiply<b, c>>
+</pre></blockquote>
+
+<p>
+Could be used by if template aliases were employed in the definitions.
+</p>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Jens: not a complete proposed resolution: "would need to make similar change"
+</p>
+<p>
+Consensus: We agree with the direction of the issue.
+</p>
+<p>
+Recommend Open.
+</p>
+</blockquote>
+
+<p><i>[
+2009-05-11 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Personally I'm <em>not</em> in favor for the addition of:
+</p>
+<blockquote><pre>typedef ratio type;
+</pre></blockquote>
+<p>
+For a reader of the
+standard it's usage or purpose is unclear. I haven't seen similar examples
+of attempts to satisfy non-feature complete compilers.
+</p>
+</blockquote>
+
+<p><i>[
+2009-05-11 Pablo adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+The addition of type to the <tt>ratio</tt> template allows the previous style
+(i.e., in the prototype implementations) to remain valid and permits the
+use of transitional library implementations for C++03 compilers. I do
+not feel strongly about its inclusion, however, and leave it up to the
+reviewers to decide.
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Bill asks for additional discussion in the issue
+that spells out more details of the implementation.
+Howard points us to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>
+which has at least most of the requested details.
+Tom is strongly in favor of overflow-checking at compile time.
+Pete points out that there is no change of functionality implied.
+We agree with the proposed resolution,
+but recommend moving the issue to Review
+to allow time to improve the discussion if needed.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+ <ol start="0">
+<li>
+<p>
+In 20.4 [ratio]/3 change as indicated:
+</p>
+
+<blockquote><pre>// ratio arithmetic
+template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins>;
+template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins>;
+template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins>;
+template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins>;
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 20.4.1 [ratio.ratio], change as indicated:
+</p>
+<blockquote><pre>namespace std {
+ template <intmax_t N, intmax_t D = 1>
+ class ratio {
+ public:
+ <ins>typedef ratio type;</ins>
+ static const intmax_t num;
+ static const intmax_t den;
+ };
+}
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 20.4.2 [ratio.arithmetic] change as indicated:
+</p>
+
+<blockquote><pre>template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins><del>{
+ typedef <em>see below</em> type;
+}</del>;
+</pre>
+
+<blockquote>
+<p>
+1 The <del>nested typedef</del> type <tt><ins>ratio_add<R1, R2></ins></tt>
+shall be a synonym for <tt>ratio<T1, T2></tt>
+where <tt>T1</tt> has the value <tt>R1::num * R2::den + R2::num * R1::den</tt> and <tt>T2</tt>
+has the value <tt>R1::den * R2::den</tt>.
+</p>
+</blockquote>
+</blockquote>
+<blockquote><pre>template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins><del>{
+ typedef <em>see below</em> type;
+}</del>;
+</pre>
+<blockquote>
+<p>
+2 The <del>nested typedef</del> type <tt><ins>ratio_subtract<R1, R2></ins></tt>
+shall be a synonym for <tt>ratio<T1, T2></tt>
+where <tt>T1</tt> has the value <tt>R1::num * R2::den - R2::num * R1::den</tt> and <tt>T2</tt>
+has the value <tt>R1::den * R2::den</tt>.
+</p>
+</blockquote>
+</blockquote>
+<blockquote><pre>template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins><del>{
+ typedef <em>see below</em> type;
+}</del>;
+</pre>
+<blockquote>
+<p>
+3 The <del>nested typedef</del> type <tt><ins>ratio_multiply<R1, R2></ins></tt>
+shall be a synonym for <tt>ratio<T1, T2></tt>
+where <tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>.
+</p>
+</blockquote>
+</blockquote>
+<blockquote><pre>template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins><del>{
+ typedef <em>see below</em> type;
+}</del>;
+</pre>
+<blockquote>
+<p>
+4 The <del>nested typedef</del> type <tt><ins>ratio_divide<R1, R2></ins></tt>
+shall be a synonym for <tt>ratio<T1, T2></tt>
+where <tt>T1</tt> has the value <tt>R1::num * R2::den</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::num</tt>.
+</p>
+</blockquote>
+</blockquote>
+</li>
+<li>
+<p>
+In 20.9.3.1 [time.duration.cons]/4 change as indicated:
+</p>
+<blockquote>
+<p>
+<i>Requires:</i> <tt>treat_as_floating_point<rep>::value</tt> shall be true or
+<tt>ratio_divide<Period2, period>::<del>type::</del>den</tt> shall be 1.[..]
+</p>
+</blockquote>
+</li>
+<li>
+<p>
+In 20.9.3.7 [time.duration.cast]/2 change as indicated:
+</p>
+<blockquote>
+<p>
+<i>Returns:</i> Let CF be <tt>ratio_divide<Period, typename
+ToDuration::period><del>::type</del></tt>, and [..]
+</p>
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="922"></a>922. [func.bind.place] Number of placeholders</h3>
+<p><b>Section:</b> B [implimits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Sohail Somani <b>Opened:</b> 2008-10-11 <b>Last modified:</b> 2009-03-13</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses DE 24</b></p>
+
+<p>
+With respect to the section 20.7.12.1.4 [func.bind.place]:
+</p>
+<p>
+TR1 dropped some suggested implementation quantities for the number of
+placeholders. The purpose of this defect is to put these back for C++0x.
+</p>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+see DE 24
+</p>
+<p>
+Recommend applying the proposed resolution from DE 24, with that
+Tentatively Ready.
+</p>
+</blockquote>
+
+<b>Original proposed resolution:</b>
+
+<p>
+Add 20.7.12.1.4 [func.bind.place]/2:
+</p>
+
+<blockquote>
+While the exact number of placeholders (<tt>_M</tt>) is implementation defined,
+this number shall be at least 10.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Add to B [implimits]:
+</p>
+
+<ul>
+<li>
+Number of placeholders (20.7.12.1.4 [func.bind.place]) [10].
+</li>
+</ul>
+
+
+
+
+
+
+<hr>
+<h3><a name="923"></a>923. atomics with floating-point </h3>
+<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17 <b>Last modified:</b> 2009-05-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Right now, C++0x doesn't have <tt>atomic<float></tt>. We're thinking of adding
+the words to support it for TR2 (note: that would be slightly
+post-C++0x). If we need it, we could probably add the words.
+</p>
+<p>
+<b>Proposed resolutions:</b> Using <tt>atomic<FP>::compare_exchange</tt> (weak or
+strong) should be either:
+</p>
+
+<ol>
+<li>
+ill-formed, or
+</li>
+<li>
+well-defined.
+</li>
+</ol>
+
+<p>
+I propose Option 1 for C++0x for expediency. If someone wants to argue
+for Option 2, they need to say what exactly they want <tt>compare_exchange</tt>
+to mean in this case (IIRC, C++0x doesn't even assume IEEE 754).
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Move to open. Blocked until concepts for atomics are addressed.
+</blockquote>
+
+<p><i>[
+Post Summit Anthony adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Recommend NAD. C++0x does have <tt>std::atomic<float></tt>, and both
+<tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> are well-defined in
+this case. Maybe change the note in 29.6 [atomics.types.operations] paragraph 20 to:
+</p>
+
+<blockquote>
+<p>
+[<i>Note:</i> The effect of the compare-and-exchange operations is
+</p>
+<blockquote><pre>if (!memcmp(object,expected,sizeof(*object)))
+ *object = desired;
+else
+ *expected = *object;
+</pre></blockquote>
+
+<p>
+This may result in failed comparisons for values that compare equal if
+the underlying type has padding bits or alternate representations of
+the same value. <i>-- end note</i>]
+</p>
+</blockquote>
+
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the note in 29.6 [atomics.types.operations] paragraph 20 to:
+</p>
+
+<blockquote>
+<p>
+[<i>Note:</i> The effect of the compare-and-exchange operations is
+</p>
+<blockquote><pre>if (<del>*object == *expected</del> <ins>!memcmp(object,expected,sizeof(*object))</ins>)
+ *object = desired;
+else
+ *expected = *object;
+</pre></blockquote>
+
+<p><ins>
+This may result in failed comparisons for values that compare equal if
+the underlying type has padding bits or alternate representations of
+the same value.</ins> <i>-- end note</i>]
+</p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="924"></a>924. structs with internal padding</h3>
+<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Right now, the <tt>compare_exchange_weak</tt> loop should rapidly converge on the
+padding contents. But <tt>compare_exchange_strong</tt> will require a bit more
+compiler work to ignore padding for comparison purposes.
+</p>
+<p>
+Note that this isn't a problem for structs with no padding, and we do
+already have one portable way to ensure that there is no padding that
+covers the key use cases: Have elements be the same type. I suspect that
+the greatest need is for a structure of two pointers, which has no
+padding problem. I suspect the second need is a structure of a pointer
+and some form of an integer. If that integer is <tt>intptr_t</tt>, there will be
+no padding.
+</p>
+<p>
+Related but separable issue: For unused bitfields, or other unused
+fields for that matter, we should probably say it's the programmer's
+responsibility to set them to zero or otherwise ensure they'll be
+ignored by <tt>memcmp</tt>.
+</p>
+
+<p>
+<b>Proposed resolutions:</b> Using
+<tt>atomic<struct-with-padding>::compare_exchange_strong</tt> should be either:
+</p>
+
+<ol>
+<li>
+ill-formed, or
+</li>
+<li>
+well-defined.
+</li>
+</ol>
+
+<p>
+I propose Option 1 for C++0x for expediency, though I'm not sure how to
+say it. I would be happy with Option 2, which I believe would mean that
+<tt>compare_exchange_strong</tt> would be implemented to avoid comparing padding
+bytes, or something equivalent such as always zeroing out padding when
+loading/storing/comparing. (Either implementation might require compiler
+support.)
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Move to open. Blocked until concepts for atomics are addressed.
+</blockquote>
+
+<p><i>[
+Post Summit Anthony adds:
+]</i></p>
+
+
+<blockquote>
+The resoultion of LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a> should resolve this issue as well.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="925"></a>925. <tt>shared_ptr</tt>'s explicit conversion from <tt>unique_ptr</tt></h3>
+<p><b>Section:</b> 20.8.13.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Rodolfo Lima <b>Opened:</b> 2008-10-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The current working draft
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>),
+section 20.8.13.2.1 [util.smartptr.shared.const] declares
+<tt>shared_ptr</tt>'s constructor that takes a rvalue reference to <tt>unique_ptr</tt> and
+<tt>auto_ptr</tt> as being explicit, affecting several valid smart pointer use
+cases that would take advantage of this conversion being implicit, for
+example:
+</p>
+
+<blockquote><pre>class A;
+std::unique_ptr<A> create();
+void process(std::shared_ptr<A> obj);
+
+int main()
+{
+ process(create()); // use case #1
+ std::unique_ptr<A> uobj = create();
+ process(std::move(uobj)); // use case #2
+ return 0;
+}
+</pre></blockquote>
+
+<p>
+If <tt>unique_ptr</tt> to <tt>shared_ptr</tt> conversions are explicit, the above lines
+should be written:
+</p>
+
+<blockquote><pre>process(std::shared_ptr<A>(create())); // use case #1
+process(std::shared_ptr<A>(std::move(uobj))); // use case #2
+</pre></blockquote>
+
+<p>
+The extra cast required doesn't seems to give any benefits to the user,
+nor protects him of any unintended conversions, this being the raison
+d'etre of explicit constructors.
+</p>
+
+<p>
+It seems that this constructor was made explicit to mimic the conversion
+from <tt>auto_ptr</tt> in pre-rvalue reference days, which accepts both lvalue and
+rvalue references. Although this decision was valid back then, C++0x
+allows the user to express in a clear and non verbose manner when he wants
+move semantics to be employed, be it implicitly (use case 1) or explicitly
+(use case 2).
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Howard and Alisdair like the motivating use cases
+and the proposed resolution.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In both 20.8.13.2 [util.smartptr.shared] paragraph 1 and
+20.8.13.2.1 [util.smartptr.shared.const] change:
+</p>
+
+<blockquote><pre>template <class Y> <del>explicit</del> shared_ptr(auto_ptr<Y> &&r);
+template <class Y, class D> <del>explicit</del> shared_ptr(unique_ptr<Y, D> &&r);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="926"></a>926. Sequentially consistent fences, relaxed operations and modification order</h3>
+<p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-19 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses UK 313</b></p>
+
+<p>
+There was an interesting issue raised over on comp.programming.threads
+today regarding the following example
+</p>
+
+<blockquote><pre>// Thread 1:
+x.store(1, memory_order_relaxed); // SX
+atomic_thread_fence(memory_order_seq_cst); // F1
+y.store(1, memory_order_relaxed); // SY1
+atomic_thread_fence(memory_order_seq_cst); // F2
+r1 = y.load(memory_order_relaxed); // RY
+
+// Thread 2:
+y.store(0, memory_order_relaxed); // SY2
+atomic_thread_fence(memory_order_seq_cst); // F3
+r2 = x.load(memory_order_relaxed); // RX
+</pre></blockquote>
+
+<p>
+is the outcome <tt>r1 == 0</tt> and <tt>r2 == 0</tt> possible?
+</p>
+<p>
+I think the intent is that this is not possible, but I am not sure the
+wording guarantees that. Here is my analysis:
+</p>
+<p>
+Since all the fences are SC, there must be a total order between them.
+<tt>F1</tt> must be before <tt>F2</tt> in that order since they are in
+the same thread. Therefore <tt>F3</tt> is either before <tt>F1</tt>,
+between <tt>F1</tt> and <tt>F2</tt> or after <tt>F2</tt>.
+</p>
+<p>
+If <tt>F3</tt> is <em>after</em> <tt>F2</tt>, then we can apply 29.3 [atomics.order]p5 from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>:
+</p>
+
+<blockquote>
+For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object
+<tt>M</tt>, where <tt>A</tt> modifies <tt>M</tt> and <tt>B</tt> takes
+its value, if there are <tt>memory_order_seq_cst</tt> fences <tt>X</tt>
+and <tt>Y</tt> such that <tt>A</tt> is sequenced before <tt>X</tt>,
+<tt>Y</tt> is sequenced before <tt>B</tt>, and <tt>X</tt> precedes
+<tt>Y</tt> in <tt>S</tt>, then <tt>B</tt> observes either the effects of
+<tt>A</tt> or a later modification of <tt>M</tt> in its modification
+order.
+</blockquote>
+
+<p>
+In this case, <tt>A</tt> is <tt>SX</tt>, <tt>B</tt> is <tt>RX</tt>, the
+fence <tt>X</tt> is <tt>F2</tt> and the fence <tt>Y</tt> is <tt>F3</tt>,
+so <tt>RX</tt> must see 1.
+</p>
+<p>
+If <tt>F3</tt> is <em>before</em> <tt>F2</tt>, this doesn't apply, but
+<tt>F3</tt> can therefore be before or after <tt>F1</tt>.
+</p>
+<p>
+If <tt>F3</tt> is <em>after</em> <tt>F1</tt>, the same logic applies, but this
+time the fence <tt>X</tt> is <tt>F1</tt>. Therefore again, <tt>RX</tt>
+must see 1.
+</p>
+<p>
+Finally we have the case that <tt>F3</tt> is <em>before</em> <tt>F1</tt>
+in the SC ordering. There are now no guarantees about <tt>RX</tt>, and
+<tt>RX</tt> can see <tt>r2==0</tt>.
+</p>
+<p>
+We can apply 29.3 [atomics.order]p5 again. This time,
+<tt>A</tt> is <tt>SY2</tt>, <tt>B</tt> is <tt>RY</tt>, <tt>X</tt> is
+<tt>F3</tt> and <tt>Y</tt> is <tt>F1</tt>. Thus <tt>RY</tt> must observe
+the effects of <tt>SY2</tt> or a later modification of <tt>y</tt> in its
+modification order.
+</p>
+<p>
+Since <tt>SY1</tt> is sequenced before <tt>RY</tt>, <tt>RY</tt> must
+observe the effects of <tt>SY1</tt> or a later modification of
+<tt>y</tt> in its modification order.
+</p>
+<p>
+In order to ensure that <tt>RY</tt> sees <tt>(r1==1)</tt>, we must see
+that <tt>SY1</tt> is later in the modification order of <tt>y</tt> than
+<tt>SY2</tt>.
+</p>
+<p>
+We're now skating on thin ice. Conceptually, <tt>SY2</tt> happens-before
+<tt>F3</tt>, <tt>F3</tt> is SC-ordered before <tt>F1</tt>, <tt>F1</tt>
+happens-before <tt>SY1</tt>, so <tt>SY1</tt> is later in the
+modification order <tt>M</tt> of <tt>y</tt>, and <tt>RY</tt> must see
+the result of <tt>SY1</tt> (<tt>r1==1</tt>). However, I don't think the
+words are clear on that.
+</p>
+
+<p><i>[
+Post Summit Hans adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+In my (Hans') view, our definition of fences will always be weaker than
+what particular hardware will guarantee. <tt>Memory_order_seq_cst</tt> fences
+inherently don't guarantee sequential consistency anyway, for good
+reasons (e.g. because they can't enforce a total order on stores).
+ Hence I don't think the issue demonstrates a gross failure to achieve
+what we intended to achieve. The example in question is a bit esoteric.
+ Hence, in my view, living with the status quo certainly wouldn't be a
+disaster either.
+</p>
+<p>
+In any case, we should probably add text along the lines of the
+following between p5 and p6 in 29.3 [atomics.order]:
+</p>
+<blockquote>
+[Note: <tt>Memory_order_seq_cst</tt> only ensures sequential consistency for a
+data-race-free program that uses exclusively <tt>memory_order_seq_cst</tt>
+operations. Any use of weaker ordering will invalidate this guarantee
+unless extreme care is used. In particular, <tt>memory_order_seq_cst</tt> fences
+only ensure a total order for the fences themselves. They cannot, in
+general, be used to restore sequential consistency for atomic operations
+with weaker ordering specifications.]
+</blockquote>
+
+<p>
+Also see thread beginning at c++std-lib-23271.
+</p>
+
+</blockquote>
+
+<p><i>[
+Herve's correction:
+]</i></p>
+
+<blockquote>
+<p>
+Minor point, and sorry for the knee jerk reaction: I admit to having
+no knowledge of Memory_order_seq_cst, but my former boss (John Lakos)
+has ingrained an automatic introspection on the use of "only". I
+think you meant:
+</p>
+
+<blockquote>
+[Note: <tt>Memory_order_seq_cst</tt> ensures sequential consistency only
+for . . . . In particular, <tt>memory_order_seq_cst</tt> fences ensure a
+total order only for . . .
+</blockquote>
+<p>
+Unless, of course, <tt>Memory_order_seq_cst</tt> really do nothing but ensure
+sequential consistency for a data-race-free program that uses
+exclusively <tt>memory_order_seq_cst</tt> operations.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a new paragraph after 29.3 [atomics.order]p5 that says
+</p>
+
+<blockquote>
+For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object
+<tt>M</tt>, where <tt>A</tt> and <tt>B</tt> modify <tt>M</tt>, if there
+are <tt>memory_order_seq_cst</tt> fences <tt>X</tt> and <tt>Y</tt> such
+that <tt>A</tt> is sequenced before <tt>X</tt>, <tt>Y</tt> is sequenced
+before <tt>B</tt>, and <tt>X</tt> precedes <tt>Y</tt> in <tt>S</tt>,
+then <tt>B</tt> occurs later than <tt>A</tt> in the modifiction order of
+<tt>M</tt>.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="927"></a>927. <tt>Dereferenceable</tt> should be <tt>HasDereference</tt></h3>
+<p><b>Section:</b> 20.8.2.2 [allocator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-23 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+20.8.2.2 [allocator.concepts] contains a reference to a concept named
+<tt>Dereferenceable</tt>. No such concept exists.
+</p>
+
+<p><i>[
+Daniel adds 2009-02-14:
+]</i></p>
+
+
+<blockquote>
+The proposal given in the paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2829.pdf">N2829</a>
+would automatically resolve this issue.
+</blockquote>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+This particular set of changes has already been made.
+There are two related changes later on (and possibly also an earlier Example);
+these can be handled editorially.
+</p>
+<p>
+Move to NAD Editorial.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change all uses of the concept <tt>Dereferenceable</tt> to
+<tt>HasDereference</tt> in 20.8.2.2 [allocator.concepts].
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="928"></a>928. Wrong concepts used for <tt>tuple</tt>'s comparison operators</h3>
+<p><b>Section:</b> 20.5.2.5 [tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2008-10-28 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In the latest working draft for C++0x, <tt>tuple</tt>'s <tt>operator==</tt> and <tt>operator<</tt>
+are declared as
+</p>
+
+<blockquote><pre>template<class... TTypes, class... UTypes>
+ requires EqualityComparable<TTypes, UTypes>...
+ bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
+</pre></blockquote>
+
+<p>
+and
+</p>
+
+<blockquote><pre>template<class... TTypes, class... UTypes>
+ requires LessThanComparable<TTypes, UTypes>...
+ bool operator<(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
+</pre></blockquote>
+
+<p>
+But the concepts <tt>EqualityComparable</tt> and <tt>LessThanComparable</tt> only take one
+parameter, not two. Also, even if <tt>LessThanComparable</tt> could take two
+parameters, the definition of <tt>tuple::operator<()</tt> should also require
+</p>
+
+<blockquote><pre>LessThanComparable<UTypes, TTypes>... // (note the order)
+</pre></blockquote>
+
+<p>
+since the algorithm for <tt>tuple::operator<</tt> is the following (pseudo-code)
+</p>
+
+<blockquote><pre>for (size_t N = 0; N < sizeof...(TTypes); ++N) {
+ if (get<N>(t) < get<N>(u) return true;
+ else if ((get<N>(u) < get<N>(t)) return false;
+}
+
+return false;
+</pre></blockquote>
+
+<p>
+Similar problems hold for <tt>tuples</tt>'s other comparison operators.
+</p>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+Recommend Tentatively Ready.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.5.1 [tuple.general] and 20.5.2.5 [tuple.rel] change:
+</p>
+
+<blockquote><pre>template<class... TTypes, class... UTypes>
+ requires <del>EqualityComparable</del><ins>HasEqualTo</ins><TTypes, UTypes>...
+ bool operator==(const tuple<TTypes...>&, const tuple<UTypes...>&);
+
+template<class... TTypes, class... UTypes>
+ requires <del>LessThanComparable</del><ins>HasLess</ins><TTypes, UTypes>... <ins>&& HasLess<UTypes, TTypes>...</ins>
+ bool operator<(const tuple<TTypes...>&, const tuple<UTypes...>&);
+
+template<class... TTypes, class... UTypes>
+ requires <del>EqualityComparable</del><ins>HasEqualTo</ins><TTypes, UTypes>...
+ bool operator!=(const tuple<TTypes...>&, const tuple<UTypes...>&);
+
+template<class... TTypes, class... UTypes>
+ requires <del>LessThanComparable</del><ins>HasLess</ins><<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types>... <ins>&& HasLess<UTypes, TTypes>...</ins>
+ bool operator>(const tuple<TTypes...>&, const tuple<UTypes...>&);
+
+template<class... TTypes, class... UTypes>
+ requires <del>LessThanComparable</del><ins>HasLess</ins><<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types>... <ins>&& HasLess<UTypes, TTypes>...</ins>
+ bool operator<=(const tuple<TTypes...>&, const tuple<UTypes...>&);
+
+template<class... TTypes, class... UTypes>
+ requires <del>LessThanComparable</del><ins>HasLess</ins><TTypes, UTypes>... <ins>&& HasLess<UTypes, TTypes>...</ins>
+ bool operator>=(const tuple<TTypes...>&, const tuple<UTypes...>&);
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="929"></a>929. Thread constructor</h3>
+<p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-23 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 323</b></p>
+
+<p>
+The <tt>thread</tt> constructor for starting a new thread with a function and
+arguments is overly constrained by the signature requiring rvalue
+references for <tt>func</tt> and <tt>args</tt> and the <tt>CopyConstructible</tt> requirements
+for the elements of <tt>args</tt>. The use of an rvalue reference for the
+function restricts the potential use of a plain function name, since
+the type of the bound parameter will be deduced to be a function
+reference and decay to pointer-to-function will not happen. This
+therefore complicates the implementation in order to handle a simple
+case. Furthermore, the use of rvalue references for args prevents the
+array to pointer decay. Since arrays are not <tt>CopyConstructible</tt> or even
+<tt>MoveConstructible</tt>, this essentially prevents the passing of arrays as
+parameters. In particular it prevents the passing of string literals.
+Consequently a simple case such as
+</p>
+
+<blockquote><pre>void f(const char*);
+std::thread t(f,"hello");
+</pre></blockquote>
+
+<p>
+is ill-formed since the type of the string literal is <tt>const char[6]</tt>.
+</p>
+
+<p>
+By changing the signature to take all parameters by value we can
+eliminate the <tt>CopyConstructible</tt> requirement and permit the use of
+arrays, as the parameter passing semantics will cause the necessary
+array-to-pointer decay. They will also cause the function name to
+decay to a pointer to function and allow the implementation to handle
+functions and function objects identically.
+</p>
+
+<p>
+The new signature of the <tt>thread</tt> constructor for a function and
+arguments is thus:
+</p>
+
+<blockquote><pre>template<typename F,typename... Args>
+thread(F,Args... args);
+</pre></blockquote>
+
+<p>
+Since the parameter pack <tt>Args</tt> can be empty, the single-parameter
+constructor that takes just a function by value is now redundant.
+</p>
+
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I agree with everything Anthony says in this issue. However I believe we
+can optimize in such a way as to get the pass-by-value behavior with the
+pass-by-rvalue-ref performance. The performance difference is that the latter
+removes a <tt>move</tt> when passing in an lvalue.
+</p>
+
+<p>
+This circumstance is very analogous to <tt>make_pair</tt> (20.3.3 [pairs])
+where we started with passing by const reference, changed to pass by value to
+get pointer decay, and then changed to pass by rvalue reference, but modified with
+<tt>decay<T></tt> to retain the pass-by-value behavior. If we were to
+apply the same solution here it would look like:
+</p>
+
+<blockquote><pre><del>template <class F> explicit thread(F f);</del>
+template <class F, class ...Args> thread(F&& f, Args&&... args);
+</pre>
+<blockquote>
+<p>
+-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
+if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
+<tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for
+some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
+</p>
+<p>
+-5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
+<del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
+thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
+<ins>Constructs
+the following objects in memory which is accessible to a new thread of execution
+as if:</ins>
+</p>
+<blockquote><pre><ins>typename decay<F>::type g(std::forward<F>(f));</ins>
+<ins>tuple<typename decay<Args>::type...> w(std::forward<Args>(args)...);</ins>
+</pre></blockquote>
+<p>
+<ins>The new thread of
+execution executes <tt><i>INVOKE</i>(g, wi...)</tt> where the <tt>wi...</tt> refers
+to the elements stored in the <tt>tuple w</tt>.</ins>
+Any return value from <tt>g</tt> is ignored.
+<del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
+<ins>If the evaluation of <tt><i>INVOKE</i>(g, wi...)</tt> terminates
+with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
+<tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
+exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
+catchable in the calling thread.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Text referring to when <tt>terminate()</tt> is called was contributed by Ganesh.
+</p>
+
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution,
+but would like the final sentence to be reworded
+since "catchable" is not a term of art (and is used nowhere else).
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Modify the class definition of <tt>std::thread</tt> in 30.3.1 [thread.thread.class] to remove the
+following signature:
+</p>
+
+<blockquote><pre><del>template<class F> explicit thread(F f);</del>
+template<class F, class ... Args> <ins>explicit</ins> thread(F&& f, Args&& ... args);
+</pre></blockquote>
+
+<p>
+Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with
+the single constructor as above. Replace paragraph 4 - 6 with the
+following:
+</p>
+
+<blockquote>
+<p>
+-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
+if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
+<tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for
+some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
+</p>
+<p>
+-5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
+<del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
+thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
+<ins>Constructs
+the following objects:</ins>
+</p>
+<blockquote><pre><ins>typename decay<F>::type g(std::forward<F>(f));</ins>
+<ins>tuple<typename decay<Args>::type...> w(std::forward<Args>(args)...);</ins>
+</pre></blockquote>
+<p>
+<ins>and executes <tt><i>INVOKE</i>(g, wi...)</tt> in a new thread of execution.
+These objects shall be destroyed when the new thread of execution completes.</ins>
+Any return value from <tt>g</tt> is ignored.
+<del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
+<ins>If the evaluation of <tt><i>INVOKE</i>(g, wi...)</tt> terminates
+with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
+<tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
+exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
+catchable in the calling thread.</ins>
+</p>
+<p>
+-6- <i>Synchronization:</i> The invocation of the constructor <i>happens before</i> the
+invocation of <del><tt>f</tt></del> <ins><tt>g</tt></ins>.
+</p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="930"></a>930. Access to std::array data as built-in array type</h3>
+<p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-11-17 <b>Last modified:</b> 2009-06-01</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 Working Draft (N2798) allows access to the elements of
+<tt>std::array</tt> by its <tt>data()</tt> member function:
+</p>
+
+<blockquote>
+
+<h5>23.2.1.4 array::data [array.data]</h5>
+<pre> T *data();
+ const T *data() const;
+</pre>
+<ol><li>
+ Returns: elems.
+</li></ol>
+</blockquote>
+
+<p>
+Unfortunately, the result of <tt>std::array::data()</tt> cannot be bound
+to a reference to a built-in array of the type of <tt>array::elems</tt>.
+And <tt>std::array</tt> provides no other way to get a reference to
+<tt>array::elems</tt>.
+This hampers the use of <tt>std::array</tt>, for example when trying to
+pass its data to a C style API function:
+</p>
+
+<pre> // Some C style API function.
+ void set_path( char (*)[MAX_PATH] );
+
+ std::array<char,MAX_PATH> path;
+ set_path( path.data() ); // error
+ set_path( &(path.data()) ); // error
+</pre>
+
+ <p>
+Another example, trying to pass the array data to an instance of another
+C++ class:
+</p>
+
+<pre> // Represents a 3-D point in space.
+ class three_d_point {
+ public:
+ explicit three_d_point(const double (&)[3]);
+ };
+
+ const std::array<double,3> coordinates = { 0, 1, 2 };
+ three_d_point point1( coordinates.data() ); // error.
+ three_d_point point2( *(coordinates.data()) ); // error.
+</pre>
+
+<p>
+A user might be tempted to use <tt>std::array::elems</tt> instead, but
+doing so isn't recommended, because <tt>std::array::elems</tt> is "for
+exposition only". Note that Boost.Array users might already use
+<tt>boost::array::elems</tt>, as its documentation doesn't explicitly
+state that <tt>boost::array::elems</tt> is for exposition only:
+http://www.boost.org/doc/libs/1_36_0/doc/html/boost/array.html
+</p>
+<p>
+I can think of three options to solve this issue:
+</p>
+<ol><li>
+Remove the words "exposition only" from the definition of
+<tt>std::array::elems</tt>, as well as the note saying that "elems is
+shown for exposition only."
+</li><li>
+Change the signature of <tt>std::array::data()</tt>, so that it would
+return a reference to the built-in array, instead of a pointer to its
+first element.
+</li><li>
+Add extra member functions, returning a reference to the built-in array.
+</li></ol>
+<p>
+Lawrence Crowl wrote me that it might be better to leave
+<tt>std::array::elems</tt> "for exposition only", to allow alternate
+representations to allocate the array data dynamically. This might be
+of interest to the embedded community, having to deal with very limited
+stack sizes.
+</p>
+<p>
+The second option, changing the return type of
+<tt>std::array::data()</tt>, would break backward compatible to current
+Boost and TR1 implementations, as well as to the other contiguous
+container (<tt>vector</tt> and <tt>string</tt>) in a very subtle way.
+For example, the following call to <tt>std::swap</tt> currently swap two
+locally declared pointers <tt>(data1, data2)</tt>, for any container
+type <tt>T</tt> that has a <tt>data()</tt> member function. When
+<tt>std::array::data()</tt> is changed to return a reference, the
+<tt>std::swap</tt> call may swap the container elements instead.
+</p>
+
+<pre> template <typename T>
+ void func(T& container1, T& container2)
+ {
+ // Are data1 and data2 pointers or references?
+ auto data1 = container1.data();
+ auto data2 = container2.data();
+
+ // Will this swap two local pointers, or all container elements?
+ std::swap(data1, data2);
+ }
+</pre>
+
+<p>
+The following concept is currently satisfied by all contiguous
+containers, but it no longer is for <tt>std::array</tt>, when
+<tt>array::data()</tt>
+is changed to return a reference (tested on ConceptGCC Alpha 7):
+</p>
+
+<pre> auto concept ContiguousContainerConcept<typename T>
+ {
+ typename value_type = typename T::value_type;
+ const value_type * T::data() const;
+ }
+</pre>
+
+<p>
+Still it's worth considering having <tt>std::array::data()</tt> return a
+reference, because it might be the most intuitive option, from a user's
+point of view. Nicolai Josuttis (who wrote <tt>boost::array</tt>)
+mailed me that he very much prefers this option.
+</p>
+<p>
+Note that for this option, the definition of <tt>data()</tt> would also
+need to be revised for zero-sized arrays, as its return type cannot be a
+reference to a zero-sized built-in array. Regarding zero-sized array,
+<tt>data()</tt> could throw an exception. Or there could be a partial
+specialization of <tt>std::array</tt> where <tt>data()</tt> returns
+<tt>T*</tt> or gets removed.
+</p>
+<p>
+Personally I prefer the third option, adding a new member function to
+<tt>std::array</tt>, overloaded for const and non-const access,
+returning a reference to the built-in array, to avoid those compatible
+issues. I'd propose naming the function <tt>std::array::c_array()</tt>,
+which sounds intuitive to me. Note that <tt>boost::array</tt> already
+has a <tt>c_array()</tt> member, returning a pointer, but Nicolai told
+me that this one is only there for historical reasons. (Otherwise a name
+like <tt>std::array::native_array()</tt> or
+<tt>std::array::builtin_array()</tt> would also be fine with me.)
+According to my proposed resolution, a zero-sized <tt>std::array</tt> does not need
+to have <tt>c_array()</tt>, while it is still required to have
+<tt>data()</tt> functions.
+</p>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+
+<p>
+Alisdair: Don't like p4 suggesting implementation-defined behaviour.
+</p>
+<p>
+Walter: What about an explicit conversion operator, instead of adding
+the new member function?
+</p>
+<p>
+Alisdair: Noodling about:
+</p>
+<blockquote><pre>template<size_t N, ValueType T>
+struct array
+{
+ T elems[N];
+
+// fantasy code starts here
+
+// crazy decltype version for grins only
+//requires True<(N>0)>
+//explict operator decltype(elems) & () { return elems; }
+
+// conversion to lvalue ref
+requires True<(N>0)>
+explict operator T(&)[N] () & { return elems; }
+
+// conversion to const lvalue ref
+requires True<(N>0)>
+explict operator const T(&)[N] () const & { return elems; }
+
+// conversion to rvalue ref using ref qualifiers
+requires True<(N>0)>
+explict operator T(&&)[N] () && { return elems; }
+
+// fantasy code ends here
+
+explicit operator bool() { return true; }
+};
+</pre></blockquote>
+
+<p>
+This seems legal but odd. Jason Merrill says currently a CWG issue 613
+on the non-static data member that fixes the error that current G++
+gives for the non-explicit, non-conceptualized version of this. Verdict
+from human compiler: seems legal.
+</p>
+<p>
+Some grumbling about zero-sized arrays being allowed and supported.
+</p>
+<p>
+Walter: Would this address the issue? Are we inclined to go this route?
+</p>
+<p>
+Alan: What would usage look like?
+</p>
+<blockquote><pre>// 3-d point in space
+struct three_d_point
+{
+ explicit three_d_point(const double (&)[3]);
+};
+
+void sink(double*);
+
+const std::array<double, 3> coordinates = { 0, 1, 2 };
+three_d_point point1( coordinates.data() ); //error
+three_d_point point2( *(coordinates.data()) ); // error
+three_d_point point3( coordinates ); // yay!
+
+sink(cooridinates); // error, no conversion
+</pre></blockquote>
+
+<p>
+Recommended Open with new wording. Take the required clause and add the
+explicit conversion operators, not have a <tt>typedef</tt>. At issue still is use
+<tt>decltype</tt> or use <tt>T[N]</tt>. In favour of using <tt>T[N]</tt>, even though use of
+<tt>decltype</tt> is specially clever.
+</p>
+
+</blockquote>
+
+<p><i>[
+Post Summit, further discussion in the thread starting with c++std-lib-23215.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to the template definition of array, 23.3.1 [array]/3:
+</p>
+
+<blockquote>
+<pre><ins>
+typedef T c_array_type[N];
+c_array_type & c_array() &;
+c_array_type && c_array() &&;
+const c_array_type & c_array() const &;
+</ins>
+</pre>
+</blockquote>
+
+<p>
+Add the following subsection to 23.3.1 [array], after 23.3.1.4 [array.data]:
+</p>
+
+<blockquote>
+<h5><ins>23.2.1.5 array::c_array [array.c_array]</ins></h5>
+ <pre><ins>
+c_array_type & c_array() &;
+c_array_type && c_array() &&;
+const c_array_type & c_array() const &;
+</ins></pre>
+<blockquote>
+<p>
+<ins><i>Returns:</i> <tt>elems</tt>.</ins>
+</p>
+</blockquote>
+
+</blockquote>
+
+<p>
+Add to Zero sized arrays 23.3.1.6 [array.zero]:
+</p>
+
+<blockquote>
+4. The presence of <tt>c_array_type</tt> and <tt>c_array()</tt> and
+their semantics are implementation defined, for a zero-sized array.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="931"></a>931. type trait <tt>extent<T, I></tt></h3>
+<p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Yechezkel Mett <b>Opened:</b> 2008-11-04 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The draft (N2798) says in 20.6.4.3 [meta.unary.prop] Table 44:
+</p>
+<blockquote>
+<table border="1">
+<caption>Table 44 -- Type property queries</caption>
+<tbody><tr><th>Template</th><th>Value</th></tr>
+<tr>
+<td>
+<tt>template <class T, unsigned I = 0> struct extent;</tt>
+</td>
+<td>
+If <tt>T</tt> is not an array type (8.3.4), or if it has rank less than
+<tt>I</tt>, or if <tt>I</tt> is 0
+and <tt>T</tt> has type "array of unknown bound of <tt>U</tt>", then 0; otherwise, the
+size of the <tt>I</tt>'th dimension of <tt>T</tt>
+</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+<p>
+Firstly it isn't clear from the wording if <tt>I</tt> is 0-based or 1-based
+("the <tt>I</tt>'th dimension" sort of implies 1-based). From the following
+example it is clear that the intent is 0-based, in which case it
+should say "or if it has rank less than or equal to <tt>I</tt>".
+</p>
+<p>
+Sanity check:
+</p>
+<p>
+The example says <tt>assert((extent<int[2], 1>::value) == 0);</tt>
+</p>
+<p>
+Here the rank is 1 and <tt>I</tt> is 1, but the desired result is 0.
+</p>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Do not use "size" or "value", use "bound". Also, move the
+cross-reference to 8.3.4 to just after "bound".
+</p>
+<p>
+Recommend Tentatively Ready.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In Table 44 of 20.6.4.3 [meta.unary.prop], third row, column "Value",
+change the cell content:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 44 -- Type property queries</caption>
+<tbody><tr><th>Template</th><th>Value</th></tr>
+<tr>
+<td>
+<tt>template <class T, unsigned I = 0> struct extent;</tt>
+</td>
+<td>
+If <tt>T</tt> is not an array type <del>(8.3.4)</del>, or if it has rank less than
+<ins> or equal to</ins> <tt>I</tt>, or if <tt>I</tt> is 0
+and <tt>T</tt> has type "array of unknown bound of <tt>U</tt>", then 0; otherwise, the
+<del>size</del> <ins>bound (8.3.4)</ins> of the <tt>I</tt>'th dimension of <tt>T</tt><ins>,
+where indexing of <tt>I</tt> is zero-based.</ins>
+</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+<p><i>[
+Wording supplied by Daniel.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="932"></a>932. <tt>unique_ptr(pointer p)</tt> for pointer deleter types</h3>
+<p><b>Section:</b> 20.8.12.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-11-26 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses US 79</b></p>
+
+<p>
+20.8.12.2.1 [unique.ptr.single.ctor]/5 no longer requires for <tt>D</tt>
+not to be a pointer type. I believe this restriction was accidently removed
+when we relaxed the completeness reuqirements on <tt>T</tt>. The restriction
+needs to be put back in. Otherwise we have a run time failure that could
+have been caught at compile time:
+</p>
+
+<blockquote><pre>{
+unique_ptr<int, void(*)(void*)> p1(malloc(sizeof(int))); <font color="#c80000">// should not compile</font>
+} <font color="#c80000">// p1.~unique_ptr() dereferences a null function pointer</font>
+unique_ptr<int, void(*)(void*)> p2(malloc(sizeof(int)), free); <font color="#c80000">// ok</font>
+</pre></blockquote>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+Recommend Tentatively Ready.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.8.12.2.1 [unique.ptr.single.ctor]/5:
+</p>
+
+<blockquote><pre>unique_ptr(pointer p);
+</pre>
+<blockquote>
+<i>Requires:</i> <ins><tt>D</tt> shall not be a pointer type (diagnostic required).</ins>
+<tt>D</tt> shall be default constructible, and that construction shall not throw an exception.
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="933"></a>933. Unique_ptr defect</h3>
+<p><b>Section:</b> 20.8.12.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-11-27 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.modifiers">active issues</a> in [unique.ptr.single.modifiers].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+If we are supporting stateful deleters, we need an overload for
+<tt>reset</tt> that
+takes a deleter as well.
+</p>
+
+<blockquote><pre>void reset( pointer p, deleter_type d);
+</pre></blockquote>
+
+<p>
+We probably need two overloads to support move-only deleters, and
+this
+sounds uncomfortably like the two constructors I have been ignoring
+for
+now...
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Howard comments that we have the functionality via move-assigment.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="934"></a>934. <tt>duration</tt> is missing <tt>operator%</tt></h3>
+<p><b>Section:</b> 20.9.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Terry Golubiewski <b>Opened:</b> 2008-11-30 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses US 81</b></p>
+
+<p>
+<tt>duration</tt> is missing <tt>operator%</tt>. This operator is convenient
+for computing where in a time frame a given <tt>duration</tt> lies. A
+motivating example is converting a <tt>duration</tt> into a "broken-down"
+time duration such as hours::minutes::seconds:
+</p>
+
+<blockquote><pre>class ClockTime
+{
+ typedef std::chrono::hours hours;
+ typedef std::chrono::minutes minutes;
+ typedef std::chrono::seconds seconds;
+public:
+ hours hours_;
+ minutes minutes_;
+ seconds seconds_;
+
+ template <class Rep, class Period>
+ explicit ClockTime(const std::chrono::duration<Rep, Period>& d)
+ : hours_ (std::chrono::duration_cast<hours> (d)),
+ minutes_(std::chrono::duration_cast<minutes>(d % hours(1))),
+ seconds_(std::chrono::duration_cast<seconds>(d % minutes(1)))
+ {}
+};
+</pre></blockquote>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree except that there is a typo in the proposed resolution. The member
+operators should be operator%=.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to the synopsis in 20.9 [time]:
+</p>
+
+<blockquote><pre>template <class Rep1, class Period, class Rep2>
+ duration<typename common_type<Rep1, Rep2>::type, Period>
+ operator%(const duration<Rep1, Period>& d, const Rep2& s);
+template <class Rep1, class Period1, class Rep2, class Period2>
+ typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type
+ operator%(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs);
+</pre></blockquote>
+
+<p>
+Add to the synopsis of <tt>duration</tt> in 20.9.3 [time.duration]:
+</p>
+
+<blockquote><pre>template <class Rep, class Period = ratio<1>>
+class duration {
+public:
+ ...
+ <ins>duration& operator%=(const rep& rhs);</ins>
+ <ins>duration& operator%=(const duration& d);</ins>
+ ...
+};
+</pre></blockquote>
+
+<p>
+Add to 20.9.3.3 [time.duration.arithmetic]:
+</p>
+
+<blockquote>
+<pre>duration& operator%=(const rep& rhs);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> <tt>rep_ %= rhs</tt>.
+</p>
+<p>
+<i>Returns:</i> <tt>*this</tt>.
+</p>
+</blockquote>
+
+<pre>duration& operator%=(const duration& d);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> <tt>rep_ %= d.count()</tt>.
+</p>
+<p>
+<i>Returns:</i> <tt>*this</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Add to 20.9.3.5 [time.duration.nonmember]:
+</p>
+
+<blockquote>
+
+<pre>template <class Rep1, class Period, class Rep2>
+ duration<typename common_type<Rep1, Rep2>::type, Period>
+ operator%(const duration<Rep1, Period>& d, const Rep2& s);
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> <tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt> and
+<tt>Rep2</tt> shall not be an instantiation of <tt>duration</tt>. Diagnostic required.
+</p>
+<p>
+<i>Returns:</i> <tt>duration<CR, Period>(d) %= s</tt>.
+</p>
+</blockquote>
+
+<pre>template <class Rep1, class Period1, class Rep2, class Period2>
+ typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type
+ operator%(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs);
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type(lhs) %= rhs</tt>.
+</p>
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="935"></a>935. clock error handling needs to be specified</h3>
+<p><b>Section:</b> 20.9.5 [time.clock] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-11-24 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Each of the three clocks specified in Clocks 20.9.5 [time.clock]
+provides the member function:
+</p>
+
+<blockquote><pre>static time_point now();
+</pre></blockquote>
+
+<p>
+The semantics specified by Clock requirements 20.9.1 [time.clock.req]
+make no mention of error handling. Thus the function may throw <tt>bad_alloc</tt>
+or an implementation-defined exception (17.6.4.10 [res.on.exception.handling]
+paragraph 4).
+</p>
+
+<p>
+Some implementations of these functions on POSIX, Windows, and
+presumably on other operating systems, may fail in ways only detectable
+at runtime. Some failures on Windows are due to supporting chipset
+errata and can even occur after successful calls to a clock's <tt>now()</tt>
+function.
+</p>
+
+<p>
+These functions are used in cases where exceptions are not appropriate
+or where the specifics of the exception or cause of error need to be
+available to the user. See
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
+<i>Library Support for hybrid error
+handling (Rev 1)</i>, for more specific discussion of use cases. Thus some change in
+the interface of now is required.
+</p>
+
+<p>
+The proposed resolution has been implemented in the Boost version of the
+chrono library. No problems were encountered.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We recommend this issue be deferred until the next Committee Draft
+has been issued and the prerequisite paper has been accepted.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Accept the proposed wording of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
+<i>Library Support for hybrid error handling (Rev 1)</i>.
+</p>
+
+<p>
+Change Clock requirements 20.9.1 [time.clock.req] as indicated:
+</p>
+
+<blockquote>
+<p>
+-2- In Table 55 <tt>C1</tt> and <tt>C2</tt> denote clock types. <tt>t1</tt> and
+<tt>t2</tt> are values returned by <tt>C1::now()</tt> where the call
+returning <tt>t1</tt> happens before (1.10) the call returning <tt>t2</tt> and
+both of these calls happen before <tt>C1::time_point::max()</tt>.
+<ins><tt>ec</tt> denotes an object of type <tt>error_code</tt>
+(19.5.2.2 [syserr.errcode.overview]).</ins>
+</p>
+
+<table border="1">
+<caption>Table 55 -- Clock requirements</caption>
+<tbody><tr>
+<th>Expression</th><th>Return type</th><th>Operational semantics</th>
+</tr>
+
+<tr>
+<td>...</td>
+<td>...</td>
+<td>...</td>
+</tr>
+
+<tr>
+<td><tt>C1::now()</tt></td>
+<td><tt>C1::time_point</tt></td>
+<td>Returns a <tt>time_point</tt> object representing the current point in time.
+</td>
+</tr>
+
+<tr>
+<td><tt><ins>C1::now(ec)</ins></tt></td>
+<td><tt><ins>C1::time_point</ins></tt></td>
+<td><ins>Returns a <tt>time_point</tt> object representing the current point in time.</ins>
+</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+<p>
+Change Class system_clock 20.9.5.1 [time.clock.system] as indicated:
+</p>
+
+<blockquote><pre>static time_point now(<ins>error_code& ec=throws()</ins>);
+</pre></blockquote>
+
+<p>
+Change Class monotonic_clock 20.9.5.2 [time.clock.monotonic] as indicated:
+</p>
+
+<blockquote><pre>static time_point now(<ins>error_code& ec=throws()</ins>);
+</pre></blockquote>
+
+<p>
+Change Class high_resolution_clock 20.9.5.3 [time.clock.hires] as indicated:
+</p>
+
+<blockquote><pre>static time_point now(<ins>error_code& ec=throws()</ins>);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="936"></a>936. Mutex type overspecified</h3>
+<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-05 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+30.4.1 [thread.mutex.requirements] describes the requirements for a type to be
+a "Mutex type". A Mutex type can be used as the template argument for
+the <tt>Lock</tt> type that's passed to <tt>condition_variable_any::wait</tt> (although
+<tt>Lock</tt> seems like the wrong name here, since <tt>Lock</tt> is given a different
+formal meaning in 30.4.3 [thread.lock]) and, although the WD doesn't quite say
+so, as the template argument for <tt>lock_guard</tt> and <tt>unique_lock</tt>.
+</p>
+
+<p>
+The requirements for a Mutex type include:
+</p>
+
+<ul>
+<li>
+<tt>m.lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
+</li>
+<li>
+<tt>m.try_lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>bool</tt>.
+</li>
+<li>
+<tt>m.unlock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
+</li>
+</ul>
+
+<p>
+Also, a Mutex type "shall not be copyable nor movable".
+</p>
+
+<p>
+The latter requirement seems completely irrelevant, and the three
+requirements on return types are tighter than they need to be. For
+example, there's no reason that <tt>lock_guard</tt> can't be instantiated with a
+type that's copyable. The rule is, in fact, that <tt>lock_guard</tt>, etc. won't
+try to copy objects of that type. That's a constraint on locks, not on
+mutexes. Similarly, the requirements for <tt>void</tt> return types are
+unnecessary; the rule is, in fact, that <tt>lock_guard</tt>, etc. won't use any
+returned value. And with the return type of <tt>bool</tt>, the requirement should
+be that the return type is convertible to <tt>bool</tt>.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Move to open. Related to conceptualization and should probably be tackled as part of that.
+</p>
+<ul>
+<li>
+The intention is not only to place a constraint on what types such as
+<tt>lock_guard</tt> may do with mutex types, but on what any code, including user
+code, may do with mutex types. Thus the constraints as they are apply to
+the mutex types themselves, not the current users of mutex types in the
+standard.
+</li>
+<li>
+This is a low priority issue; the wording as it is may be overly
+restrictive but this may not be a real issue.
+</li>
+</ul>
+</blockquote>
+
+<p><i>[
+Post Summit Anthony adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Section 30.4.1 [thread.mutex.requirements] conflates the
+requirements on a generic Mutex type (including user-supplied mutexes)
+with the requirements placed on the standard-supplied mutex types in an
+attempt to group everything together and save space.
+</p>
+<p>
+When applying concepts to chapter 30, I suggest that the concepts
+<tt>Lockable</tt> and <tt>TimedLockable</tt> embody the requirements for
+*use* of a mutex type as required by
+<tt>unique_lock/lock_guard/condition_variable_any</tt>. These should be
+relaxed as Pete describes in the issue. The existing words in 30.4.1 [thread.mutex.requirements] are requirements on all of
+<tt>std::mutex</tt>, <tt>std::timed_mutex</tt>,
+<tt>std::recursive_mutex</tt> and <tt>std::recursive_timed_mutex</tt>,
+and should be rephrased as such.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="938"></a>938. <tt>default_delete<T[]>::operator()</tt> should only accept <tt>T*</tt></h3>
+<p><b>Section:</b> 20.8.12.1.2 [unique.ptr.dltr.dflt1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-12-07 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Consider:
+</p>
+
+<blockquote><pre>derived* p = new derived[3];
+std::default_delete<base[]> d;
+d(p); <font color="#c80000">// should fail</font>
+</pre></blockquote>
+
+<p>
+Currently the marked line is a run time failure. We can make it a compile
+time failure by "poisoning" <tt>op(U*)</tt>.
+</p>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+Recommend Review.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to 20.8.12.1.2 [unique.ptr.dltr.dflt1]:
+</p>
+
+<blockquote><pre>namespace std {
+ template <class T> struct default_delete<T[]> {
+ void operator()(T*) const;
+ <ins>template <class U> void operator()(U*) const = delete;</ins>
+};
+}
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="939"></a>939. Problem with <tt>std::identity</tt> and reference-to-temporaries</h3>
+<p><b>Section:</b> 20.7.6 [identity.operation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-12-11 <b>Last modified:</b> 2009-06-02</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>std::identity</tt> takes an argument of type <tt>T const &</tt>
+and returns a result of <tt>T const &</tt>.
+</p>
+<p>
+Unfortunately, this signature will accept a value of type other than <tt>T</tt> that
+is convertible-to-<tt>T</tt>, and then return a reference to the dead temporary. The
+constraint in the concepts version simply protects against returning
+reference-to-<tt>void</tt>.
+</p>
+<p>
+Solutions:
+</p>
+<blockquote>
+<p>
+i/ Return-by-value, potentially slicing bases and rejecting non-copyable
+types
+</p>
+<p>
+ii/ Provide an additional overload:
+</p>
+<blockquote><pre>template< typename T >
+template operator( U & ) = delete;
+</pre></blockquote>
+<p>
+This seems closer on intent, but moves beyond the original motivation for
+the operator, which is compatibility with existing (non-standard)
+implementations.
+</p>
+<p>
+iii/ Remove the <tt>operator()</tt> overload. This restores the original definition
+of the <tt>identity</tt>, although now effectively a type_trait rather than part of
+the perfect forwarding protocol.
+</p>
+<p>
+iv/ Remove <tt>std::identity</tt> completely; its original reason to exist is
+replaced with the <tt>IdentityOf</tt> concept.
+</p>
+</blockquote>
+<p>
+My own preference is somewhere between (ii) and (iii) - although I stumbled
+over the issue with a specific application hoping for resolution (i)!
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We dislike options i and iii, and option ii seems like overkill.
+If we remove it (option iv), implementers can still provide it under a
+different name.
+</p>
+<p>
+Move to Open pending wording (from Alisdair) for option iv.
+</p>
+</blockquote>
+
+<p><i>[
+2009-05-23 Alisdair provided wording for option iv.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Strike 20.2.1 [concept.transform] p3:
+</p>
+
+<blockquote>
+<del>-4- <i>Note:</i> concept form of the identity type metafunction (20.7.6).</del>
+</blockquote>
+
+<p>
+Strike from 20.7 [function.objects] p2:
+</p>
+
+<blockquote><pre><del>// 20.7.6, identity operation:</del>
+<del>template <IdentityOf T> struct identity;</del>
+</pre></blockquote>
+
+<p>
+Remove 20.7.6 [identity.operation] (whole subclause):
+</p>
+
+<blockquote>
+<pre><del>template <IdentityOf T> struct identity {
+ typedef T type;
+
+ requires ReferentType<T>
+ const T& operator()(const T& x) const;
+};</del>
+
+<del>requires ReferentType<T>
+ const T& operator()(const T& x) const;</del>
+</pre>
+<blockquote>
+<del>-1- <i>Returns:</i> <tt>x</tt></del>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="940"></a>940. <tt>std::distance</tt></h3>
+<p><b>Section:</b> 24.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Thomas <b>Opened:</b> 2008-12-14 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 270</b></p>
+
+<p>
+Regarding the <tt>std::distance</tt> - function, 24.4 [iterator.operations]
+/ 4 says:
+</p>
+<blockquote>
+Returns the
+number of increments or decrements needed to get from first to last.
+</blockquote>
+<p>
+This sentence is completely silent about the sign of the return value.
+24.4 [iterator.operations] / 1 gives more information about the
+underlying operations, but
+again no inferences about the sign can be made.
+Strictly speaking, that is taking that sentence literally, I think this
+sentence even implies a positive return value in all cases, as the
+number of increments or decrements is clearly a ratio scale variable,
+with a natural zero bound.
+</p>
+<p>
+Practically speaking, my implementations did what common sense and
+knowledge based on pointer arithmetic forecasts, namely a positive sign
+for increments (that is, going from <tt>first</tt> to <tt>last</tt> by <tt>operator++</tt>), and a
+negative sign for decrements (going from <tt>first</tt> to <tt>last</tt> by <tt>operator--</tt>).
+</p>
+<p>
+Here are my two questions:
+</p>
+<p>
+First, is that paragraph supposed to be interpreted in the way what I
+called 'common sense', that is negative sign for decrements ? I am
+fairly sure that's the supposed behavior, but a double-check here in
+this group can't hurt.
+</p>
+<p>
+Second, is the present wording (2003 standard version - no idea about
+the draft for the upcoming standard) worth an edit to make it a bit more
+sensible, to mention the sign of the return value explicitly ?
+</p>
+
+<p><i>[
+Daniel adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+My first thought was that resolution <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#204">204</a> would already cover the
+issue report, but it seems that current normative wording is in
+contradiction to that resolution:
+</p>
+
+<p>
+Referring to
+<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>,
+24.4 [iterator.operations]/ p.4 says:
+</p>
+
+<blockquote>
+<i>Effects:</i> Returns the number of increments or decrements needed to get
+from <tt>first</tt> to <tt>last</tt>.
+</blockquote>
+
+<p>
+IMO the part " or decrements" is in contradiction to p. 5 which says
+</p>
+
+<blockquote>
+<i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>.
+</blockquote>
+
+<p>
+because "reachable" is defined in 24.2 [iterator.concepts]/7 as
+</p>
+
+<blockquote>
+An iterator <tt>j</tt> is called reachable from an iterator <tt>i</tt> if and only if
+there is a finite
+sequence of applications of the expression <tt>++i</tt> that makes <tt>i == j</tt>.[..]
+</blockquote>
+
+<p>
+Here is wording that would be consistent with this definition of "reachable":
+</p>
+
+<p>
+Change 24.4 [iterator.operations] p4 as follows:
+</p>
+
+<blockquote>
+<i>Effects:</i> Returns the number of increments <del>or decrements</del>
+needed to get from <tt>first</tt> to <tt>last</tt>.
+</blockquote>
+
+</blockquote>
+
+<p>
+Thomas adds more discussion and an alternative view point
+<a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/e8e46dcda0a5d797#">here</a>.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+The proposed wording below was verbally agreed to. Howard provided.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Pete reports that a recent similar change has been made
+for the <tt>advance()</tt> function.
+</p>
+<p>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 24.4 [iterator.operations]:
+</p>
+
+<blockquote>
+<pre>template <InputIterator Iter>
+ Iter::difference_type
+ distance(Iter first, Iter last);
+<del>template <RandomAccessIterator Iter>
+ Iter::difference_type distance(Iter first, Iter last);</del>
+</pre>
+
+<blockquote>
+<p>
+-4- <i>Effects:</i> Returns the number of increments <del>or decrements</del>
+needed to get from <tt>first</tt> to <tt>last</tt>.
+</p>
+<p>
+-5- <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>.
+</p>
+</blockquote>
+
+<pre><ins>template <RandomAccessIterator Iter>
+ Iter::difference_type distance(Iter first, Iter last);</ins>
+</pre>
+
+<blockquote>
+<p>
+<ins>-6- <i>Effects:</i> Returns the number of increments or decrements
+needed to get from <tt>first</tt> to <tt>last</tt>.</ins>
+</p>
+<p>
+<ins>-7- <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>
+or <tt>first</tt> shall be reachable from <tt>last</tt>.</ins>
+</p>
+</blockquote>
+
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="941"></a>941. Ref-qualifiers for assignment operators</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> Niels Dekker <b>Opened:</b> 2008-12-18 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The assignment and equality operators <tt>=</tt> and <tt>==</tt> are easily confused, just
+because of their visual similarity, and in this case a simple typo can cause
+a serious bug. When the left side of an <tt>operator=</tt> is an rvalue, it's
+highly unlikely that the assignment was intended by the programmer:
+</p>
+<blockquote><pre>if ( func() = value ) // Typical typo: == intended!
+</pre></blockquote>
+<p>
+Built-in types don't support assignment to an rvalue, but unfortunately,
+a lot of types provided by the Standard Library do.
+</p>
+<p>
+Fortunately the language now offers a syntax to prevent a certain member
+function from having an rvalue as <tt>*this</tt>: by adding a ref-qualifier (<tt>&</tt>)
+to the member function declaration. Assignment operators are explicitly
+mentioned as a use case of ref-qualifiers, in "Extending Move Semantics
+To <tt>*this</tt> (Revision 1)",
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1821.htm">N1821</a> by Daveed
+Vandevoorde and Bronek Kozicki
+</p>
+<p>
+Hereby I would like to propose adding ref-qualifiers to all appropriate
+assignment operators in the library.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open.
+We recommend this be deferred until after the next Committee Draft.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+A proposed resolution is provided by the paper on this subject,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</a>,
+<i>Ref-qualifiers for assignment operators of the Standard Library</i>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="943"></a>943. <tt>ssize_t</tt> undefined</h3>
+<p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+There is a row in "Table 122 - Atomics for standard typedef types"
+in 29.5.1 [atomics.types.integral] with <tt>atomic_ssize_t</tt>
+and <tt>ssize_t</tt>. Unless, I'm missing something <tt>ssize_t</tt>
+is not defined by the standard.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Move to review. Proposed resolution: Remove the typedef. Note: ssize_t
+is a POSIX type.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Remove the row containing <tt>ssize_t</tt> from Table 119
+"Atomics for standard typedef types" in 29.5.2 [atomics.types.address].
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="944"></a>944. <tt>atomic<bool></tt> derive from <tt>atomic_bool</tt>?</h3>
+<p><b>Section:</b> 29.5.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I think it's fairly obvious that <tt>atomic<bool></tt> is supposed to be derived
+from <tt>atomic_bool</tt> (and otherwise follow the <tt>atomic<integral></tt> interface),
+though I think the current wording doesn't support this. I raised this
+point along with <tt>atomic<floating-point></tt> privately with Herb and I seem
+to recall it came up in the resulting discussion on this list. However,
+I don't see anything on the current libs issue list mentioning this
+problem.
+</p>
+
+<p>
+29.5.3 [atomics.types.generic]/3 reads
+</p>
+
+<blockquote>
+There are full specializations over the integral types on the atomic
+class template. For each integral type integral in the second column of
+table 121 or table 122, the specialization <tt>atomic<integral></tt> shall be
+publicly derived from the corresponding atomic integral type in the
+first column of the table. These specializations shall have trivial
+default constructors and trivial destructors.
+</blockquote>
+
+<p>
+Table 121 does not include (<tt>atomic_bool</tt>, <tt>bool</tt>),
+so that this should probably be mentioned explicitly in the quoted paragraph.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Move to open. Lawrence will draft a proposed resolution. Also, ask
+Howard to fix the title.
+</blockquote>
+
+<p><i>[
+Post Summit Anthony provided proposed wording.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Replace paragraph 3 in 29.5.3 [atomics.types.generic] with
+</p>
+
+<blockquote>
+-3- There are full specializations over the integral types on the <tt>atomic</tt>
+class template. For each integral type <tt>integral</tt> in the second column of
+table 121 or table 122, the specialization <tt>atomic<integral></tt> shall be
+publicly derived from the corresponding atomic integral type in the first
+column of the table.
+<ins>In addition, the specialization <tt>atomic<bool></tt>
+shall be publicly derived from <tt>atomic_bool</tt>.</ins>
+These specializations shall have trivial default
+constructors and trivial destructors.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="945"></a>945. <tt>system_clock::rep</tt> not specified</h3>
+<p><b>Section:</b> 20.9.5.1 [time.clock.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.system">active issues</a> in [time.clock.system].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.system">issues</a> in [time.clock.system].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In 20.9.5.1 [time.clock.system], the declaration of <tt>system_clock::rep</tt> says "see
+below", but there is nothing below that describes it.
+</p>
+
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+This note refers to:
+</p>
+
+<blockquote>
+-2- <tt>system_clock::duration::min() < system_clock::duration::zero()</tt> shall be <tt>true</tt>.
+</blockquote>
+
+<p>
+I.e. this is standardeze for "<tt>system_clock::rep</tt> is signed".
+Perhaps an editorial note along the lines of:
+</p>
+
+<blockquote>
+-2- <tt>system_clock::duration::min() < system_clock::duration::zero()</tt>
+shall be <tt>true</tt>. <ins>[<i>Note:</i> <tt>system_clock::rep</tt> shall be signed. <i>-- end note</i>].</ins>
+</blockquote>
+
+<p>
+?
+</p>
+
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the direction of the proposed resolution.
+Move to NAD Editorial.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a note to 20.9.5.1 [time.clock.system], p2:
+</p>
+<blockquote>
+-2- <tt>system_clock::duration::min() < system_clock::duration::zero()</tt>
+shall be <tt>true</tt>. <ins>[<i>Note:</i> <tt>system_clock::rep</tt> shall be signed. <i>-- end note</i>].</ins>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="946"></a>946. <tt>duration_cast</tt> improperly specified</h3>
+<p><b>Section:</b> 20.9.3.7 [time.duration.cast] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration.cast">active issues</a> in [time.duration.cast].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.cast">issues</a> in [time.duration.cast].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+20.9.3.7 [time.duration.cast]/3:
+
+<blockquote>
+.... All intermediate computations shall be
+carried out in the widest possible representation... .
+</blockquote>
+
+<p>
+So ignoring
+floating-point types for the moment, all this arithmetic has to be done
+using the implementation's largest integral type, even if both arguments
+use int for their representation. This seems excessive. And it's not at
+all clear what this means if we don't ignore floating-point types.
+</p>
+
+<p>
+This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>.
+</p>
+
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+The intent of this remark is that intermediate computations are carried out
+using:
+</p>
+
+<blockquote><pre>common_type<typename ToDuration::rep, Rep, intmax_t>::type
+</pre></blockquote>
+
+<p>
+The Remark was intended to be clarifying prose supporting the rather algorithmic description
+of the previous paragraph. I'm open to suggestions. Perhaps the entire paragraph
+3 (Remarks) would be better dropped?
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We view this as a specific case of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>,
+and should be resolved when that issue is resolved.
+</p>
+<p>
+Move to NAD.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="947"></a>947. duration arithmetic: contradictory requirements</h3>
+<p><b>Section:</b> 20.9.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In 20.9.3.5 [time.duration.nonmember], paragraph 8 says that calling
+<tt>dur / rep</tt>
+when <tt>rep</tt> is an instantiation of <tt>duration</tt> requires a diagnostic.
+That's followed by an <tt>operator/</tt> that takes two durations.
+So <tt>dur1 / dur2</tt> is legal under the second version,
+but requires a diagnostic under the first.
+</p>
+
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+Please see the thread starting with c++std-lib-22980 for more information.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open, pending proposed wording (and preferably an implementation).
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="948"></a>948. <tt>ratio</tt> arithmetic tweak</h3>
+<p><b>Section:</b> 20.4.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-12-26 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.arithmetic">active issues</a> in [ratio.arithmetic].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.arithmetic">issues</a> in [ratio.arithmetic].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>,
+20.4.2 [ratio.arithmetic] lacks a paragraph from the proposal
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>:
+</p>
+
+<blockquote>
+<p><b>ratio arithmetic [ratio.arithmetic]</b></p>
+
+<p>
+... If the implementation is unable to form the indicated <tt>ratio</tt> due to
+overflow, a diagnostic shall be issued.
+</p>
+</blockquote>
+
+<p>
+The lack of a diagnostic on compile-time overflow is a significant lack of
+functionality. This paragraph could be put back into the WP simply editorially.
+However in forming this issue I realized that we can do better than that. This
+paragraph should also allow alternative formulations which go to extra lengths
+to avoid overflow when possible. I.e. we should not mandate overflow when the
+implementation can avoid it.
+</p>
+
+<p>
+For example:
+</p>
+
+<blockquote>
+<pre>template <class R1, class R2> struct ratio_multiply {
+ typedef <i>see below</i>} type;
+</pre>
+
+<blockquote>
+The nested typedef type shall be a synonym for <tt>ratio<T1, T2></tt> where
+<tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> has the
+value <tt>R1::den * R2::den</tt>.
+</blockquote>
+
+</blockquote>
+
+<p>
+Consider the case where <tt>intmax_t</tt> is a 64 bit 2's complement signed integer,
+and we have:
+</p>
+
+<blockquote><pre>typedef std::ratio<0x7FFFFFFFFFFFFFFF, 0x7FFFFFFFFFFFFFF0> R1;
+typedef std::ratio<8, 7> R2;
+typedef std::ratio_multiply<R1, R2>::type RT;
+</pre></blockquote>
+
+<p>
+According to the present formulation the implementaiton will multiply
+<tt>0x7FFFFFFFFFFFFFFF * 8</tt> which will result in an overflow and subsequently
+require a diagnostic.
+</p>
+
+<p>
+However if the implementation is first allowed to divde <tt>0x7FFFFFFFFFFFFFFF</tt>
+by <tt>7</tt> obtaining <tt>0x1249249249249249 / 1</tt> and divide
+<tt>8</tt> by <tt>0x7FFFFFFFFFFFFFF0</tt> obtaining <tt>1 / 0x0FFFFFFFFFFFFFFE</tt>,
+then the exact result can then be computed without overflow:
+</p>
+
+<blockquote><pre>[0x7FFFFFFFFFFFFFFF/0x7FFFFFFFFFFFFFF0] * [8/7] = [0x1249249249249249/0x0FFFFFFFFFFFFFFE]
+</pre></blockquote>
+
+<p>
+Example implmentation which accomplishes this:
+</p>
+
+<blockquote><pre>template <class R1, class R2>
+struct ratio_multiply
+{
+private:
+ typedef ratio<R1::num, R2::den> _R3;
+ typedef ratio<R2::num, R1::den> _R4;
+public:
+ typedef ratio<__ll_mul<_R3::num, _R4::num>::value,
+ __ll_mul<_R3::den, _R4::den>::value> type;
+};
+</pre></blockquote>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+Recommend Tentatively Ready.
+</blockquote>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a paragraph prior to p1 in 20.4.2 [ratio.arithmetic]:
+</p>
+
+<blockquote>
+Implementations may use other algorithms to compute the indicated ratios to avoid overflow.
+If overflow occurs, a diagnostic shall be issued.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="949"></a>949. <tt>owner_less</tt></h3>
+<p><b>Section:</b> 20.8.13.4 [util.smartptr.ownerless] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2008-12-30 <b>Last modified:</b> 2009-03-10</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+20.8.13.4 [util.smartptr.ownerless] (class template <tt>owner_less</tt>) says that
+<tt>operator()(x,y)</tt> shall return <tt>x.before(y)</tt>.
+</p>
+<p>
+However, <tt>shared_ptr</tt> and <tt>weak_ptr</tt> have an <tt>owner_before()</tt> but not a
+<tt>before()</tt>, and there's no base class to provide a missing <tt>before()</tt>.
+</p>
+<p>
+Being that the class is named <tt>owner_less</tt> , I'm guessing that
+"<tt>before()</tt>" should be "<tt>owner_before()</tt>", right?
+</p>
+
+<p><i>[
+Herve adds:
+]</i></p>
+
+
+<blockquote>
+Agreed with the typo, it should be "shall return <tt>x.owner_before(y)</tt>".
+</blockquote>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+Recommend Tentatively Ready.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.8.13.4 [util.smartptr.ownerless] p2:
+</p>
+
+<blockquote>
+-2- <tt>operator()(x,y)</tt> shall return
+<tt>x.<ins>owner_</ins>before(y)</tt>. [<i>Note:</i> ...
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="950"></a>950. unique_ptr converting ctor shouldn't accept array form</h3>
+<p><b>Section:</b> 20.8.12.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>unique_ptr</tt>'s of array type should not convert to
+<tt>unique_ptr</tt>'s which do not have an array type.
+</p>
+
+<blockquote><pre>struct Deleter
+{
+ void operator()(void*) {}
+};
+
+int main()
+{
+ unique_ptr<int[], Deleter> s;
+ unique_ptr<int, Deleter> s2(std::move(s)); <font color="#c80000">// should not compile</font>
+}
+</pre></blockquote>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Walter: Does the "diagnostic required" apply to both arms of the "and"?
+</p>
+<p>
+Tom Plum: suggest to break into several sentences
+</p>
+<p>
+Walter: suggest "comma" before the "and" in both places
+</p>
+<p>
+Recommend Review.
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+The post-Summit comments have been applied to the proposed resolution.
+We now agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.8.12.2.1 [unique.ptr.single.ctor]:
+</p>
+
+<blockquote>
+<pre>template <class U, class E> unique_ptr(unique_ptr<U, E>&& u);
+</pre>
+<blockquote>
+<p>
+-20- <i>Requires:</i> If <tt>D</tt> is not a reference type,
+construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
+shall be well formed and shall not throw an exception. If <tt>D</tt> is
+a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
+(diagnostic required). <tt>unique_ptr<U, E>::pointer</tt> shall be
+implicitly convertible to <tt>pointer</tt> <ins>(diagnostic required). <tt>U</tt> shall not be
+an array type (diagnostic required)</ins>. [<i>Note:</i> These requirements
+imply that <tt>T</tt> and <tt>U</tt> are complete types. -- <i>end note</i>]
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 20.8.12.2.3 [unique.ptr.single.asgn]:
+</p>
+
+<blockquote>
+<pre>template <class U, class E> unique_ptr& operator=(unique_ptr<U, E>&& u);
+</pre>
+<blockquote>
+<p>
+-6- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
+<tt>D</tt> shall not throw an exception. <tt>unique_ptr<U,
+E>::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>
+<ins>(diagnostic required). <tt>U</tt> shall not be an array type (diagnostic required)</ins>.
+[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
+are complete types. -- <i>end note</i>]
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="951"></a>951. Various threading bugs #1</h3>
+<p><b>Section:</b> 20.9.2.1 [time.traits.is_fp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>.
+</p>
+
+<p>
+20.9.2.1 [time.traits.is_fp] says that the type <tt>Rep</tt> "is
+assumed to be ... a class emulating an integral type." What are the
+requirements for such a type?
+</p>
+<p><i>[
+2009-05-10 Howard adds:
+]</i></p>
+
+
+<blockquote>
+<tt>IntegralLike</tt>.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>,
+we recommend this issue be addressed in the context of providing concepts for the entire <tt>thread</tt> header.
+</p>
+<p>
+We look forward to proposed wording.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="952"></a>952. Various threading bugs #2</h3>
+<p><b>Section:</b> 20.9.3.7 [time.duration.cast] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration.cast">active issues</a> in [time.duration.cast].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.cast">issues</a> in [time.duration.cast].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+20.9.3.7 [time.duration.cast] specifies an implementation and imposes
+requirements in text (and the implementation doesn't satisfy all of the
+text requirements). Pick one.
+</p>
+
+<p>
+This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>.
+</p>
+
+<p><i>[
+2009-05-10 Howard adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+The <i>Remarks</i> paragraph is an English re-statement of the preceeding
+<i>Returns</i> clause. It was meant to be clarifying and motivating, not
+confusing. I'm not aware with how the <i>Remarks</i> contradicts the <i>Returns</i> clause
+but I'm ok with simply removing the <i>Remarks</i>.
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Pete suggests that this could be resolved
+by rephrasing the Remarks to Notes.
+</p>
+<p>
+Move to NAD Editorial.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="953"></a>953. Various threading bugs #3</h3>
+<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>.
+</p>
+
+<p>
+20.9.1 [time.clock.req] says that a clock's <tt>rep</tt> member is "an
+arithmetic type or a class emulating an arithmetic type." What are the
+requirements for such a type?
+</p>
+
+<p><i>[
+2009-05-10 Howard adds:
+]</i></p>
+
+
+<blockquote>
+This wording was aimed directly at the <tt>ArithmeticLike</tt> concept.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We recommend this issue be addressed in the context of providing concepts
+for the entire <tt>thread</tt> header.
+</p>
+<p>
+May resolve for now by specifying arithmetic types,
+and in future change to <tt>ArithmeticLike</tt>.
+However, Alisdair believes this is not feasible.
+</p>
+<p>
+Bill disagrees.
+</p>
+<p>
+We look forward to proposed wording. Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="954"></a>954. Various threading bugs #4</h3>
+<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Table 55 -- Clock Requirements (in 20.9.1 [time.clock.req])
+</p>
+
+<ol type="a">
+<li>
+the requirements for <tt>C1::time_point</tt> require <tt>C1</tt> and <tt>C2</tt>
+to "refer to the same epoch", but "epoch" is not defined.
+</li>
+<li>
+"Different clocks may share a <tt>time_point</tt> definition if it is
+valid to compare their <tt>time_point</tt>s by comparing their
+respective <tt>duration</tt>s." What does "valid" mean here? And, since
+<tt>C1::rep</tt> is "**THE** representation type of the native
+<tt>duration</tt> and <tt>time_point</tt>" (emphasis added), there
+doesn't seem to be much room for some other representation.
+</li>
+<li>
+<tt>C1::is_monotonic</tt> has type "<tt>const bool</tt>". The
+"<tt>const</tt>" should be removed.
+</li>
+<li>
+<tt>C1::period</tt> has type <tt>ratio</tt>. <tt>ratio</tt> isn't a type,
+it's a template. What is the required type?
+</li>
+</ol>
+
+<p><i>[
+2009-05-10 Howard adds:
+]</i></p>
+
+
+<ol type="a">
+<li>
+<p>
+"epoch" is purposefully not defined beyond the common English
+<a href="http://www.dictionary.net/epoch">definition</a>. The C standard
+also chose not to define epoch, though POSIX did. I believe it is a strength
+of the C standard that epoch is not defined. When it is known that two <tt>time_point</tt>s
+refer to the same epoch, then a definition of the epoch is not needed to compare
+the two <tt>time_point</tt>s, or subtract them.
+</p>
+<p>
+A <tt>time_point</tt> and a <tt>Clock</tt> implicitly refer to an (unspecified) epoch.
+The <tt>time_point</tt> represents an offset (<tt>duration</tt>) from an epoch.
+</p>
+</li>
+<li>
+<p>
+The sentence:
+</p>
+<blockquote>
+Different clocks
+may share a <tt>time_point</tt>
+definition if it is valid to
+compare their <tt>time_point</tt>s by
+comparing their respective
+<tt>duration</tt>s.
+</blockquote>
+
+<p>
+is redundant and could be removed. I believe the sentence which follows the above:
+</p>
+
+<blockquote>
+<tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
+</blockquote>
+
+<p>
+is sufficient. If two clocks share the same epoch, then by definition, comparing
+their <tt>time_point</tt>s is valid.
+</p>
+</li>
+<li>
+<tt>is_monotonic</tt> is meant to never change (be <tt>const</tt>). It is also
+desired that this value be usable in compile-time computation and branching.
+</li>
+<li>
+<p>
+This should probably instead be worded:
+</p>
+<blockquote>
+An instantiation of <tt>ratio</tt>.
+</blockquote>
+</li>
+</ol>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Re (a): It is not clear to us whether "epoch" is a term of art.
+</p>
+<p>
+Re (b), (c), and (d): We agree with Howard's comments,
+and would consider adding to (c) a <tt>static constexpr</tt> requirement.
+</p>
+<p>
+Move to Open pending proposed wording.
+</p>
+</blockquote>
+
+<p><i>[
+2009-05-25 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+In regards to (d) I suggest to say "a specialization of ratio" instead of
+"An instantiation of ratio". This seems to be the better matching standard
+core language term for this kind of entity.
+</blockquote>
+
+<p><i>[
+2009-05-25 Ganesh adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Regarding (a), I found this paper on the ISO website using the term "epoch" consistently with the current wording:
+</p>
+
+<p>
+<a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM">http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM</a>
+</p>
+<p>
+which is part of ISO/IEC 18026 "Information technology -- Spatial Reference Model (SRM)".
+</p>
+</blockquote>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol type="a">
+<li>
+<p>
+Change 20.9.1 [time.clock.req] p1:
+</p>
+<blockquote>
+-1- A clock is a bundle consisting of a native <tt>duration</tt>, a native <tt>time_point</tt>, and a function <tt>now()</tt> to get the
+current <tt>time_point</tt>. <ins>The origin of the clock's <tt>time_point</tt> is referred to as the clock's <i>epoch</i> as defined in
+section 6.3 of ISO/IEC 18026.</ins>
+A clock shall meet the requirements in Table 45.
+</blockquote>
+</li>
+<li>
+<p>
+Remove the sentence from the <tt>time_point</tt> row of the table "Clock Requirements":
+</p>
+<table border="1">
+<caption>Clock requirements</caption>
+<tbody><tr>
+<td>
+<tt>C1::time_point</tt>
+</td>
+<td>
+<tt>chrono::time_point<C1></tt> or <tt>chrono::time_point<C2, C1::duration></tt>
+</td>
+<td>
+The native <tt>time_point</tt> type of the clock.
+<del>Different clocks may share a <tt>time_point</tt> definition if it is valid to compare their <tt>time_point</tt>s by comparing their respective <tt>duration</tt>s.</del>
+<tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
+</td>
+</tr>
+</tbody></table>
+</li>
+</ol>
+<ol start="4" type="a">
+<li>
+<p>
+Change the row starting with <tt>C1::period</tt> of the table "Clock Requirements":
+</p>
+<table border="1">
+<caption>Clock requirements</caption>
+<tbody><tr>
+<td>
+<tt>C1::period</tt>
+</td>
+<td>
+<ins>a specialization of</ins> <tt>ratio</tt>
+</td>
+<td>
+The tick period of the clock in seconds.
+</td>
+</tr>
+</tbody></table>
+
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="955"></a>955. Various threading bugs #5</h3>
+<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-06-07</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+20.9.1 [time.clock.req] requires that a clock type have a member
+typedef named <tt>time_point</tt> that names an instantiation of the
+template <tt>time_point</tt>, and a member named <tt>duration</tt> that
+names an instantiation of the template <tt>duration</tt>. This mixing of
+levels is confusing. The typedef names should be different from the
+template names.
+</p>
+
+<p><i>[
+Post Summit, Anthony provided proposed wording.
+]</i></p>
+
+
+<p><i>[
+2009-05-04 Howard adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+The reason that the typedef names were given the same name as the class templates
+was so that clients would not have to stop and think about whether they were
+using the clock's native <tt>time_point</tt> / <tt>duration</tt> or the class
+template directly. In this case, one person's confusion is another person's
+encapsulation. The detail that sometimes one is referring to the clock's
+native types, and sometimes one is referring to an independent type is
+<em>purposefully</em> "hidden" because it is supposed to be an unimportant
+detail. It can be confusing to have to remember when to type <tt>duration</tt>
+and when to type <tt>duration_type</tt>, and there is no need to require the
+client to remember something like that.
+</p>
+
+<p>
+For example, here is code that I once wrote in testing out the usability of
+this facility:
+</p>
+
+<blockquote><pre>template <class Clock, class Duration>
+void do_until(const std::chrono::<b>time_point</b><Clock, Duration>& t)
+{
+ typename Clock::<b>time_point now</b> = Clock::now();
+ if (t > now)
+ {
+ typedef typename std::common_type
+ <
+ Duration,
+ typename std::chrono::system_clock::<b>duration</b>
+ >::type CD;
+ typedef std::chrono::<b>duration</b><double, std::nano> ID;
+
+ CD d = t - now;
+ ID us = duration_cast<ID>(d);
+ if (us < d)
+ ++us;
+ ...
+ }
+}
+</pre></blockquote>
+
+<p>
+I see no rationale to require the client to append <tt>_type</tt> to <em>some</em>
+of those declarations. It seems overly burdensome on the author of <tt>do_until</tt>:
+</p>
+
+<blockquote><pre>template <class Clock, class Duration>
+void do_until(const std::chrono::<b>time_point</b><Clock, Duration>& t)
+{
+ typename Clock::<b>time_point<font color="#c80000">_type</font></b> now = Clock::now();
+ if (t > now)
+ {
+ typedef typename std::common_type
+ <
+ Duration,
+ typename std::chrono::system_clock::<b>duration<font color="#c80000">_type</font></b>
+ >::type CD;
+ typedef std::chrono::<b>duration</b><double, std::nano> ID;
+
+ CD d = t - now;
+ ID us = duration_cast<ID>(d);
+ if (us < d)
+ ++us;
+ ...
+ }
+}
+</pre></blockquote>
+
+<p>
+Additionally I'm fairly certain that this suggestion hasn't been implemented.
+If it had, it would have been discovered that it is incomplete. <tt>time_point</tt>
+also has a nested type (purposefully) named <tt>duration</tt>.
+</p>
+<blockquote>
+That is, the current proposed wording would put the WP into an inconsistent state.
+</blockquote>
+<p>
+In contrast,
+the current WP has been implemented and I've received very favorable feedback
+from people using this interface in real-world code.
+</p>
+
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Bill agrees that distinct names should be used for distinct kinds of entities.
+</p>
+<p>
+Walter would prefer not to suffix type names,
+especially for such well-understood terms as "duration".
+</p>
+<p>
+Howard reminds us that the proposed resolution is incomplete, per his comment
+in the issue.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+<p><i>[
+2009-06-07 Howard adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Not meaning to be argumentative, but we have a decade of positive experience
+with the precedent of using the same name for the nested type as an external
+class representing an identical concept.
+</p>
+
+<blockquote><pre>template<class Category, class T, class Distance = ptrdiff_t,
+ class Pointer = T*, class Reference = T&>
+struct <b>iterator</b>
+{
+ ...
+};
+
+template <BidirectionalIterator Iter>
+class <b>reverse_iterator</b>
+{
+ ...
+};
+
+template <ValueType T, Allocator Alloc = allocator<T> >
+ requires NothrowDestructible<T>
+class list
+{
+public:
+ typedef <i>implementation-defined</i> <b>iterator</b>;
+ ...
+ typedef reverse_iterator<iterator> <b>reverse_iterator</b>;
+ ...
+};
+</pre></blockquote>
+
+<p>
+I am aware of <em>zero</em> complaints regarding the use of <tt>iterator</tt>
+and <tt>reverse_iterator</tt> as nested types of the containers despite these
+names also having related meaning at namespace std scope.
+</p>
+
+<p>
+Would we really be doing programmers a favor by renaming these nested types?
+</p>
+
+<blockquote><pre>template <ValueType T, Allocator Alloc = allocator<T> >
+ requires NothrowDestructible<T>
+class list
+{
+public:
+ typedef <i>implementation-defined</i> <b>iterator_type</b>;
+ ...
+ typedef reverse_iterator<iterator> <b>reverse_iterator_type</b>;
+ ...
+};
+</pre></blockquote>
+
+<p>
+I submit that such design contributes to needless verbosity which ends up
+reducing readability.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.9 [time]:
+</p>
+
+<blockquote><pre>...
+template <class Clock, class Duration = typename Clock::duration<ins>_type</ins>> class time_point;
+...
+</pre></blockquote>
+
+<p>
+Change 20.9.1 [time.clock.req]:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 45 -- Clock requirements</caption>
+<tbody><tr>
+<th>Expression</th>
+<th>Return type</th>
+<th>Operational semantics</th>
+</tr>
+<tr>
+<td>...</td>
+<td>...</td>
+<td>...</td>
+</tr>
+<tr>
+<td><tt>C1::duration<ins>_type</ins></tt></td>
+<td><tt>chrono::duration<C1::rep, C1::period></tt></td>
+<td>The native <tt>duration</tt> type of the clock.</td>
+</tr>
+<tr>
+<td><tt>C1::time_point<ins>_type</ins></tt></td>
+<td><tt>chrono::time_point<C1></tt> or <tt>chrono::time_point<C2, C1::duration<ins>_type</ins><</tt></td>
+<td>The native <tt>time_point</tt> type of the clock. Different clocks may share a <tt>time_point<ins>_type</ins></tt>
+definition if it is valid to
+compare their <tt>time_point<ins>_type</ins></tt>s by
+comparing their respective
+<tt>duration<ins>_type</ins></tt>s. <tt>C1</tt> and <tt>C2</tt> shall
+refer to the same epoch.</td>
+</tr>
+<tr>
+<td>...</td>
+<td>...</td>
+<td>...</td>
+</tr>
+<tr>
+<td><tt>C1::now()</tt></td>
+<td><tt>C1::time_point<ins>_type</ins></tt></td>
+<td>Returns a <tt>time_point<ins>_type</ins></tt> object
+representing the current point
+in time.
+</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+<p>
+Change 20.9.5.1 [time.clock.system]:
+</p>
+
+<blockquote>
+<p>
+-1- Objects of class <tt>system_clock</tt> represent wall clock time from the system-wide realtime clock.
+</p>
+
+<blockquote><pre>class system_clock {
+public:
+ typedef <i>see below</i> rep;
+ typedef ratio<<i>unspecified</i>, <i>unspecified</i>> period;
+ typedef chrono::duration<rep, period> duration<ins>_type</ins>;
+ typedef chrono::time_point<system_clock> time_point<ins>_type</ins>;
+ static const bool is_monotonic = <i>unspecified</i> ;
+
+ static time_point<ins>_type</ins> now();
+
+ // Map to C API
+ static time_t to_time_t (const time_point<ins>_type</ins>& t);
+ static time_point<ins>_type</ins> from_time_t(time_t t);
+};
+</pre></blockquote>
+
+<p>
+-2- <tt>system_clock::duration<ins>_type</ins>::min() < system_clock::duration<ins>_type</ins>::zero()</tt> shall be <tt>true</tt>.
+</p>
+
+<pre>time_t to_time_t(const time_point<ins>_type</ins>& t);
+</pre>
+
+<blockquote>
+-3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
+point in time as <tt>t</tt> when both values are truncated to the
+coarser of the precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>.
+</blockquote>
+
+<pre><tt>time_point<ins>_type</ins></tt> from_time_t(time_t t);
+</pre>
+
+<blockquote>
+-4- <i>Returns:</i> A <tt>time_point<ins>_type</ins></tt> object that represents the same point
+in time as <tt>t</tt> when both values are truncated to the coarser of the
+precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>.
+</blockquote>
+</blockquote>
+
+<p>
+Change 20.9.5.2 [time.clock.monotonic]:
+</p>
+
+<blockquote><pre>class monotonic_clock {
+public:
+ typedef <i>unspecified</i> rep;
+ typedef ratio<<i>unspecified</i> , <i>unspecified</i>> period;
+ typedef chrono::duration<rep, period> duration<ins>_type</ins>;
+ typedef chrono::time_point<<i>unspecified</i> , duration<ins>_type</ins>> time_point<ins>_type</ins>;
+ static const bool is_monotonic = true;
+
+ static time_point<ins>_type</ins> now();
+};
+</pre></blockquote>
+
+<p>
+Change 20.9.5.3 [time.clock.hires]:
+</p>
+
+<blockquote><pre>class high_resolution_clock {
+public:
+ typedef <i>unspecified</i> rep;
+ typedef ratio<<i>unspecified</i> , <i>unspecified</i>> period;
+ typedef chrono::duration<rep, period> duration<ins>_type</ins>;
+ typedef chrono::time_point<<i>unspecified</i> , duration<ins>_type</ins>> time_point<ins>_type</ins>;
+ static const bool is_monotonic = true;
+
+ static time_point<ins>_type</ins> now();
+};
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="956"></a>956. Various threading bugs #6</h3>
+<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
+<p><b>View all 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>
+20.9.1 [time.clock.req] uses the word "native" in several places,
+but doesn't define it. What is a "native <tt>duration</tt>"?
+</p>
+
+<p><i>[
+2009-05-10 Howard adds:
+]</i></p>
+
+
+<blockquote>
+The standard uses "native" in several places without defining it (e.g.
+2.14.3 [lex.ccon]). It is meant to mean "that which is defined
+by the facility", or something along those lines. In this case it refers
+to the nested <tt>time_point</tt> and <tt>duration</tt> types of the clock.
+Better wording is welcome.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open pending proposed wording from Pete.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="957"></a>957. Various threading bugs #7</h3>
+<p><b>Section:</b> 20.9.5.1 [time.clock.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.system">active issues</a> in [time.clock.system].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.system">issues</a> in [time.clock.system].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+20.9.5.1 [time.clock.system]: <tt>to_time_t</tt> is overspecified. It
+requires truncation, but should allow rounding. For example, suppose a
+system has a clock that gives times in milliseconds, but <tt>time()</tt> rounds
+those times to the nearest second. Then <tt>system_clock</tt> can't use any
+resolution finer than one second, because if it did, truncating times
+between half a second and a full second would produce the wrong <tt>time_t</tt>
+value.
+</p>
+
+<p><i>[
+Post Summit Anthony Williams provided proposed wording.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Review pending input from Howard. and other stakeholders.
+</blockquote>
+
+<p><i>[
+2009-05-23 Howard adds:
+]</i></p>
+
+
+<blockquote>
+I am in favor of the wording provided by Anthony.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.9.5.1 [time.clock.system] replace paragraphs 3 and 4 with:
+</p>
+
+<blockquote>
+<pre>time_t to_time_t(const time_point& t);
+</pre>
+<blockquote>
+-3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
+point in time as <tt>t</tt> when both values are <del>truncated</del>
+<ins>restricted</ins> to the coarser of the precisions of
+<tt>time_t</tt> and <tt>time_point</tt>. <ins> It is implementation
+defined whether values are rounded or truncated to the required
+precision.</ins>
+</blockquote>
+
+<pre>time_point from_time_t(time_t t);
+</pre>
+<blockquote>
+-4- <i>Returns:</i> A <tt>time_point</tt> object that represents the
+same point in time as <tt>t</tt> when both values are <del>truncated</del>
+<ins>restricted</ins> to the
+coarser of the precisions of <tt>time_t</tt> and <tt>time_point</tt>.
+<ins>It is implementation defined whether values are
+rounded or truncated to the required precision.</ins>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="958"></a>958. Various threading bugs #8</h3>
+<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+30.5.1 [thread.condition.condvar]: the specification for <tt>wait_for</tt>
+with no predicate has an effects clause that says it calls <tt>wait_until</tt>,
+and a returns clause that sets out in words how to determine the return
+value. Is this description of the return value subtly different from the
+description of the value returned by <tt>wait_until</tt>? Or should the effects
+clause and the returns clause be merged?
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> and any other monotonic-clock
+related issues.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="959"></a>959. Various threading bugs #9</h3>
+<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+30.5.1 [thread.condition.condvar]: <tt>condition_variable::wait_for</tt>
+is required to compute the absolute time by adding the duration value to
+<tt>chrono::monotonic_clock::now()</tt>, but <tt>monotonic_clock</tt> is not required to
+exist.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> and any other monotonic-clock
+related issues.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="960"></a>960. Various threading bugs #10</h3>
+<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+30.4.1 [thread.mutex.requirements]: paragraph 4 is entitled
+"Error conditions", but according to 17.5.1.4 [structure.specifications], "Error
+conditions:" specifies "the error conditions for error codes reported by
+the function." It's not clear what this should mean when there is no
+function in sight.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Move to open.
+</blockquote>
+
+<p><i>[
+Beman provided proposed wording.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 30.4.1 [thread.mutex.requirements] Mutex requirements,
+paragraph 4 as indicated:
+</p>
+
+<blockquote>
+<p>
+-4- <del><i>Error conditions:</i></del>
+<ins>The error conditions for error codes, if any, reported by member
+functions of type Mutex shall be:</ins>
+</p>
+<ul>
+<li>
+<tt>not_enough_memory</tt> -- if there is not enough memory to construct
+the mutex object.
+</li>
+<li>
+<tt>resource_unavailable_try_again</tt> -- if any native handle type
+manipulated is not available.
+</li>
+<li>
+<tt>operation_not_permitted</tt> -- if the thread does not have the
+necessary permission to change the state of the mutex object.
+</li>
+<li>
+<tt>device_or_resource_busy</tt> -- if any native handle type
+manipulated is already locked.
+</li>
+<li>
+<tt>invalid_argument</tt> -- if any native handle type manipulated as
+part of mutex construction is incorrect.
+</li>
+</ul>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="961"></a>961. Various threading bugs #11</h3>
+<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+30.4.1 [thread.mutex.requirements] describes required member
+functions of mutex types, and requires that they throw exceptions under
+certain circumstances. This is overspecified. User-defined types can
+abort on such errors without affecting the operation of templates
+supplied by standard-library.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+Move to open. Related to conceptualization and should probably be
+tackled as part of that.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="962"></a>962. Various threading bugs #12</h3>
+<p><b>Section:</b> 30.4.3.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+30.4.3.2.2 [thread.lock.unique.locking]: <tt>unique_lock::lock</tt> is
+required to throw an object of type <tt>std::system_error</tt> "when the
+postcondition cannot be achieved." The postcondition is <tt>owns == true</tt>,
+and this is trivial to achieve. Presumably, the requirement is intended
+to mean something more than that.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+Move to open.
+</blockquote>
+
+<p><i>[
+Beman has volunteered to provide proposed wording.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="963"></a>963. Various threading bugs #13</h3>
+<p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.member">active issues</a> in [thread.thread.member].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+30.3.1.5 [thread.thread.member]: <tt>thread::detach</tt> is required to
+throw an exception if the thread is "not a detachable thread".
+"Detachable" is never defined.
+</p>
+
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+Due to a mistake on my part, 3 proposed resolutions appeared at approximately
+the same time. They are all three noted below in the discussion.
+</blockquote>
+
+<p><i>[
+Summit, proposed resolution:
+]</i></p>
+
+
+<blockquote>
+<p>
+In 30.3.1.5 [thread.thread.member] change:
+</p>
+
+<blockquote><pre>void detach();
+</pre>
+<blockquote>
+<p>...</p>
+<p>-14- <i>Error conditions:</i></p>
+<ul>
+<li><tt>no_such_process</tt> -- <ins>if the thread is</ins> not <del>a</del> valid<del> thread</del>.</li>
+<li><tt>invalid_argument</tt> -- <ins>if the thread is</ins> not <del>a detachable</del> <ins>joinable</ins><del> thread</del>.</li>
+</ul>
+</blockquote>
+
+</blockquote>
+
+</blockquote>
+
+<p><i>[
+Post Summit, Jonathan Wakely adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+A <tt>thread</tt> is detachable if it is joinable. As we've defined joinable,
+we can just use that.
+</p>
+<p>
+This corresponds to the pthreads specification, where pthread_detach
+fails if the thread is not joinable:
+</p>
+<blockquote>
+EINVAL: The implementation has detected that the value specified by
+thread does not refer to a joinable thread.
+</blockquote>
+<p>
+Jonathan recommends this proposed wording:
+</p>
+<blockquote>
+<p>
+In 30.3.1.5 [thread.thread.member] change:
+</p>
+
+<blockquote><pre>void detach();
+</pre>
+<blockquote>
+<p>...</p>
+<p>-14- <i>Error conditions:</i></p>
+<ul>
+<li>...</li>
+<li><tt>invalid_argument</tt> -- not a <del>detachable</del> <ins>joinable</ins> thread.</li>
+</ul>
+</blockquote>
+
+</blockquote>
+</blockquote>
+</blockquote>
+
+<p><i>[
+Post Summit, Anthony Williams adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+This is covered by the precondition that <tt>joinable()</tt> be <tt>true</tt>.
+</p>
+<p>
+Anthony recommends this proposed wording:
+</p>
+
+<blockquote>
+<p>
+In 30.3.1.5 [thread.thread.member] change:
+</p>
+
+<blockquote><pre>void detach();
+</pre>
+<blockquote>
+<p>...</p>
+<p>-14- <i>Error conditions:</i></p>
+<ul>
+<li>...</li>
+<li><del><tt>invalid_argument</tt> -- not a detachable thread.</del></li>
+</ul>
+</blockquote>
+
+</blockquote>
+
+</blockquote>
+
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="964"></a>964. Various threading bugs #14</h3>
+<p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The requirements for the constructor for <tt>condition_variable</tt> has several
+error conditions, but the requirements for the constructor for
+<tt>condition_variable_any</tt> has none. Is this difference intentional?
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Move to open, pass to Howard. If this is intentional, a note may be
+helpful. If the error conditions are to be copied from
+<tt>condition_variable</tt>, this depends on LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>.
+</blockquote>
+
+<p><i>[
+Post Summit Howard adds:
+]</i></p>
+
+
+<blockquote>
+The original intention
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2447.htm#ConditionVariablesWording">N2447</a>)
+was to let the OS return whatever errors it was going to return, and for
+those to be translated into exceptions, for both
+<tt>condition_variable</tt> and <tt>condition_variable_any</tt>. I have not
+received any complaints about specific error conditions from vendors on
+non-POSIX platforms, but such complaints would not surprise me if they surfaced.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="965"></a>965. Various threading bugs #15</h3>
+<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+30.5.1 [thread.condition.condvar]: the constructor for
+<tt>condition_variable</tt> throws an exception with error code
+<tt>device_or_resource_busy</tt> "if attempting to initialize a
+previously-initialized but as of yet undestroyed <tt>condition_variable</tt>."
+How can this occur?
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+<p>
+Move to review. Proposed resolution: strike the <tt>device_or_resource_busy</tt>
+error condition from the constructor of <tt>condition_variable</tt>.
+</p>
+<ul>
+<li>
+This is a POSIX error that cannot occur in this interface because the
+C++ interface does not separate declaration from initialization.
+</li>
+</ul>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 30.5.1 [thread.condition.condvar] p3:
+</p>
+
+<blockquote>
+<ul>
+<li>...</li>
+<li>
+<del><tt>device_or_resource_busy</tt> -- if attempting to initialize a
+previously-initialized but as of yet undestroyed
+<tt>condition_variable</tt>.</del>
+</li>
+</ul>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="966"></a>966. Various threading bugs #16</h3>
+<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+30.5.1 [thread.condition.condvar]: <tt>condition_variable::wait</tt> and
+<tt>condition_variable::wait_until</tt> both have a postcondition that <tt>lock</tt> is
+locked by the calling thread, and a throws clause that requires throwing
+an exception if this postcondition cannot be achieved. How can the
+implementation detect that this <tt>lock</tt> can never be obtained?
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Move to open. Requires wording. Agreed this is an issue, and the
+specification should not require detecting deadlocks.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="967"></a>967. Various threading bugs #17</h3>
+<p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+the error handling for the constructor for <tt>condition_variable</tt>
+distinguishes lack of memory from lack of other resources, but the error
+handling for the thread constructor does not. Is this difference
+intentional?
+</p>
+
+<p><i>[
+Beman has volunteered to provide proposed wording.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="968"></a>968. Various threading bugs #18</h3>
+<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+30.4.1 [thread.mutex.requirements]: several functions are
+required to throw exceptions "if the thread does not have the necessary
+permission ...". "The necessary permission" is not defined.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+Move to open.
+</blockquote>
+
+
+<p><i>[
+Beman has volunteered to provide proposed wording.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="969"></a>969. What happened to Library Issue 475?</h3>
+<p><b>Section:</b> 25.3.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2009-01-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.foreach">active issues</a> in [alg.foreach].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a> has CD1 status, but the non-normative note in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
+was removed in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>
+(25.3.4 [alg.foreach] in both drafts).
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to NAD Editorial.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Restore the non-normative note. It might need to be expressed in terms of concepts.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="970"></a>970. addressof overload unneeded</h3>
+<p><b>Section:</b> 20.8.11.1 [object.addressof] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-16 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#object.addressof">active issues</a> in [object.addressof].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#object.addressof">issues</a> in [object.addressof].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+20.8.11.1 [object.addressof] specifies:
+</p>
+
+<blockquote><pre>template <ObjectType T> T* addressof(T& r);
+template <ObjectType T> T* addressof(T&& r);
+</pre></blockquote>
+
+<p>
+The two signatures are ambiguous when the argument is an lvalue. The
+second signature seems not useful: what does it mean to take the
+address of an rvalue?
+</p>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+Recommend Review.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.8.11.1 [object.addressof]:
+</p>
+
+<blockquote><pre>template <ObjectType T> T* addressof(T& r);
+<del>template <ObjectType T> T* addressof(T&& r);</del>
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="971"></a>971. Spurious diagnostic conversion function</h3>
+<p><b>Section:</b> 19.5.2.6 [syserr.errcode.nonmembers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-01-19 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Anthony Williams raised the question in c++std-lib-22987 "why is there
+<tt>std::make_error_code(std::errc)</tt>? What purpose does this serve?"
+</p>
+<p>
+The function <tt>make_error_code(errc e)</tt> is not required, since
+<tt>make_error_condition(errc e)</tt> is the function that is needed for <tt>errc</tt>
+conversions. <tt>make_error_code(errc e)</tt> appears to be a holdover from my
+initial confusion over the distinction between POSIX and operating
+systems that conform to the POSIX spec.
+</p>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+Recommend Review.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+The designer of the facility (Christopher Kohlhoff)
+strongly disagrees that there is an issue here,
+and especially disagrees with the proposed resolution.
+Bill would prefer to be conservative and not apply this proposed resolution.
+Move to Open, and recommend strong consideration for NAD status.
+</blockquote>
+
+<p><i>[
+2009-05-21 Beman adds:
+]</i></p>
+
+
+<blockquote>
+My mistake. Christopher and Bill are correct and the issue should be
+NAD. The function is needed by users.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change System error support 19.5 [syserr], Header <tt><system_error></tt>
+synopsis, as indicated:
+</p>
+
+<blockquote><pre><del>error_code make_error_code(errc e);</del>
+error_condition make_error_condition(errc e);
+</pre></blockquote>
+
+<p>
+Delete from Class error_code non-member functions
+19.5.2.6 [syserr.errcode.nonmembers]:
+</p>
+
+<blockquote><pre><del>error_code make_error_code(errc e);</del>
+</pre>
+<blockquote>
+<del><i>Returns:</i> <tt>error_code(static_cast<int>(e),
+generic_category)</tt>.</del>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="972"></a>972. The term "Assignable" undefined but still in use</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">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Previous versions of the Draft had a table, defining the Assignable
+requirement. For example
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>
+Table 79, "Assignable requirements". But I guess the term "Assignable"
+is outdated by now, because the current Committee Draft provides
+<tt>MoveAssignable</tt>, <tt>CopyAssignable</tt>, and <tt>TriviallyCopyAssignable</tt> concepts
+instead. And as far as I can see, it no longer has a definition of
+<tt>Assignable</tt>. (Please correct me if I'm wrong.) Still the word
+"Assignable" is used in eight places in the Draft,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>.
+</p>
+
+<p>
+Are all of those instances of "<tt>Assignable</tt>" to be replaced by "<tt>CopyAssignable</tt>"?
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to NAD Editorial.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change Exception Propagation 18.8.5 [propagation]:
+</p>
+<blockquote>
+<tt>exception_ptr</tt> shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>,
+<tt><ins>Copy</ins>Assignable</tt> and <tt>EqualityComparable</tt>.
+</blockquote>
+
+<p>
+Change Class template reference_wrapper 20.7.5 [refwrap]:
+</p>
+<blockquote>
+<tt>reference_wrapper<T></tt> is a <tt>CopyConstructible</tt> and <tt><ins>Copy</ins>Assignable</tt> wrapper around a reference to an object of type <tt>T</tt>.
+</blockquote>
+<p>
+Change Placeholders 20.7.12.1.4 [func.bind.place]:
+</p>
+<blockquote>
+It is implementation defined whether placeholder types are <tt><ins>Copy</ins>Assignable</tt>. <tt><ins>Copy</ins>Assignable</tt> placeholders' copy assignment operators shall not throw exceptions.
+</blockquote>
+<p>
+Change Class template shared_ptr 20.8.13.2 [util.smartptr.shared]:
+</p>
+<blockquote>
+Specializations of <tt>shared_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt><ins>Copy</ins>Assignable</tt>, and <tt>LessThanComparable</tt>...
+</blockquote>
+<p>
+Change Class template weak_ptr 20.8.13.3 [util.smartptr.weak]:
+</p>
+<blockquote>
+Specializations of <tt>weak_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt><ins>Copy</ins>Assignable</tt>, and <tt>LessThanComparable</tt>...
+</blockquote>
+<p>
+Change traits typedefs 21.2.2 [char.traits.typedefs] (note: including deletion of reference to 23.1!):
+</p>
+<blockquote>
+<i>Requires:</i> <tt>state_type</tt> shall meet the requirements of <tt><ins>Copy</ins>Assignable</tt><del> (23.1)</del>, <tt>CopyConstructible</tt> (20.1.8), and <tt>DefaultConstructible</tt> types.
+</blockquote>
+<p>
+Change Class seed_seq 26.5.7.1 [rand.util.seedseq] (note again: including deletion of reference to 23.1!):
+</p>
+<blockquote>
+In addition to the requirements set forth below, instances of
+<tt>seed_seq</tt> shall meet the requirements of <tt>CopyConstructible</tt> (20.1.8) and of <tt><ins>Copy</ins>Assignable</tt><del> (23.1)</del>.
+</blockquote>
+
+<p>
+Note: The proposed resolution of this issue does not deal with the
+instance of the term "Assignable" in D.9.1 [auto.ptr], as this is dealt
+with more specifically by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, "<tt>auto_ptr</tt> characteristics", submitted
+by Maarten Hilferink.
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="973"></a>973. auto_ptr characteristics</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%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Maarten Hilferink <b>Opened:</b> 2009-01-21 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#auto.ptr">active issues</a> in [auto.ptr].</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#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I think that the Note of D.9.1 [auto.ptr], paragraph 3 needs a rewrite
+since "Assignable" is no longer defined as a concept.
+The relationship of <tt>auto_ptr</tt> with the new <tt>CopyAssignable</tt>, <tt>MoveAssignable</tt>,
+ and <tt>MoveConstructible</tt> concepts should be clarified.
+Furthermore, since the use of <tt>auto_ptr</tt> is depreciated anyway,
+ we can also omit a description of its intended use.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the intent of the proposed resolution.
+Move to NAD Editorial.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change D.9.1 [auto.ptr], paragraph 3:
+</p>
+
+<blockquote>
+The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
+<tt>auto_ptr</tt> owns the ob ject 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 ob ject at
+the same time the behavior of the program is undefined. [<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.
+<del><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.</del>
+
+<ins>Instances of <tt>auto_ptr</tt> shall
+meet the <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>
+requirements, but do not meet the <tt>CopyConstructible</tt> and
+<tt>CopyAssignable</tt> requirements.</ins>
+-- <i>end note</i>]
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="974"></a>974. <tt>duration<double></tt> should not implicitly convert to <tt>duration<int></tt></h3>
+<p><b>Section:</b> 20.9.3.1 [time.duration.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-21 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The following code should not compile because it involves implicit truncation
+errors (against the design philosophy of the <tt>duration</tt> library).
+</p>
+
+<blockquote><pre>duration<double> d(3.5);
+duration<int> i = d; <font color="#c80000">// implicit truncation, should not compile</font>
+</pre></blockquote>
+
+<p>
+This intent was codified in the example implementation which drove this proposal
+but I failed to accurately translate the code into the specification in this
+regard.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the proposed resolution.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.9.3.1 [time.duration.cons], p4:
+</p>
+
+<blockquote>
+<pre>template <class Rep2, class Period2>
+ duration(const duration<Rep2, Period2>& d);
+</pre>
+<blockquote>
+-4- <i>Requires:</i> <tt>treat_as_floating_point<rep>::value</tt>
+shall be <tt>true</tt> or <ins>both</ins> <tt>ratio_divide<Period2,
+period>::type::den</tt> shall be 1
+<ins>and <tt>treat_as_floating_point<Rep2>::value</tt>
+shall be <tt>false</tt></ins>.
+Diagnostic required.
+[<i>Note:</i> This requirement prevents implicit truncation error when
+converting between integral-based <tt>duration</tt> types. Such a
+construction could easily lead to confusion about the value of the
+<tt>duration</tt>. -- <i>end note</i>]
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="975"></a>975. <tt>is_convertible</tt> cannot be instantiated for non-convertible types</h3>
+<p><b>Section:</b> 20.6.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-01-25 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.rel">active issues</a> in [meta.rel].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.rel">issues</a> in [meta.rel].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<b>Addresses UK 206</b>
+
+<p>
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.
+</p>
+
+<p>
+The current specification of <tt>std::is_convertible</tt> (reference is draft
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>)
+is basically defined by 20.6.5 [meta.rel]/4:
+</p>
+
+<blockquote>
+<p>
+In order to instantiate the template <tt>is_convertible<From,
+To></tt>, the following code shall be well formed:
+</p>
+
+<blockquote><pre>template <class T>
+ typename add_rvalue_reference<T>::type create();
+
+To test() {
+ return create<From>();
+}
+</pre></blockquote>
+
+<p>
+[<i>Note:</i> This requirement gives well defined results for reference
+types, void types, array types, and function types. --<i>end note</i>]
+</p>
+</blockquote>
+
+<p>
+The first sentence can be interpreted, that e.g. the expression
+</p>
+
+<blockquote><pre>std::is_convertible<double, int*>::value
+</pre></blockquote>
+
+<p>
+is ill-formed because <tt>std::is_convertible<double, int*></tt> could not be
+instantiated, or in more general terms: The wording requires that
+<tt>std::is_convertible<X, Y></tt> cannot be instantiated for otherwise valid
+argument types <tt>X</tt> and <tt>Y</tt> if <tt>X</tt> is not convertible to <tt>Y</tt>.
+</p>
+
+<p>
+This semantic is both unpractical and in contradiction to what the last type
+traits paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2255.html">N2255</a>
+proposed:
+</p>
+
+<blockquote>
+<p>
+If the following <tt>test</tt> function is well formed code <tt>b</tt>
+is <tt>true</tt>, else it is <tt>false</tt>.
+</p>
+
+<blockquote><pre>template <class T>
+ typename add_rvalue_reference<T>::type create();
+
+To test() {
+ return create<From>();
+}
+</pre></blockquote>
+
+<p>
+[<i>Note:</i> This definition gives well defined results for <tt>reference</tt>
+types, <tt>void</tt> types, array types, and function types. --<i>end note</i>]
+</p>
+</blockquote>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Jens: Checking that code is well-formed and then returning true/false
+sounds like speculative compilation. John Spicer would really dislike
+this. Please find another wording suggesting speculative compilation.
+</p>
+<p>
+Recommend Open.
+</p>
+</blockquote>
+
+<p><i>[
+Post Summit, Howard adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+John finds the following wording clearer:
+</p>
+<blockquote>
+
+<table border="1">
+<tbody><tr>
+<th>Template</th><th>Condition</th><th>Comments</th>
+</tr>
+<tr>
+<td><tt>template <class From, class To><br>struct is_convertible;</tt></td>
+<td><i>see below</i></td>
+<td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
+or (possibly cv-qualified) <tt>void</tt> types.</td>
+</tr>
+</tbody></table>
+
+<p>
+Given the following function prototype:
+</p>
+
+<blockquote><pre>template <class T>
+ typename add_rvalue_reference<T>::type create();
+</pre></blockquote>
+
+<p>
+<tt>is_convertible<From, To>::value</tt> shall be <tt>true</tt> if the
+return expression in the following code would be well-formed, including
+any implicit conversions to the return type of the function, else
+<tt>is_convertible<From, To>::value</tt> shall be <tt>false</tt>.
+</p>
+
+<blockquote><pre>To test() {
+ return create<From>();
+}
+</pre></blockquote>
+
+</blockquote>
+
+</blockquote>
+
+<b>Original proposed wording:</b>
+
+<p>
+In 20.6.5 [meta.rel]/4 change:
+</p>
+
+<blockquote>
+<del>In order to instantiate the template <tt>is_convertible<From, To></tt>, the
+following code shall be well formed</del> <ins>If the following code
+is well formed <tt>is_convertible<From, To>::value</tt> is <tt>true</tt>, otherwise
+<tt>false</tt></ins>:[..]
+</blockquote>
+
+<p><b>Revision 2</b></p>
+
+<blockquote>
+
+<p>
+In 20.6.5 [meta.rel] change:
+</p>
+
+<blockquote>
+
+<table border="1">
+<tbody><tr>
+<th>Template</th><th>Condition</th><th>Comments</th>
+</tr>
+<tr>
+</tr><tr><td>...</td><td>...</td><td>...</td></tr>
+<tr><td><tt>template <class From, class To><br>struct is_convertible;</tt></td>
+<td>
+<del>The code set out below shall be well formed.</del>
+<ins><i>see below</i></ins></td>
+<td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
+or (possibly cv-qualified) <tt>void</tt> types.</td>
+</tr>
+</tbody></table>
+
+<p>
+-4- <del>In order to instantiate the template <tt>is_convertible<From, To></tt>, the
+following code shall be well formed:</del>
+<ins>Given the following function prototype:</ins>
+</p>
+
+<blockquote><pre>template <class T>
+ typename add_rvalue_reference<T>::type create();
+</pre></blockquote>
+
+<p>
+<ins><tt>is_convertible<From, To>::value</tt> inherits either directly or
+indirectly from <tt>true_type</tt> if the
+return expression in the following code would be well-formed, including
+any implicit conversions to the return type of the function, else
+<tt>is_convertible<From, To>::value</tt> inherits either directly or
+indirectly from <tt>false_type</tt>.</ins>
+</p>
+
+<blockquote><pre>To test() {
+ return create<From>();
+}
+</pre></blockquote>
+
+<p>
+[<i>Note:</i> This requirement gives well defined results for reference types,
+void types, array types, and function types. <i>-- end note</i>]
+</p>
+
+</blockquote>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+In 20.6.5 [meta.rel] change:
+</p>
+
+<blockquote>
+
+<table border="1">
+<tbody><tr>
+<th>Template</th><th>Condition</th><th>Comments</th>
+</tr>
+<tr>
+</tr><tr><td>...</td><td>...</td><td>...</td></tr>
+<tr><td><tt>template <class From, class To><br>struct is_convertible;</tt></td>
+<td>
+<del>The code set out below shall be well formed.</del>
+<ins><i>see below</i></ins></td>
+<td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
+or (possibly cv-qualified) <tt>void</tt> types.</td>
+</tr>
+</tbody></table>
+
+<p>
+-4- <del>In order to instantiate the template <tt>is_convertible<From, To></tt>, the
+following code shall be well formed:</del>
+<ins>Given the following function prototype:</ins>
+</p>
+
+<blockquote><pre>template <class T>
+ typename add_rvalue_reference<T>::type create();
+</pre></blockquote>
+
+<p>
+<ins>the predicate condition for a template specialization
+<tt>is_convertible<From, To></tt> shall be satisfied, if and only
+if the return expression in the following code would be well-formed,
+including any implicit conversions to the return type of the
+function.</ins>
+</p>
+
+<blockquote><pre>To test() {
+ return create<From>();
+}
+</pre></blockquote>
+
+<p>
+[<i>Note:</i> This requirement gives well defined results for reference types,
+void types, array types, and function types. <i>— end note</i>]
+</p>
+
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="976"></a>976. Class template std::stack should be movable</h3>
+<p><b>Section:</b> 23.3.5.3.1 [stack.defn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-01 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The synopsis given in 23.3.5.3.1 [stack.defn] does not show up
+</p>
+
+<blockquote><pre>requires MoveConstructible<Cont> stack(stack&&);
+requires MoveAssignable<Cont> stack& operator=(stack&&);
+</pre></blockquote>
+
+<p>
+although the other container adaptors do provide corresponding
+members.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the proposed resolution.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In the class stack synopsis of 23.3.5.3.1 [stack.defn] insert:
+</p>
+
+<blockquote><pre>template <ObjectType T, StackLikeContainer Cont = deque<T> >
+ requires SameType<Cont::value_type, T>
+ && NothrowDestructible<Cont>
+class stack {
+public:
+ ...
+ requires CopyConstructible<Cont> explicit stack(const Cont&);
+ requires MoveConstructible<Cont> explicit stack(Cont&& = Cont());
+ <ins>requires MoveConstructible<Cont> stack(stack&&);</ins>
+ <ins>requires MoveAssignable<Cont> stack& operator=(stack&&);</ins>
+ template <class Alloc>
+ requires Constructible<Cont, const Alloc&>
+ explicit stack(const Alloc&);
+ ...
+};
+</pre></blockquote>
+
+<p>
+[Remark: This change should be done in sync with the resolution of
+paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</a>]
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="977"></a>977. insert iterators inefficient for expensive to move types</h3>
+<p><b>Section:</b> 24.7 [insert.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-02 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#insert.iterators">active issues</a> in [insert.iterators].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.iterators].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The new concepts for the insert iterators mandate an extra copy when
+inserting an lvalue:
+</p>
+
+<blockquote><pre>requires CopyConstructible<Cont::value_type>
+ back_insert_iterator<Cont>&
+ operator=(const Cont::value_type& value);
+</pre>
+<blockquote>
+-1- <i>Effects:</i> <tt>push_back(*container, <b>Cont::value_type(</b>value<b>)</b>);</tt>
+</blockquote>
+</blockquote>
+
+<p>
+The reason is to convert <tt>value</tt> into an rvalue because the current
+<tt>BackInsertionContainer</tt> concept only handles <tt>push_back</tt>-ing
+rvalues:
+</p>
+
+<blockquote><pre>concept BackInsertionContainer<typename C> : Container<C> {
+ void push_back(C&, value_type&&);
+}
+</pre></blockquote>
+
+<p>
+Without the conversion of <tt>value</tt> to an rvalue, the assignment operator
+fails to concept check.
+</p>
+
+<p>
+A solution is to modify the <tt>BackInsertionContainer</tt> concept so that
+the client can pass in the parameter type for <tt>push_back</tt> similar to
+what is already done for the <tt>OutputIterator</tt> concept:
+</p>
+
+<blockquote><pre>concept BackInsertionContainer<typename C, typename Value = C::value_type&&>
+ : Container<C> {
+ void push_back(C&, Value);
+}
+</pre></blockquote>
+
+<p>
+This allows the assignment operator to be adjusted appropriately:
+</p>
+
+<blockquote><pre>requires BackInsertionContainer<Cont, Cont::value_type const&> &&
+ CopyConstructible<Cont::value_type>
+ back_insert_iterator<Cont>&
+ operator=(const Cont::value_type& value);
+</pre>
+<blockquote>
+-1- <i>Effects:</i> <tt>push_back(*container, value);</tt>
+</blockquote>
+</blockquote>
+
+<p><i>[
+We may want to propagate this fix to other concepts such as <tt>StackLikeContainer</tt>.
+]</i></p>
+
+
+<p><i>[
+Solution and wording collaborated on by Doug and Howard.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Howard notes that "these operations behaved efficiently until concepts were added."
+</p>
+<p>
+Alisdair is uncertain that the proposed resolution is syntactically correct.
+</p>
+<p>
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 23.2.6.1 [container.concepts.free]:
+</p>
+
+<blockquote>
+<pre>concept FrontInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
+ : Container<C> {
+ void push_front(C&, <del>value_type&&</del> <ins>Value</ins>);
+
+ axiom FrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) {
+ x == (push_front(c, x), front(c));
+ }
+}
+</pre>
+
+<p>...</p>
+
+<pre>concept BackInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
+ : Container<C> {
+ void push_back(C&, <del>value_type&&</del> <ins>Value</ins>);
+}
+</pre>
+
+<p>...</p>
+
+<pre>concept InsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
+ : Container<C> {
+ iterator insert(C&, const_iterator, <del>value_type&&</del> <ins>Value</ins>);
+
+ axiom Insertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) {
+ v == *insert(c, position, v);
+ }
+}
+</pre>
+
+</blockquote>
+
+<p>
+Change 23.2.6.2 [container.concepts.member]:
+</p>
+
+<blockquote>
+<pre>auto concept MemberFrontInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
+ : MemberContainer<C> {
+ void C::push_front(<del>value_type&&</del> <ins>Value</ins>);
+
+ axiom MemberFrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) {
+ x == (c.push_front(x), c.front());
+ }
+}
+</pre>
+
+<p>...</p>
+
+<pre>auto concept MemberBackInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
+ : MemberContainer<C> {
+ void C::push_back(<del>value_type&&</del> <ins>Value</ins>);
+}
+</pre>
+
+<p>...</p>
+
+<pre>auto concept MemberInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
+ : MemberContainer<C> {
+ iterator C::insert(const_iterator, <del>value_type&&</del> <ins>Value</ins>);
+
+ axiom MemberInsertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) {
+ v == *c.insert(position, v);
+ }
+}
+</pre>
+</blockquote>
+
+<p>
+Change 23.2.6.3 [container.concepts.maps]:
+</p>
+
+<blockquote>
+<pre>template <MemberFrontInsertionContainer C<ins>, typename Value = C::value_type&&</ins>>
+concept_map FrontInsertionContainer<C<ins>, Value</ins>> {
+ typedef Container<C>::value_type value_type;
+
+ void push_front(C& c, <del>value_type&&</del> <ins>Value</ins> v) { c.push_front(static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); }
+}
+</pre>
+
+<p>...</p>
+
+<pre>template <MemberBackInsertionContainer C<ins>, typename Value = C::value_type&&</ins>>
+concept_map BackInsertionContainer<C<ins>, Value</ins>> {
+ typedef Container<C>::value_type value_type;
+
+ void push_back(C& c, <del>value_type&&</del> <ins>Value</ins> v) { c.push_back(static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); }
+}
+</pre>
+
+<p>...</p>
+
+<pre>template <MemberInsertionContainer C<ins>, typename Value = C::value_type&&</ins>>
+concept_map InsertionContainer<C<ins>, Value</ins>> {
+ typedef Container<C>::value_type value_type;
+ Container<C>::iterator insert(C& c, Container<C>::const_iterator i, <del>value_type&&</del> <ins>Value</ins> v)
+ { return c.insert(i, static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); }
+}
+</pre>
+
+</blockquote>
+
+<p>
+Change 24.7.1 [back.insert.iterator]:
+</p>
+
+<blockquote><pre>template <BackInsertionContainer Cont>
+class back_insert_iterator {
+ ...
+ requires <ins>BackInsertionContainer<Cont, const Cont::value_type&></ins>
+ <del>CopyConstructible<Cont::value_type></del>
+ back_insert_iterator<Cont>&
+ operator=(const Cont::value_type& value);
+ ...
+</pre></blockquote>
+
+<p>
+Change 24.7.2.2 [back.insert.iter.op=]:
+</p>
+
+<blockquote>
+<pre>requires <ins>BackInsertionContainer<Cont, const Cont::value_type&></ins>
+ <del>CopyConstructible<Cont::value_type></del>
+ back_insert_iterator<Cont>&
+ operator=(const Cont::value_type& value);
+</pre>
+<blockquote>
+-1- <i>Effects:</i> <tt>push_back(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
+</blockquote>
+</blockquote>
+
+<p>
+Change 24.7.3 [front.insert.iterator]:
+</p>
+
+<blockquote><pre>template <FrontInsertionContainer Cont>
+class front_insert_iterator {
+ ...
+ requires <ins>FrontInsertionContainer<Cont, const Cont::value_type&></ins>
+ <del>CopyConstructible<Cont::value_type></del>
+ front_insert_iterator<Cont>&
+ operator=(const Cont::value_type& value);
+ ...
+</pre></blockquote>
+
+<p>
+Change 24.7.4.2 [front.insert.iter.op=]:
+</p>
+
+<blockquote>
+<pre>requires <ins>FrontInsertionContainer<Cont, const Cont::value_type&></ins>
+ <del>CopyConstructible<Cont::value_type></del>
+ front_insert_iterator<Cont>&
+ operator=(const Cont::value_type& value);
+</pre>
+<blockquote>
+-1- <i>Effects:</i> <tt>push_front(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
+</blockquote>
+</blockquote>
+
+<p>
+Change 24.7.5 [insert.iterator]:
+</p>
+
+<blockquote><pre>template <InsertionContainer Cont>
+class insert_iterator {
+ ...
+ requires <ins>InsertionContainer<Cont, const Cont::value_type&></ins>
+ <del>CopyConstructible<Cont::value_type></del>
+ insert_iterator<Cont>&
+ operator=(const Cont::value_type& value);
+ ...
+</pre></blockquote>
+
+<p>
+Change 24.7.6.2 [insert.iter.op=]:
+</p>
+
+<blockquote>
+<pre>requires <ins>InsertionContainer<Cont, const Cont::value_type&></ins>
+ <del>CopyConstructible<Cont::value_type></del>
+ insert_iterator<Cont>&
+ operator=(const Cont::value_type& value);
+</pre>
+<blockquote>
+<p>
+-1- <i>Effects:</i>
+</p>
+<blockquote><pre>iter = insert(*container, iter, <del>Cont::value_type(</del>value<del>)</del>);
+++iter;
+</pre></blockquote>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="978"></a>978. Hashing smart pointers</h3>
+<p><b>Section:</b> 20.7.17 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-02 <b>Last modified:</b> 2009-05-31</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I don't see an open issue on supporting <tt>std::hash</tt> for smart pointers
+(<tt>unique_ptr</tt> and <tt>shared_ptr</tt> at least).
+</p>
+<p>
+It seems reasonable to at least expect support for the smart
+pointers, especially as they support comparison for use in ordered
+associative containers.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Howard points out that the client can always supply a custom hash function.
+</p>
+<p>
+Alisdair replies that the smart pointer classes are highly likely
+to be frequently used as hash keys.
+</p>
+<p>
+Bill would prefer to be conservative.
+</p>
+<p>
+Alisdair mentions that this issue may also be viewed as a subissue or
+duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.
+</p>
+<p>
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
+</p>
+</blockquote>
+
+<p><i>[
+2009-05-31 Peter adds:
+]</i></p>
+
+
+<blockquote>
+<blockquote>
+Howard points out that the client can always supply a custom hash function.
+</blockquote>
+<p>
+Not entirely true. The client cannot supply the function that hashes the
+address of the control block (the equivalent of the old <tt>operator<</tt>, now
+proudly carrying the awkward name of '<tt>owner_before</tt>'). Only the
+implementation can do that, not necessarily via specializing <tt>hash<></tt>, of
+course.
+</p>
+<p>
+This hash function makes sense in certain situations for <tt>shared_ptr</tt>
+(when one needs to switch from <tt>set/map</tt> using ownership ordering to
+<tt>unordered_set/map</tt>) and is the only hash function that makes sense for
+<tt>weak_ptr</tt>.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="979"></a>979. Bad example</h3>
+<p><b>Section:</b> 24.5.3 [move.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-03 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+24.5.3 [move.iterators] has an incorrect example:
+</p>
+
+<blockquote>
+<p>
+-2- [<i>Example:</i>
+</p>
+
+<blockquote><pre>set<string> s;
+// populate the set s
+vector<string> v1(s.begin(), s.end()); // copies strings into v1
+vector<string> v2(make_move_iterator(s.begin()),
+ make_move_iterator(s.end())); // moves strings into v2
+</pre></blockquote>
+
+<p>
+<i>-- end example</i>]
+</p>
+</blockquote>
+
+<p>
+One can not move from a <tt>set</tt> because the iterators return <tt>const</tt>
+references.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution. Move to NAD Editorial.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 24.5.3 [move.iterators]/2:
+</p>
+
+<blockquote>
+<p>
+-2- [<i>Example:</i>
+</p>
+
+<blockquote><pre><del>set</del><ins>list</ins><string> s;
+// populate the <del>set</del><ins>list</ins> s
+vector<string> v1(s.begin(), s.end()); // copies strings into v1
+vector<string> v2(make_move_iterator(s.begin()),
+ make_move_iterator(s.end())); // moves strings into v2
+</pre></blockquote>
+
+<p>
+<i>-- end example</i>]
+</p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="981"></a>981. Unordered container requirements should add <tt>initializer_list</tt> support</h3>
+<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-08 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Refering to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>
+all container requirements tables (including those for
+associative containers) provide useful member function overloads
+accepting <tt>std::initializer_list</tt> as argument, the only exception is
+Table 87. There seems to be no reason for not providing them, because 23.5 [unord]
+is already <tt>initializer_list</tt>-aware. For the sake of
+library interface consistency and user-expectations corresponding
+overloads should be added to the table requirements of unordered
+containers as well.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the proposed resolution.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+In 23.2.5 [unord.req]/9 insert:
+</p>
+
+<blockquote>
+... <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <ins><tt>il</tt>
+designates an object of type <tt>initializer_list<value_type></tt>, </ins><tt>t</tt> is a value of type
+<tt>X::value_type</tt>, ...
+</blockquote>
+
+<p>
+In 23.2.5 [unord.req], Table 87 insert:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 87 - Unordered associative container requirements (in addition to container)</caption>
+<tbody><tr>
+<th>Expression</th> <th>Return type</th> <th>Assertion/note<br>pre-/post-condition</th> <th>Complexity</th>
+</tr>
+<tr>
+<td><tt>X(i, j)<br>X a(i, j)</tt></td> <td><tt>X</tt></td> <td>...</td> <td>...</td>
+</tr>
+<tr>
+<td><ins><tt>X(il)</tt></ins></td> <td><ins><tt>X</tt></ins></td>
+<td><ins>Same as <tt>X(il.begin(), il.end())</tt>.</ins></td>
+<td><ins>Same as <tt>X(il.begin(), il.end())</tt>.</ins></td>
+</tr>
+<tr>
+<td>...</td> <td>...</td> <td>...</td> <td>...</td>
+</tr>
+<tr>
+<td><tt>a = b</tt></td> <td><tt>X</tt></td> <td>...</td> <td>...</td>
+</tr>
+<tr>
+<td><ins><tt>a = il</tt></ins></td> <td><ins><tt>X&</tt></ins></td>
+<td><ins><tt>a = X(il); return *this;</tt></ins></td>
+<td><ins>Same as <tt>a = X(il)</tt>.</ins></td>
+</tr>
+<tr>
+<td>...</td> <td>...</td> <td>...</td> <td>...</td>
+</tr>
+<tr>
+<td><tt>a.insert(i, j)</tt></td> <td><tt>void</tt></td> <td>...</td> <td>...</td>
+</tr>
+<tr>
+<td><ins><tt>a.insert(il)</tt></ins></td> <td><ins><tt>void</tt></ins></td>
+<td><ins>Same as <tt>a.insert(il.begin(), il.end())</tt>.</ins></td>
+<td><ins>Same as <tt>a.insert(il.begin(), il.end())</tt>.</ins></td>
+</tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="982"></a>982. Wrong complexity for initializer_list assignment in Table 85</h3>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-08 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+According to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>,
+the associative container requirements table 85 says
+ that assigning an <tt>initializer_list</tt> to such a container is of
+ constant complexity, which is obviously wrong.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the proposed resolution.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+In 23.2.4 [associative.reqmts], Table 85 change:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 85 - Associative container requirements (in addition to container)</caption>
+<tbody><tr>
+<th>Expression</th> <th>Return type</th> <th>Assertion/note<br>pre-/post-condition</th> <th>Complexity</th>
+</tr>
+<tr>
+<td><tt>a = il</tt></td> <td><tt>X&</tt></td> <td><tt>a = X(il);<br>return *this;</tt></td>
+<td><del>constant</del><ins>Same as <tt>a = X(il)</tt>.</ins></td>
+</tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="983"></a>983. <tt>unique_ptr</tt> reference deleters should not be moved from</h3>
+<p><b>Section:</b> 20.8.12.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-10 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Dave brought to my attention that when a <tt>unique_ptr</tt> has a non-const reference
+type deleter, move constructing from it, even when the <tt>unique_ptr</tt> containing
+the reference is an rvalue, could have surprising results:
+</p>
+
+<blockquote><pre>D d(some-state);
+unique_ptr<A, D&> p(new A, d);
+unique_ptr<A, D> p2 = std::move(p);
+<font color="#c80000">// has d's state changed here?</font>
+</pre></blockquote>
+
+<p>
+I agree with him. It is the <tt>unique_ptr</tt> that is the rvalue, not the
+deleter. When the deleter is a reference type, the <tt>unique_ptr</tt> should
+respect the "lvalueness" of the deleter.
+</p>
+
+<p>
+Thanks Dave.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Seems correct, but complicated enough that we recommend moving to Review.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.8.12.2.1 [unique.ptr.single.ctor], p20-21
+</p>
+
+<blockquote>
+<pre>template <class U, class E> unique_ptr(unique_ptr<U, E>&& u);
+</pre>
+
+<blockquote>
+
+<p>
+-20- <i>Requires:</i> If <tt><del>D</del> <ins>E</ins></tt> is not a reference type,
+construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
+shall be well formed and shall not throw an exception.
+<ins>
+Otherwise <tt>E</tt> is a reference type and construction of the deleter
+<tt>D</tt> from an lvalue of type <tt>E</tt> shall be well formed and
+shall not throw an exception.
+</ins>
+If <tt>D</tt> is
+a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
+(diagnostic required). <tt>unique_ptr<U, E>::pointer</tt> shall be
+implicitly convertible to <tt>pointer</tt>. [<tt>Note:</tt> These
+requirements imply that <tt>T</tt> and <tt>U</tt> are complete types.
+<i>-- end note</i>]
+</p>
+
+<p>
+-21- <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns the
+pointer which <tt>u</tt> owns (if any). If the deleter
+<ins><tt>E</tt></ins> is not a reference type, <del>it</del> <ins>this
+deleter</ins> is move constructed from <tt>u</tt>'s deleter, otherwise
+<del>the reference</del> <ins>this deleter</ins> is copy constructed
+from <tt>u</tt>.'s deleter. After the construction, <tt>u</tt> no longer
+owns a pointer. [<i>Note:</i> The deleter constructor can be implemented
+with <tt>std::forward<<del>D</del><ins>E</ins>></tt>. <i>-- end
+note</i>]
+</p>
+
+</blockquote>
+</blockquote>
+
+<p>
+Change 20.8.12.2.3 [unique.ptr.single.asgn], p1-3
+</p>
+
+<blockquote>
+<pre>unique_ptr& operator=(unique_ptr&& u);
+</pre>
+<blockquote>
+
+<p>
+-1- <i>Requires:</i> <ins>If the deleter <tt>D</tt> is not a reference type,</ins>
+<del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue <tt>D</tt> shall not throw an exception.
+<ins>
+Otherwise the deleter <tt>D</tt> is a reference type,
+and assignment of the deleter <tt>D</tt> from an lvalue <tt>D</tt> shall not throw an exception.</ins>
+</p>
+
+<p>
+-2- <i>Effects:</i> reset(u.release()) followed by
+a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
+<ins><tt>std::forward<D>(u.get_deleter())</tt></ins>.
+</p>
+
+<p>
+-3- <i>Postconditions:</i> This <tt>unique_ptr</tt> now owns the pointer
+which <tt>u</tt> owned, and <tt>u</tt> no longer owns it. <del>[<i>Note:</i> If
+<tt>D</tt> is a reference type, then the referenced lvalue deleters are
+move assigned. <i>-- end note</i>]</del>
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 20.8.12.2.3 [unique.ptr.single.asgn], p6-7
+</p>
+
+<blockquote>
+<pre>template <class U, class E> unique_ptr& operator=(unique_ptr<U, E>&& u);
+</pre>
+<blockquote>
+
+<p>
+<i>Requires:</i> <ins>If the deleter <tt>E</tt> is not a reference type,</ins>
+<del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue
+<tt><del>D</del><ins>E</ins></tt> shall not throw an exception.
+<ins>
+Otherwise the deleter <tt>E</tt> is a reference type,
+and assignment of the deleter <tt>D</tt> from an lvalue <tt>E</tt> shall not throw an exception.</ins>
+<tt>unique_ptr<U, E>::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
+[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U></tt>
+are complete types. <i>-- end note</i>]
+</p>
+
+<p>
+<i>Effects:</i> <tt>reset(u.release())</tt> followed by
+a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
+<ins><tt>std::forward<E>(u.get_deleter())</tt></ins>.
+<del>If either
+<tt>D</tt> or <tt>E</tt> is a reference type, then the referenced lvalue
+deleter participates in the move assignment.</del>
+</p>
+
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="984"></a>984. Does <tt><cinttypes></tt> have macro guards?</h3>
+<p><b>Section:</b> 27.9.2 [c.files] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The C standard says about <tt><inttypes.h></tt>:
+</p>
+
+<blockquote>
+C++ implementations should define these macros only when <tt>__STDC_FORMAT_MACROS</tt>is defined
+before <tt><inttypes.h></tt> is included.
+</blockquote>
+
+<p>
+The C standard has a similar note about <tt><stdint.h></tt>. For <tt><cstdint></tt>
+we adopted a "thanks but no thanks" policy and documented that fact in
+18.4.1 [cstdint.syn]:
+</p>
+
+<blockquote>
+... [<i>Note:</i> The macros defined by <tt><stdint></tt> are
+provided unconditionally. In particular, the symbols
+<tt>__STDC_LIMIT_MACROS</tt> and <tt>__STDC_CONSTANT_MACROS</tt>
+(mentioned in C99 footnotes 219, 220, and 222) play no role in C++.
+<i>-- end note</i>]
+</blockquote>
+
+<p>
+I recommend we put a similar note in 27.9.2 [c.files] regarding <tt><cinttypes></tt>.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to 27.9.2 [c.files]:
+</p>
+
+<blockquote>
+Table 112 describes header <tt><cinttypes></tt>.
+<ins>
+[<i>Note:</i> The macros defined by <tt><cintypes></tt> are
+provided unconditionally. In particular, the symbol
+<tt>__STDC_FORMAT_MACROS</tt>
+(mentioned in C99 footnote 182) plays no role in C++.
+<i>-- end note</i>]
+</ins>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="985"></a>985. Allowing throwing move</h3>
+<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2009-02-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<b>Introduction</b>
+</p>
+
+<p>This proposal is meant to resolve potential regression of the
+<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>
+draft, see
+next section, and to relax the requirements for containers of types with
+throwing move constructors.</p>
+
+<p>The basic problem is that some containers operations, like <tt>push_back</tt>,
+have a strong exception safety
+guarantee (i.e. no side effects upon exception) that are not achievable when
+throwing move constructors are used since there is no way to guarantee revert
+after partial move. For such operations the implementation can at most provide
+the basic guarantee (i.e. valid but unpredictable) as it does with multi
+copying operations (e.g. range insert).</p>
+
+<p>For example, <tt>vector<T>::push_back()</tt> (where <tt>T</tt> has a move
+constructor) might resize the <tt>vector</tt> and move the objects to the new underlying
+buffer. If move constructor throws it might
+not be possible to recover the throwing object or to move the old objects back to
+the original buffer.</p>
+
+<p>The current draft is explicit by disallowing throwing move
+for some operations (e.g. <tt>vector<>::reserve</tt>) and not clear about other
+operations mentioned in 23.2.1 [container.requirements.general]/10
+(e.g. single element <tt>insert</tt>): it guarantees strong exception
+safety without explicitly disallowing a throwing move constructor.
+</p>
+
+<p>
+<b>Regression</b>
+</p>
+
+<p>This section only refers to cases in which the contained object
+is by itself a standard container.</p>
+
+<p>Move constructors of standard containers are allowed to throw and therefore
+existing operations are broken, compared with C++03, due to move optimization.
+(In fact existing implementations like Dinkumware are actually throwing).</p>
+
+<p>For example, <tt>vector< list<int> >::reserve</tt> yields
+undefined behavior since <tt>list<int></tt>'s move constructor is allowed to throw.
+On the other hand, the same operation has strong exception safety guarantee in
+C++03.</p>
+
+<p>There are few options to solve this regression:</p>
+
+<ol>
+<li>
+Disallow throwing move and throwing default constructor
+</li>
+
+<li>
+Disallow throwing move but disallowing usage after move
+</li>
+
+<li>
+Special casing
+</li>
+
+<li>
+Disallow throwing move and making it optional
+</li>
+
+</ol>
+
+<p>Option 1 is suggested by proposal
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a>
+but it might not be applicable for existing implementations for which
+containers default constructors are throwing.</p>
+
+<p>Option 2 limits the usage significantly and it's error prone
+by allowing zombie objects that are nothing but destructible (e.g. no <tt>clear()</tt>
+is allowed after move). It also potentially complicates the implementation by
+introducing special state.</p>
+
+<p>Option 3 is possible, for example, using default
+construction and <tt>swap</tt> instead of move for standard containers case. The
+implementation is also free to provide special hidden operation for non
+throwing move without forcing the user the cope with the limitation of option-2
+when using the public move.</p>
+
+<p>Option 4 impact the efficiency in all use cases due to rare throwing move.</p>
+
+<p>The proposed wording will imply option 1 or 3 though option 2 is also
+achievable using more wording. I personally oppose to option 2 that has impact
+on usability.</p>
+
+<p>
+<b>Relaxation for user types</b>
+</p>
+
+<p>Disallowing throwing move constructors in general seems very restrictive
+since, for example, common implementation of move will be default construction
++ <tt>swap</tt> so move will throw if the
+default constructor will throw. This is currently the case with the Dinkumware
+implementation of node based containers (e.g. <tt>std::list</tt>)
+though this section doesn't refer to standard types.</p>
+
+<p>For throwing move constructors it seem that the implementation should have
+no problems to provide the basic guarantee instead of the strong one. It's
+better to allow throwing move constructors with basic guarantee than to
+disallow it silently (compile and run), via undefined behavior.</p>
+
+<p>There might still be cases in which the relaxation will break existing generic
+code that assumes the strong guarantee but it's broken either way given a
+throwing move constructor since this is not a preserving optimization. </p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Bjarne comments (referring to his draft paper):
+"I believe that my suggestion simply solves that.
+Thus, we don't need a throwing move."
+</p>
+<p>
+Move to Open and recommend it be deferred until after the next
+Committee Draft is issued.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+23.2.1 [container.requirements.general] paragraph 10 add footnote:
+</p>
+
+<blockquote>
+<p>
+-10- Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and
+23.2.6.4) all container types defined in this Clause meet the following
+additional requirements:
+</p>
+<ul>
+<li>...</li>
+</ul>
+
+<p>
+<ins>[<i>Note</i>: for compatibility with C++
+2003, when "no effect" is required, standard containers should not use the
+value_type's throwing move constructor when the contained object is by itself a
+standard container. -- <i>end note</i>]</ins>
+</p>
+
+</blockquote>
+
+<p>23.2.5.1 [unord.req.except] change paragraph 2 to say: </p>
+
+<blockquote>
+<p>
+-2- For unordered associative containers, if an exception is
+thrown by any operation other than the container's hash function from within an
+<tt>insert()</tt> function inserting a single element, the <tt>insert()</tt>
+function has no effect<ins> unless the exception is thrown by the contained
+object move constructor</ins>.
+</p>
+
+<p>
+-4- For unordered associative containers, if an exception is
+thrown from within a <tt>rehash()</tt> function other than by the container's hash
+function or comparison function, the <tt>rehash()</tt> function has no effect
+<ins>unless the exception is thrown by the contained
+object move constructor</ins>.</p>
+
+</blockquote>
+
+<p>
+23.3.2.3 [deque.modifiers] change paragraph 2 to say:
+</p>
+
+<blockquote>
+-2- <i>Remarks:</i> If an exception is thrown other than by
+the copy constructor<ins>, move constructor</ins>
+or assignment operator of <tt>T</tt>
+there are no effects.
+<ins>If an exception is thrown by <tt>push_back()</tt> or <tt>emplace_back()</tt>
+function, that function has no effects unless the exception is thrown by
+the move constructor of <tt>T</tt>.</ins>
+</blockquote>
+
+<p>
+23.3.2.3 [deque.modifiers] change paragraph 6 to say:
+</p>
+
+<blockquote>
+-6- <i>Throws:</i> Nothing unless an exception is thrown by the copy
+constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>.
+</blockquote>
+
+<p>
+23.3.6.2 [vector.capacity] remove paragraph 2
+</p>
+
+<blockquote>
+<del>-2- <i>Requires:</i> If <tt>value_type</tt> has a move constructor,
+that constructor shall not throw any exceptions.</del>
+</blockquote>
+
+<p>
+23.3.6.2 [vector.capacity] paragraph 3 change to say:
+</p>
+
+<blockquote>
+-3- <i>Effects:</i> A directive that informs a <tt>vector</tt>
+of a planned change in size, so
+that it can manage the storage allocation accordingly. After <tt>reserve()</tt>,
+<tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt>
+if reallocation happens; and equal
+to the previous value of <tt>capacity()</tt>
+otherwise. Reallocation happens at this point if and only if the current
+capacity is less than the argument of <tt>reserve()</tt>.
+If an exception is thrown, there are no effects<ins>
+unless the exception is thrown by the contained object move constructor</ins>.
+</blockquote>
+
+<p>
+23.3.6.2 [vector.capacity] paragraph 12 change to say:
+</p>
+
+<blockquote>
+-12- <i>Requires:</i> <del>If <tt>value_type</tt> has a move constructor,
+that constructor shall not throw any exceptions.</del>
+<ins>If an exception is thrown, there are no effects unless the exception is thrown by
+the contained object move constructor.</ins>
+</blockquote>
+
+<p>
+23.3.6.4 [vector.modifiers] change paragraph 1 to say:
+</p>
+
+<blockquote>
+-1- <del><i>Requires:</i> If <tt>value_type</tt> has a move constructor,
+that constructor shall not throw any exceptions.</del>
+<ins><i>Remarks:</i> If an exception is thrown by <tt>push_back()</tt>
+or <tt>emplace_back()</tt> function, that function has no effect unless the
+exception is thrown by the move constructor of <tt>T</tt>.</ins>
+</blockquote>
+
+<p>
+23.3.6.4 [vector.modifiers] change paragraph 2 to say:
+</p>
+
+<blockquote>
+-2- <i>Remarks:</i> Causes reallocation if the new size is greater than
+the old capacity. If no reallocation happens, all the iterators and
+references before the insertion point remain valid. If an exception is
+thrown other than by the copy constructor<ins>, move constructor</ins>
+or assignment operator of <tt>T</tt> or by any <tt>InputIterator</tt>
+operation there are no effects.
+</blockquote>
+
+<p>
+23.3.6.4 [vector.modifiers] change paragraph 6 to say:
+</p>
+
+<blockquote>
+-6- <i>Throws:</i> Nothing unless an exception is thrown by the copy
+constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="986"></a>986. Generic <tt>try_lock</tt> contradiction</h3>
+<p><b>Section:</b> 30.4.4 [thread.lock.algorithm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Chris Fairles <b>Opened:</b> 2009-02-14 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In 30.4.4 [thread.lock.algorithm], the generic <tt>try_lock</tt> effects (p2) say that a failed
+<tt>try_lock</tt> is when it either returns <tt>false</tt> or throws an exception. In
+the event a call to <tt>try_lock</tt> does fail, by either returning <tt>false</tt> or
+throwing an exception, it states that <tt>unlock</tt> shall be called for all
+prior arguments. Then the returns clause (p3) goes on to state
+in a note that after returning, either all locks are locked or none
+will be. So what happens if multiple locks fail on <tt>try_lock</tt>?
+</p>
+
+<p>
+Example:
+</p>
+
+<blockquote><pre>#include <mutex>
+
+int main() {
+ std::mutex m0, m1, m2;
+ std::unique_lock<std::mutex> l0(m0, std::defer_lock);
+ std::unique_lock<std::mutex> l1(m1); //throws on try_lock
+ std::unique_lock<std::mutex> l2(m2); //throws on try_lock
+
+ int result = std::try_lock(l0, l1, l2);
+
+ assert( !l0.owns_lock() );
+ assert( l1.owns_lock() ); //??
+ assert( l2.owns_lock() ); //??
+}
+</pre></blockquote>
+
+<p>
+The first lock's <tt>try_lock</tt> succeeded but, being a prior argument to a
+lock whose <tt>try_lock</tt> failed, it gets unlocked as per the effects clause
+of 30.4.4 [thread.lock.algorithm]. However, 2 locks remain locked in this case but the return
+clause states that either all arguments shall be locked or none will
+be. This seems to be a contradiction unless the intent is for
+implementations to make an effort to unlock not only prior arguments,
+but the one that failed and those that come after as well. Shouldn't
+the note only apply to the arguments that were successfully locked?
+</p>
+
+<p>
+Further discussion and possible resolutions in c++std-lib-23049.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+Move to review. Agree with proposed resolution.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change 30.4.4 [thread.lock.algorithm], p2:
+</p>
+
+<blockquote>
+-2- <i>Effects:</i> Calls <tt>try_lock()</tt> for each argument in order
+beginning with the first until all arguments have been processed or a
+call to <tt>try_lock()</tt> fails, either by returning <tt>false</tt> or by throwing an
+exception. If a call to <tt>try_lock()</tt> fails, <tt>unlock()</tt> shall be called for
+all prior arguments<ins> and there shall be no further calls to <tt>try_lock()</tt></ins>.
+</blockquote>
+
+<p>
+Delete the note from 30.4.4 [thread.lock.algorithm], p3
+</p>
+
+<blockquote>
+-3- <i>Returns:</i> -1 if all calls to <tt>try_lock()</tt> returned <tt>true</tt>,
+otherwise a 0-based index value that indicates
+the argument for which <tt>try_lock()</tt> returned <tt>false</tt>. <del>[<i>Note:</i>
+On return, either all arguments will be
+locked or none will be locked. -- <i>end note</i>]</del>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="987"></a>987. <tt>reference_wrapper</tt> and function types</h3>
+<p><b>Section:</b> 20.7.5 [refwrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-18 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap">issues</a> in [refwrap].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The synopsis in 20.7.5 [refwrap] says:
+</p>
+
+<blockquote><pre>template <<b>ObjectType</b> T> class reference_wrapper
+...
+</pre></blockquote>
+
+<p>
+And then paragraph 3 says:
+</p>
+
+<blockquote>
+<p>
+The template instantiation <tt>reference_wrapper<T></tt> shall be
+derived from <tt>std::unary_function<T1, R></tt> only if the type
+<tt>T</tt> is any of the following:
+</p>
+
+<ul>
+<li>
+a <b>function type</b> or a pointer to function type taking one argument of
+type <tt>T1</tt> and returning <tt>R</tt>
+</li>
+</ul>
+</blockquote>
+
+<p>
+But function types are not <tt>ObjectType</tt>s.
+</p>
+
+<p>
+Paragraph 4 contains the same contradiction.
+</p>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Jens: restricted reference to ObjectType
+</p>
+<p>
+Recommend Review.
+</p>
+</blockquote>
+
+<p><i>[
+Post Summit, Peter adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+In <a href="https://svn.boost.org/trac/boost/ticket/1846">https://svn.boost.org/trac/boost/ticket/1846</a>
+however Eric Niebler makes the very reasonable point that <tt>reference_wrapper<F></tt>,
+where <tt>F</tt> is a function type, represents a reference to a function,
+a legitimate entity. So <tt>boost::ref</tt> was changed to allow it.
+</p>
+<p>
+<a href="https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp">https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp</a>
+</p>
+<p>
+Therefore, I believe an alternative proposed resolution for issue 987 could simply
+allow <tt>reference_wrapper</tt> to be used with function types.
+</p>
+</blockquote>
+
+<p><i>[
+Post Summit, Howard adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I agree with Peter (and Eric). I got this one wrong on my first try. Here
+is code that demonstrates how easy (and useful) it is to instantiate
+<tt>reference_wrapper</tt> with a function type:
+</p>
+
+<blockquote><pre>#include <functional>
+
+template <class F>
+void test(F f);
+
+void f() {}
+
+int main()
+{
+ test(std::ref(f));
+}
+</pre></blockquote>
+
+<p>
+Output (link time error shows type of <tt>reference_wrapper</tt> instantiated
+with function type):
+</p>
+
+<blockquote><pre>Undefined symbols:
+ "void test<std::reference_wrapper<void ()()> >(std::reference_wrapper<void ()()>)",...
+</pre></blockquote>
+
+<p>
+I've taken the liberty of changing the proposed wording to allow function types
+and set to Open. I'll also freely admit that I'm not positive <tt>ReferentType</tt>
+is the correct concept.
+</p>
+
+</blockquote>
+
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Howard observed that <tt>FunctionType</tt>,
+a concept not (yet?) in the Working Paper,
+is likely the correct constraint to be applied.
+However, the proposed resolution provides an adequate approximation.
+</p>
+<p>
+Move to Review.
+</p>
+</blockquote>
+
+<p><i>[
+2009-05-23 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+By constraining to <tt>PointeeType</tt> we rule out the ability for <tt>T</tt> to be a
+reference, and call in reference-collapsing. I'm not sure if this is
+correct and intended, but would like to be sure the case was considered.
+</p>
+<p>
+Is dis-allowing reference types and the
+implied reference collapsing the intended result?
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 20.7 [function.objects]:
+</p>
+
+<blockquote><pre>// 20.6.5, reference_wrapper:
+template <<del>ObjectType</del> <ins>ReferentType</ins> T>
+ <ins>requires PointeeType<T></ins>
+ class reference_wrapper;
+
+template <<del>ObjectType</del> <ins>PointeeType</ins> T>
+ reference_wrapper<T> ref(T&);
+
+template <<del>ObjectType</del> <ins>PointeeType</ins> T>
+ reference_wrapper<const T> cref(const T&);
+
+template <<del>ObjectType</del> <ins>PointeeType</ins> T>
+ reference_wrapper<T> ref(reference_wrapper<T>);
+template <<del>ObjectType</del> <ins>PointeeType</ins> T>
+ reference_wrapper<const T> cref(reference_wrapper<T>);
+</pre></blockquote>
+
+<p>
+Change the synopsis in 20.7.5 [refwrap]:
+</p>
+
+<blockquote><pre>template <<del>ObjectType</del> <ins>ReferentType</ins> T>
+ <ins>requires PointeeType<T></ins>
+ class reference_wrapper
+ ...
+</pre></blockquote>
+
+<p>
+Change the prototypes in 20.7.5.5 [refwrap.helpers]:
+</p>
+
+<blockquote><pre>template <<del>ObjectType</del> <ins>PointeeType</ins> T>
+ reference_wrapper<T> ref(T&);
+...
+template <<del>ObjectType</del> <ins>PointeeType</ins> T>
+ reference_wrapper<const T> cref(const T&);
+...
+template <<del>ObjectType</del> <ins>PointeeType</ins> T>
+ reference_wrapper<T> ref(reference_wrapper<T>);
+...
+template <<del>ObjectType</del> <ins>PointeeType</ins> T>
+ reference_wrapper<const T> cref(reference_wrapper<T>);
+</pre></blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+a) The occurrence of <tt>T&</tt> in the function signature auto-implies
+<tt>std::ReferentType</tt>,
+this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4
+</p>
+<p>
+b) The occurrence of the constrained template <tt>reference_wrapper<T></tt> in
+the remaining
+signatures lets kick in 14.11.1.2 [temp.req.impl]/4 bullet 1 and adds *all* requirements of
+this template. But we need to add at least *one* requirement (and it
+was an arbitrary,
+but natural decision to require <tt>std::PointeeType</tt> here) to *activate*
+this. If we hadn't done
+this, we were in unconstrained mode!
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="988"></a>988. <tt>Reflexivity</tt> meaningless?</h3>
+<p><b>Section:</b> 20.2.6 [concept.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-24 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#concept.comparison">active issues</a> in [concept.comparison].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.comparison">issues</a> in [concept.comparison].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+20.2.6 [concept.comparison] p2:
+</p>
+<p>
+Due to the subtle meaning of <tt>==</tt> inside axioms, the <tt>Reflexivity</tt> axiom does
+not do anything as written. It merely states that a value is substitutable
+with itself, rather than asserting a property of the <tt>==</tt> operator.
+</p>
+
+<b>
+Original proposed resolution:
+</b>
+
+<p>
+Change the definition of <tt>Reflexivity</tt> in 20.2.6 [concept.comparison]:
+</p>
+
+<blockquote><pre>axiom Reflexivity(T a) { <ins>(</ins>a == a<ins>) == true</ins>; }
+</pre></blockquote>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Alisdair: I was wrong.
+</p>
+<p>
+Recommend NAD.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+NAD.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="989"></a>989. late_check and library</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> Alisdair Meredith <b>Opened:</b> 2009-02-24 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The example in 6.9p2 shows how late_check blocks inhibit concept_map lookup
+inside a constrained context, and so inhibit concept map adaption by users
+to meet template requirements.
+</p>
+<p>
+Do we need some text in clause 17 prohibitting use of late_check in library
+template definitions unless otherwise documented?
+</p>
+
+<p><i>[
+Doug adds:
+]</i></p>
+
+
+<blockquote>
+We need something like this, but it should be a more general statement
+about implementations respecting the concept maps provided by the
+user. Use of late_check is one way in which implementations can
+subvert the concept maps provided by the user, but there are other
+ways as well ("pattern-based" overloading, tricks with "auto" concept
+maps and defaulted associated type arguments).
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open, pending proposed wording from Alisdair and/or Doug for further review.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="990"></a>990. <tt>monotonic_clock::is_monotonic</tt> must be <tt>true</tt></h3>
+<p><b>Section:</b> 20.9.5.2 [time.clock.monotonic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+There is some confusion over what the value of <tt>monotonic_clock::is_monotonic</tt>
+when <tt>monotonic_clock</tt> is a synonym for <tt>system_clock</tt>. The
+intent is that if <tt>monotonic_clock</tt> exists, then <tt>monotonic_clock::is_monotonic</tt>
+is <tt>true</tt>.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the proposed resolution.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.9.5.2 [time.clock.monotonic], p1:
+</p>
+
+<blockquote>
+-1- Objects of class <tt>monotonic_clock</tt> represent clocks for which
+values of <tt>time_point</tt> never decrease as physical time advances.
+<tt>monotonic_clock</tt> may be a synonym for <tt>system_clock</tt>
+<ins>if and only if <tt>system_clock::is_monotonic</tt> is
+<tt>true</tt></ins>.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="991"></a>991. Response to JP 50</h3>
+<p><b>Section:</b> 22.3.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#conversions.string">active issues</a> in [conversions.string].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#conversions.string">issues</a> in [conversions.string].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Add custom allocator parameter to <tt>wstring_convert</tt>, since we cannot
+allocate memory for strings from a custom allocator.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 22.3.3.2.2 [conversions.string]:
+</p>
+
+<blockquote><pre>template<class Codecvt, class Elem = wchar_t<ins>,
+ class Wide_alloc = std::allocator<Elem>,
+ class Byte_alloc = std::allocator<char> </ins>> class wstring_convert {
+ public:
+ typedef std::basic_string<char<ins>, char_traits<char>, Byte_alloc</ins>> byte_string;
+ typedef std::basic_string<Elem<ins>, char_traits<Elem>, Wide_alloc</ins>> wide_string;
+ ...
+</pre></blockquote>
+
+<p>
+Change 22.3.3.2.2 [conversions.string], p3:
+</p>
+
+<blockquote>
+-3- The class template describes an ob ject that controls conversions
+between wide string ob jects of class
+<tt>std::basic_string<Elem<ins>, char_traits<Elem>, Wide_alloc</ins>></tt>
+and byte string objects of class
+<tt>std::basic_string<char<ins>, char_traits<char>, Byte_alloc</ins>></tt>
+<del>(also known as <tt>std::string</tt>)</del>.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="992"></a>992. Response to UK 169</h3>
+<p><b>Section:</b> 17.6.1.1 [contents] <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>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#contents">active issues</a> in [contents].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#contents">issues</a> in [contents].</p>
+<p><b>View all 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 phrasing contradicts later freedom to implement the C standard
+library portions in the global namespace as well as std. (17.6.2.3p4)
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+The proposed wording seems to go too far.
+Move back to Open.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 17.6.1.1 [contents], p2:
+</p>
+
+<blockquote>
+-2- All library entities except <ins>those from the Standard C
+library,</ins> macros, <tt>operator new</tt> and <tt>operator
+delete</tt> are defined within the namespace <tt>std</tt> or namespaces
+nested within namespace <tt>std</tt>.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="993"></a>993. Response to UK 188</h3>
+<p><b>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The function <tt>_Exit</tt> does not appear to be defined in this standard.
+Should it be added to the table of functions included-by-reference to
+the C standard?
+</p>
+
+<p><i>[
+2009-05-09 Alisdair fixed some minor issues in the wording.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to 18.5 [support.start.term] Table 20 (Header
+<tt><cstdlib></tt> synopsis) Functions:
+</p>
+
+<blockquote><pre>_Exit
+</pre></blockquote>
+
+<p>
+Add before the description of <tt>abort(void)</tt>:
+</p>
+
+<blockquote><pre>void _Exit [[noreturn]] (int status)
+</pre>
+
+<blockquote>
+<p>
+The function <tt>_Exit(int status)</tt> has additional behavior in this
+International Standard:
+</p>
+<ul>
+<li>
+The program is terminated without executing destructors for objects of
+automatic, thread, or static storage duration and without calling the
+functions passed to <tt>atexit()</tt> (3.6.3 [basic.start.term]).
+</li>
+</ul>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="994"></a>994. Response to UK 193</h3>
+<p><b>Section:</b> 18.6.2.2 [new.handler] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>quick_exit</tt> has been added as a new valid way to terminate a program in a
+well defined way
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 18.6.2.2 [new.handler], p2:
+</p>
+
+<blockquote>
+<p>
+-2- <i>Required behavior:</i> ...
+</p>
+<ul>
+<li>...</li>
+<li>
+<del>call either <tt>abort()</tt> or <tt>exit();</tt></del>
+<ins>terminate execution of the program without returning to the caller</ins>
+</li>
+</ul>
+</blockquote>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="995"></a>995. Operational Semantics Unclear</h3>
+<p><b>Section:</b> 17.5.1.3 [structure.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-06 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+As a practical matter there's disagreement on the meaning of <i>operational
+semantics</i>. If the text in 17.5.1.3 [structure.requirements]p4 isn't
+clear, it should be clarified. However, it's not clear whether the
+disagreement is merely due to people not being aware of the text.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Agree with the recommended NAD resolution.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Recommend NAD. The text in 17.5.1.3 [structure.requirements] is
+perfectly clear.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="996"></a>996. Move operation not well specified</h3>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-06 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+There are lots of places in the standard where we talk about "the move
+constructor" but where we mean "the move operation," i.e. <tt>T( move( x ) )</tt>.
+</p>
+<p>
+We also don't account for whether that operation modifies <tt>x</tt> or not, and
+we need to.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open, pending proposed wording from Dave for further
+review.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="997"></a>997. Response to UK 163</h3>
+<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Many functions are defined as "Effects: Equivalent to a...", which seems
+to also define the preconditions, effects, etc. But this is not made
+clear.
+</p>
+
+<p>
+After studying the occurrences of "Effects: Equivalent to", I agree with
+the diagnosis but disagree with the solution. In 21.4.2 [string.cons]
+we find
+</p>
+
+<blockquote>
+<p>
+14 <i>Effects:</i> If <tt>InputIterator</tt> is an integral type, equivalent to
+<tt>basic_string(static_cast<size_type>(begin), static_cast<value_type>(end), a)</tt>
+</p>
+<p>
+15 Otherwise constructs a string from the values in the range <tt>[begin,
+end)</tt>, as indicated in the Sequence Requirements table (see 23.1.3).
+</p>
+</blockquote>
+
+<p>
+This would be devishly difficult to re-write with an explicit
+"Equivalent to:" clause. Instead, I propose the following, which will
+result in much less editorial re-work.
+</p>
+
+<p><i>[
+2009-05-09 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#492">492</a>.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a new paragraph after 17.5.1.4 [structure.specifications], p3:
+</p>
+
+<blockquote>
+<p>
+-3- Descriptions of function semantics contain the following elements (as appropriate):<sup>154</sup>
+</p>
+
+<ul>
+<li>
+<i>Requires:</i> the preconditions for calling the function
+</li>
+<li>
+<i>Effects:</i> the actions performed by the function
+</li>
+<li>
+<i>Postconditions:</i> the observable results established by the function
+</li>
+<li>
+<i>Returns:</i> a description of the value(s) returned by the function
+</li>
+<li>
+<i>Throws:</i> any exceptions thrown by the function, and the conditions that would cause the exception
+</li>
+<li>
+<i>Complexity:</i> the time and/or space complexity of the function
+</li>
+<li>
+<i>Remarks:</i> additional semantic constraints on the function
+</li>
+<li>
+<i>Error conditions:</i> the error conditions for error codes reported by the function.
+</li>
+<li>
+<i>Notes:</i> non-normative comments about the function
+</li>
+</ul>
+
+<p><ins>
+Whenever the <i>Effects</i> element specifies that the semantics of some
+function <tt>F</tt> are <i>Equivalent to</i> some <i>code-sequence</i>, then
+the various elements are interpreted as follows. If <tt>F</tt>'s
+semantics specifies a <i>Requires</i> element, then that requirement is
+logically imposed prior to the <i>equivalent-to</i> semantics. Then,
+the semantics of the <i>code-sequence</i> are determined by the
+<i>Requires</i>, <i>Effects</i>, <i>Postconditions</i>, <i>Returns</i>,
+<i>Throws</i>, <i>Complexity</i>, <i>Remarks</i>, <i>Error
+Conditions</i> and <i>Notes</i> specified for the (one or more) function
+invocations contained in the <i>code-sequence</i>. The value returned from
+<tt>F</tt> is specified by <tt>F</tt>'s <i>Returns</i> element, or
+if <tt>F</tt> has no <i>Returns</i> element, a non-<tt>void</tt> return from <tt>F</tt> is specified
+by the <i>Returns</i> elements in <i>code-sequence</i>. If
+<tt>F</tt>'s semantics contains a <i>Throws</i> (or
+<i>Postconditions</i>, or <i>Complexity</i>) element, then that
+supersedes any occurrences of that element in the <i>code-sequence</i>.
+</ins></p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="998"></a>998. Smart pointer referencing its owner</h3>
+<p><b>Section:</b> 20.8.12.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Pavel Minaev <b>Opened:</b> 2009-02-26 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.modifiers">active issues</a> in [unique.ptr.single.modifiers].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Consider the following (simplified) implementation of
+<tt>std::auto_ptr<T>::reset()</tt>:
+</p>
+
+<blockquote><pre>void reset(T* newptr = 0) {
+ if (this->ptr && this->ptr != newptr) {
+ delete this->ptr;
+ }
+ this->ptr = newptr;
+}
+</pre></blockquote>
+
+<p>
+Now consider the following code which uses the above implementation:
+</p>
+
+<blockquote><pre>struct foo {
+ std::auto_ptr<foo> ap;
+ foo() : ap(this) {}
+ void reset() { ap.reset(); }
+};
+int main() {
+ (new foo)->reset();
+}
+</pre></blockquote>
+
+<p>
+With the above implementation of auto_ptr, this results in U.B. at the
+point of auto_ptr::reset(). If this isn't obvious yet, let me explain
+how this goes step by step:
+</p>
+
+<ol>
+<li>
+<tt>foo::reset()</tt> entered
+</li>
+<li>
+<tt>auto_ptr::reset()</tt> entered
+</li>
+<li>
+<tt>auto_ptr::reset()</tt> tries to delete <tt>foo</tt>
+</li>
+<li>
+<tt>foo::~foo()</tt> entered, tries to destruct its members
+</li>
+<li>
+<tt>auto_ptr::~auto_ptr()</tt> executed - <tt>auto_ptr</tt> is no longer a valid object!
+</li>
+<li>
+<tt>foo::~foo()</tt> left
+</li>
+<li>
+<tt>auto_ptr::reset()</tt> sets its "ptr" field to 0 <- U.B.! <tt>auto_ptr</tt>
+is not a valid object here already!
+</li>
+</ol>
+
+<p><i>[
+Thanks to Peter Dimov who recognized the connection to <tt>unique_ptr</tt> and
+brought this to the attention of the LWG, and helped with the solution.
+]</i></p>
+
+
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+To fix this behavior <tt>reset</tt> must be specified such that deleting the
+pointer is the last action to be taken within <tt>reset</tt>.
+</blockquote>
+
+<p><i>[
+Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+The example providing the rationale for LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a> is poor, as it relies on
+broken semantics of having two object believing they are unique owners of a
+single resource. It should not be surprising that UB results from such
+code, and I feel no need to go out of our way to support such behaviour.
+</p>
+<p>
+If an example is presented that does not imply multiple ownership of a
+unique resource, I would be much more ready to accept the proposed
+resolution.
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Howard summarizes:
+</p>
+<blockquote>
+This issue has to do with circular ownership,
+and affects <tt>auto_ptr</tt>, too (but we don't really care about that).
+It is intended to spell out the order in which operations must be performed
+so as to avoid the possibility
+of undefined behavior in the self-referential case.
+</blockquote>
+<p>
+Howard points to message c++std-lib-23175 for another example,
+requested by Alisdair.
+</p>
+<p>
+We agree with the issue and with the proposed resolution.
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.8.12.2.5 [unique.ptr.single.modifiers], p5 (<i>Effects</i> clause for <tt>reset</tt>), and p6:
+</p>
+
+<blockquote>
+<p>
+-5- <i>Effects:</i> <del>If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.</del>
+<ins>Assigns <tt>p</tt> to the stored <tt>pointer</tt>, and then if the old value of the <tt>pointer</tt> is not
+equal to <tt>nullptr</tt>, calls <tt>get_deleter()(</tt>the old value of the <tt>pointer)</tt>.
+[<i>Note:</i> The order of these operations is significant because the call to <tt>get_deleter()</tt>
+may destroy <tt>*this</tt>. <i>-- end note</i>]</ins>
+</p>
+
+<p>
+-6- Postconditions: <tt>get() == p</tt>.
+<ins>[<i>Note:</i> The postcondition does not hold if the call to
+<tt>get_deleter()</tt> destroys <tt>*this</tt> since <tt>this->get()</tt> is no longer a valid
+expression. <i>-- end note</i>]</ins>
+</p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="999"></a>999. Taking the address of a function</h3>
+<p><b>Section:</b> 20.8.11.1 [object.addressof] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#object.addressof">active issues</a> in [object.addressof].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#object.addressof">issues</a> in [object.addressof].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The same fix (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>) may be applied to <tt>addressof</tt>, which is also constrained to
+<tt>ObjectType</tt>. (That was why <tt>boost::ref</tt> didn't work with functions - it
+tried to apply <tt>boost::addressof</tt> and the <tt>reinterpret_cast<char&></tt>
+implementation of <tt>addressof</tt> failed.)
+</p>
+
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 20.8 [memory]:
+</p>
+
+<blockquote><pre>template <<del>ObjectType</del> <ins>PointeeType</ins> T>
+ T* addressof(T& r);
+</pre></blockquote>
+
+<p>
+Change 20.8.11.1 [object.addressof]:
+</p>
+
+<blockquote><pre>template <<del>ObjectType</del> <ins>PointeeType</ins> T>
+ T* addressof(T& r);
+</pre></blockquote>
+
+
+<p><b>Rationale:</b></p>
+<p>
+a) The occurrence of <tt>T&</tt> in the function signature auto-implies
+<tt>std::ReferentType</tt>,
+this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1000"></a>1000. adjacent_find is over-constrained</h3>
+<p><b>Section:</b> 25.3.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2009-03-13</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.adjacent.find">issues</a> in [alg.adjacent.find].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<b>Addresses UK 296</b>
+</p>
+
+<p>
+<tt>adjacent_find</tt> in C++03 allows an arbitrary predicate, but in C++0x
+<tt>EqualityComparable/EquivalenceRelation</tt> is required. This forbids a
+number of use cases, including:
+</p>
+<blockquote>
+<table>
+<tbody><tr>
+<td valign="top">
+<tt>adjacent_find(begin, end, less<double>)</tt>
+</td>
+<td>
+Find the first
+place where a range is not ordered in decreasing order - in use to check
+for sorted ranges.
+</td>
+</tr>
+<tr>
+<td valign="top">
+<tt>adjacent_find(begin, end, DistanceBiggerThan(6) ) )</tt>
+</td>
+<td>
+Find the first
+place in a range where values differ by more than a given value - in use
+to check an algorithm which produces points in space does not generate
+points too far apart.
+</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+<p>
+A number of books use predicate which are not equivalence relations in
+examples, including "Thinking in C++" and "C++ Primer".
+</p>
+
+<p>
+Adding the requirement that the predicate is an <tt>EquivalenceRelation</tt>
+does not appear to open up any possibility for a more optimised algorithm.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the definition of adjacent_find in the synopsis of 25 [algorithms]
+and 25.3.8 [alg.adjacent.find] to:
+</p>
+
+<blockquote><pre>template<ForwardIterator Iter>
+ requires <del>EqualityComparable</del><ins>HasEqualTo</ins><Iter::value_type<ins>, Iter::value_type</ins>>
+ Iter adjacent_find(Iter first, Iter last);
+
+template<ForwardIterator Iter, <del>EquivalenceRelation</del><ins>Predicate</ins><auto, Iter::value_type<ins>, Iter::value_type</ins>> Pred>
+ requires CopyConstructible<Pred>
+ Iter adjacent_find(Iter first, Iter last, Pred pred);
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1001"></a>1001. Pointers, concepts and headers</h3>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-10 <b>Last modified:</b> 2009-06-16</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 78</b></p>
+
+<p>
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>.
+</p>
+
+<p>
+This is effectively an extension of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#343">343</a>.
+</p>
+<p>
+We know there is an increasing trend (encouraged by conformance testers and
+some users) that each library header should supply no more than required to
+satisfy the synopsis in the standard. This is typically achieved by
+breaking larger headers into smaller subsets, and judicious use of forward
+declarations.
+</p>
+<p>
+If we apply this policy to C++0x (per
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>)
+it will be very surprising for
+people using library algorithms over ranges defined by pointers that they
+must <tt>#include <iterator_concepts></tt> for their code to compile again. That is
+because pointers do not satisfy any of the iterator concepts without the
+<tt>concept_map</tt> supplied in this header.
+</p>
+<p>
+Therefore, I suggest we should require all library headers that make use of
+iterator concepts are specifically required to <tt>#include <iterator_concepts></tt>.
+</p>
+<p>
+At a minimum, the list of headers would be: (assuming all are constrained by
+concepts)
+</p>
+<blockquote><pre>algorithm
+array
+deque
+forward_list
+initializer_list
+iterator
+locale
+list
+map
+memory // if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a> is adopted
+memory_concepts
+numeric
+random
+regex
+set
+string
+tuple
+unordered_map
+unordered_set
+utility
+vector
+</pre></blockquote>
+
+<p><i>[
+Ganesh adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+The same problems exists for <tt><memory_concepts></tt> and
+<tt><container_concepts></tt>.
+</p>
+<p>
+In order to compile <tt><vector></tt> you just need the
+definitions of the concepts in <tt><memory_concepts></tt>, the
+concept maps defined there are not necessary. Yet, from the user point
+of view, if the concept map template for <tt>AllocatableElement</tt> are
+not in scope, <tt><vector></tt> is pretty useless. Same for
+<tt><tuple></tt> and <tt>ConstructibleWithAllocator</tt>.
+</p>
+<p>
+Similarly, <tt><queue></tt> is not very useful if the concept map
+template for <tt>QueueLikeContainer</tt> is not in scope, although the
+definition of concept alone is theoretically sufficient.
+</p>
+<p>
+There's a pattern here: if a concept has concept maps "attached", they
+should never be separated.
+</p>
+</blockquote>
+
+<p><i>[
+Beman provided the proposed resolution for the May 2009 mailing. He
+comments:
+]</i></p>
+
+
+<blockquote>
+
+<p>Initially I tried to specify exactly what header should include what other
+headers. This was verbose, error prone, hard to maintain, and appeared to add
+little value compared to just stating the general rule.</p>
+
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Pete believes the proposed wording overconstrains implementers.
+Instead of specifying the mechanism,
+he prefers a solution that spells out what needs to be declared,
+rather than how those declarations are to be provided,
+e.g.,
+</p>
+<blockquote>
+A C++ header shall provide the names
+that are required to be defined in that header.
+</blockquote>
+<p>
+Bill suggests approaching the wording from a programmer's perspective.
+We may want to consider promising that certain widely-used headers
+(e.g., the concept headers) are included when needed by other headers.
+He feels, however, there is nothing broken now,
+although we may want to consider "something nicer."
+</p>
+<p>
+Move to Open status.
+</p>
+
+</blockquote>
+
+<p><i>[
+2009-06-16 Beman updated the proposed resolution:
+]</i></p>
+
+
+<blockquote>
+ <ul>
+ <li>The mechanism is no longer specified, as requested in Batavia.</li>
+ <li>The footnote has been removed since it specified mechanism and also did
+ not reflect existing practice.</li>
+ <li>A sentence was added that makes it clear that the existing practice is
+ permitted.</li>
+ </ul>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p><i>Change 17.6.4.2 [res.on.headers], Headers, paragraph 1, as indicated:</i></p>
+<blockquote>
+ <p> <ins>A C++
+ header shall provide definitions for any names that appear in its synopsis (3.2 [basic.def.odr]).</ins>
+ A C++ header may include other C++ headers.<del><sup>[footnote]</sup></del> <ins>A C++
+ header shown in its synopsis as including other C++ headers shall provide
+ definitions for the same names as if those other headers were included. A C++ header that uses a
+ concept (14.10 [concept]) shall provide the definition for that concept as if it included the C++ header
+ that defines that concept in its synopsis. The mechanism and ordering of such
+ definitions is unspecified.</ins></p>
+
+ <p><ins>[<i>Example:</i> If C++ header <code><a></code> contains a concept
+ defined in C++ header <code><b></code>, and header <code><b></code> contains a
+ concept defined in C++ header <code><c></code>, then inclusion of <code><a></code>
+ is equivalent to inclusion of <code><a></code>, <code><b></code>, and <code>
+ <c></code>. <i>— end example</i>]</ins></p>
+
+ <p><del><sup>[footnote]</sup> C++ headers must include a C++ header that contains
+ any needed definition (3.2).</del></p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1002"></a>1002. Response to UK 170</h3>
+<p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 170</b></p>
+
+<p>
+One of goals of C++0x is to make language easier to teach and for
+'incidental' programmers. The fine-grained headers of the C++ library
+are valuable in large scale systems for managing dependencies and
+optimising build times, but overcomplicated for simple development and
+tutorials. Add additional headers to support the whole library through a
+single include statement.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We do not all agree that this is an issue,
+but we agree that if it needs solving this is the right way to do it.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Insert a new paragraph in 17.6.1.2 [headers] between p4 and p5
+</p>
+<blockquote>
+An additional header <tt><std></tt> shall have the effect of
+supplying the entire standard library. [<i>Note:</i> for example, it
+might be implemented as a file with an <tt>#include</tt> statement for each of the
+headers listed in tables 13 and 14. <i>-- end note</i>]
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1003"></a>1003. Response to JP 23</h3>
+<p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#compliance">active issues</a> in [compliance].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses JP 23</b></p>
+
+<p>
+There is a freestanding implementation including
+<tt><type_traits></tt>, <tt><array></tt>,
+<tt><ratio></tt>, lately added to Table 13, C++ library headers.
+Programmers think them useful and hope that these headers are also added
+to Table 15, C++ headers for freestanding implementations, that shows
+the set of headers which a freestanding implementation shall include at
+least.
+</p>
+
+<p><b>Original proposed resolution</b></p>
+
+<p>
+Add <tt><type_traits></tt>, <tt><array></tt>,
+<tt><ratio></tt> to Table 15.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+ The <tt><array></tt> header has far too many dependencies to require for a
+free-standing implementation.
+</p>
+<p>
+The <tt><ratio></tt> header would be useful, has no dependencies, but is not
+strictly necessary.
+</p>
+<p>
+The <tt><type_traits></tt> header is fundamentally a core language facility with a
+library interface, so should be supported.
+</p>
+
+<p>
+(it is anticipated the resolution will come via an update to paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a>)
+(see also LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>)
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Leave in Review status pending a paper on freestanding implementations
+by Martin Tasker.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add <tt><type_traits></tt> to Table 15.
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="1004"></a>1004. Response to UK 179</h3>
+<p><b>Section:</b> 17.6.3.8 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.functions">issues</a> in [res.on.functions].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 179</b></p>
+
+<p>
+According to the 4th bullet there is a problem if "if any replacement
+function or handler function or destructor operation throws an
+exception". There should be no problem throwing exceptions so long as
+they are caught within the function.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+The phrasing "throws an exception" is commonly used elsewhere
+to mean "throws or propagates an exception."
+Move to Open pending a possible more general resolution.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the 4th bullet of 17.6.3.8 [res.on.functions], p2:
+</p>
+
+<blockquote>
+<ul>
+<li>
+if any replacement function or handler function or destructor operation
+<del>throws</del> <ins>propagates</ins> an exception, unless specifically
+allowed in the applicable <i>Required behavior:</i> paragraph.
+</li>
+</ul>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1005"></a>1005. Response to JP 26</h3>
+<p><b>Section:</b> 18.3.1.1 [numeric.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-25</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses JP 26</b></p>
+
+<p>
+<tt>numeric_limits</tt> [partial specializations] does not use concept.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Alisdair will provide a soltion as part of treatment of axioms and LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>.
+</blockquote>
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+Alisdair recommends NAD as the partial specializations are already
+constrained by requirements on the primary template.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+The Working Draft does not in general repeat a primary template's constraints
+in any specializations.
+Move to NAD.
+</blockquote>
+
+<p><i>[
+2009-05-25 Howard adds:
+]</i></p>
+
+
+<blockquote>
+A c++std-lib thread starting at c++std-lib-23880 has cast doubt that NAD is the
+correct resolution of this issue. Indeed the discussion also casts doubt that
+the current proposed wording is the correct resolution as well. Personally I'm
+inclined to reset the status to Open. However I'm reverting the status to
+that which it had prior to the Batavia recommendation. I'm setting back to Review.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 18.3.1.1 [numeric.limits]:
+</p>
+
+<blockquote><pre>template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<const T>;
+template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<volatile T>;
+template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<const volatile T>;
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1006"></a>1006. Response to UK 190</h3>
+<p><b>Section:</b> 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete">issues</a> in [new.delete].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 190</b></p>
+
+<p>
+It is not entirely clear how the current specification acts in the
+presence of a garbage collected implementation.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agreed.
+</blockquote>
+
+<p><i>[
+2009-05-09 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+Proposed wording is too strict for implementations that do not support
+garbage collection. Updated wording supplied.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We recommend advancing this to Tentatively Ready
+with the understanding that it will not be moved for adoption
+unless and until the proposed resolution to Core issue #853 is adopted.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+(Editorial note: This wording ties into the proposed
+resolution for Core #853)
+</p>
+
+<p>
+Add paragraphs to 18.6.1.1 [new.delete.single]:
+</p>
+
+<blockquote><pre>void operator delete(void* ptr) throw();
+<del>void operator delete(void* ptr, const std::nothrow_t&) throw();</del>
+</pre>
+
+<p><i>[
+The second signature deletion above is editorial.
+]</i></p>
+
+
+<blockquote>
+<p><ins>
+<i>Requires:</i> If an implementation has strict pointer safety
+(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
+be a safely-derived pointer.
+</ins></p>
+
+<p>-10- ...</p>
+</blockquote>
+
+<pre>void operator delete(void* ptr, const std::nothrow_t&) throw();
+</pre>
+
+<blockquote>
+<p><ins>
+<i>Requires:</i> If an implementation has strict pointer safety
+(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
+be a safely-derived pointer.
+</ins></p>
+
+<p>-15- ...</p>
+</blockquote>
+
+</blockquote>
+
+<p>
+Add paragraphs to 18.6.1.2 [new.delete.array]:
+</p>
+
+<blockquote><pre>void operator delete[](void* ptr) throw();
+<del>void operator delete[](void* ptr, const std::nothrow_t&) throw();</del>
+</pre>
+
+<p><i>[
+The second signature deletion above is editorial.
+]</i></p>
+
+
+<blockquote>
+<p><ins>
+<i>Requires:</i> If an implementation has strict pointer safety
+(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
+be a safely-derived pointer.
+</ins></p>
+
+<p>-9- ...</p>
+</blockquote>
+
+<pre>void operator delete[](void* ptr, const std::nothrow_t&) throw();
+</pre>
+
+<blockquote>
+<p><ins>
+<i>Requires:</i> If an implementation has strict pointer safety
+(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
+be a safely-derived pointer.
+</ins></p>
+
+<p>-13- ...</p>
+</blockquote>
+
+</blockquote>
+
+
+<p>
+Add paragraphs to 18.6.1.3 [new.delete.placement]:
+</p>
+
+<blockquote><pre>void operator delete(void* ptr, void*) throw();
+</pre>
+
+<blockquote>
+<p><ins>
+<i>Requires:</i> If an implementation has strict pointer safety
+(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
+be a safely-derived pointer.
+</ins></p>
+
+<p>-7- ...</p>
+</blockquote>
+
+<pre>void operator delete[](void* ptr, void*) throw();
+</pre>
+
+<blockquote>
+<p><ins>
+<i>Requires:</i> If an implementation has strict pointer safety
+(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
+be a safely-derived pointer.
+</ins></p>
+
+<p>-9- ...</p>
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1007"></a>1007. Response to JP 29</h3>
+<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-13</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses JP 29</b></p>
+
+<p>
+<tt>throw_with_nested</tt> does not use concept.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agreed.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Alisdair initially proposed wording in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2619.pdf">N2619</a>.
+</p>
+<p>
+We are awaiting an updated paper based on feedback from the San Francisco
+review.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1008"></a>1008. Response to JP 31</h3>
+<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-13</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses JP 31</b></p>
+
+<p>
+It is difficult to understand in which case <tt>nested_exception</tt> is applied.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Alisdair will add an example in an update to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2619.pdf">N2619</a>.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1009"></a>1009. Response to UK 251</h3>
+<p><b>Section:</b> 24.2.1 [iterator.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 251</b></p>
+
+<p>
+The post-increment operator is dangerous for a general InputIterator.
+The multi-pass guarantees that make it meaningful are defined as part of
+the ForwardIterator refinement. Any change will affect only constrained
+templates that have not yet been written, so should not break existing
+user iterators which remain free to add these operations. This change
+will also affect the generalised OutputIterator, although there is no
+percieved need for the post-increment operator in this case either.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 24.2.1 [iterator.iterators]:
+</p>
+
+<blockquote><pre>concept Iterator<typename X> : Semiregular<X> {
+ MoveConstructible reference = typename X::reference;
+ <del>MoveConstructible postincrement_result;</del>
+
+ <del>requires HasDereference<postincrement_result>;</del>
+
+ reference operator*(X&&);
+ X& operator++(X&);
+ <del>postincrement_result operator++(X&, int);</del>
+}
+</pre>
+
+<p>...</p>
+<pre><del>postincrement_result operator++(X& r, int);</del>
+</pre>
+
+<blockquote>
+<del>-3- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</del>
+</blockquote>
+
+</blockquote>
+
+<p>
+Change 24.2.2 [input.iterators]:
+</p>
+
+<blockquote>
+<pre>concept InputIterator<typename X> : Iterator<X>, EqualityComparable<X> {
+ ObjectType value_type = typename X::value_type;
+ MoveConstructible pointer = typename X::pointer;
+
+ SignedIntegralLike difference_type = typename X::difference_type;
+
+ requires IntegralType<difference_type>
+ && Convertible<reference, const value_type &>;
+ && Convertible<pointer, const value_type*>;
+
+ <del>requires Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;</del>
+
+ pointer operator->(const X&);
+}
+</pre>
+</blockquote>
+
+<p>
+Change 24.2.3 [output.iterators]:
+</p>
+
+<blockquote>
+<pre>auto concept OutputIterator<typename X, typename Value> {
+ requires Iterator<X>;
+
+ typename reference = Iterator<X>::reference;
+ <del>typename postincrement_result = Iterator<X>::postincrement_result;</del>
+ requires SameType<reference, Iterator<X>::reference>
+ <del>&& SameType<postincrement_result, Iterator<X>::postincrement_result></del>
+ <del>&& Convertible<postincrement_result, const X&></del>
+ && HasAssign<reference, Value>
+ <del>&& HasAssign<HasDereference<postincrement_result>::result_type, Value></del>;
+}
+</pre>
+</blockquote>
+
+<p>
+Change 24.2.4 [forward.iterators]:
+</p>
+
+<p><i>[
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a> which is attempting to change this same area in a compatible
+way.
+]</i></p>
+
+
+<blockquote>
+<pre>concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> {
+ <del>requires Convertible<postincrement_result, const X&>;</del>
+
+ <ins>MoveConstructible postincrement_result;</ins>
+ <ins>requires HasDereference<postincrement_result>
+ && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;</ins>
+
+ <ins>postincrement_result operator++(X&, int);</ins>
+
+ axiom MultiPass(X a, X b) {
+ if (a == b) *a == *b;
+ if (a == b) ++a == ++b;
+ }
+}
+</pre>
+
+<blockquote>
+<p>-4- ...</p>
+</blockquote>
+
+<pre><ins>postincrement_result operator++(X& r, int);</ins>
+</pre>
+
+<blockquote>
+<p>
+<ins>-5- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</ins>
+</p>
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1010"></a>1010. Response to UK 263</h3>
+<p><b>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 263</b></p>
+
+<p>
+This requirement on <tt>operator-=</tt> would be better expressed as a default
+implementation in the concept, with a matching axiom.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+The proposed resolution should also remove
+paragraph 5 and the declaration that precedes it.
+Further, we should provide an axiom
+that captures the desired semantics.
+This may be a broader policy to be applied.
+Move to Open.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 24.2.6 [random.access.iterators]:
+</p>
+
+<blockquote><pre>concept RandomAccessIterator<typename X> : BidirectionalIterator<X>, LessThanComparable<X> {
+ ...
+ X& operator-=(X& <ins>x</ins>, difference_type <ins>n</ins>)<ins> { return x += -n</ins>;<ins> }</ins>
+ ...
+}
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1011"></a>1011. Response to UK 271</h3>
+<p><b>Section:</b> 24.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 271</b></p>
+
+<p>
+<tt>next/prev</tt> return an incremented iterator without changing the value of
+the original iterator. However, even this may invalidate an
+<tt>InputIterator</tt>. A <tt>ForwardIterator</tt> is required to guarantee the
+'multipass' property.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change [iterator.synopsis]:
+</p>
+
+<blockquote><pre>template <<del>InputIterator</del> <ins>ForwardIterator</ins> Iter>
+ Iter next(Iter x,
+ Iter::difference_type n = 1);
+</pre></blockquote>
+
+<p>
+Change 24.4 [iterator.operations], p6:
+</p>
+
+<blockquote><pre>template <<del>InputIterator</del> <ins>ForwardIterator</ins> Iter>
+ Iter next(Iter x,
+ Iter::difference_type n = 1);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1012"></a>1012. Response to UK 277</h3>
+<p><b>Section:</b> 24.5.1.2.1 [reverse.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 277</b></p>
+
+<p>
+The default constructor default-initializes current, rather than
+value-initializes. This means that when Iterator corresponds to a
+trivial type, the current member is left un-initialized, even when the
+user explictly requests value intialization! At this point, it is not
+safe to perform any operations on the reverse_iterator other than assign
+it a new value or destroy it. Note that this does correspond to the
+basic definition of a singular iterator.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree with option i.
+</blockquote>
+
+<p>
+Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We believe this should be revisited
+in conjunction with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>,
+which nearly duplicates this issue.
+Move to Open.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change [reverse.iter.con]:
+</p>
+
+<blockquote><pre>reverse_iterator();
+</pre>
+<blockquote>
+-1- <i>Effects:</i> <del>Default</del> <ins>Value</ins> initializes <tt>current</tt>. Iterator
+operations applied to the resulting iterator have defined behavior if and
+only if the corresponding operations are defined on a default constructed
+iterator of type <tt>Iterator</tt>.
+</blockquote>
+</blockquote>
+
+<p>
+Change 24.5.3.2.1 [move.iter.op.const]:
+</p>
+
+<blockquote><pre>move_iterator();
+</pre>
+<blockquote>
+-1- <i>Effects:</i> Constructs a <tt>move_iterator</tt>, <del>default</del> <ins>value</ins>
+initializing <tt>current</tt>.
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1013"></a>1013. Response to UK 305</h3>
+<p><b>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#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#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 305</b></p>
+
+<p>
+The negative requirement on <tt>IsSameType</tt> is a hold-over from an earlier
+draught with a variadic template form of <tt>min/max</tt> algorith. It is no
+longer necessary.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 25 [algorithms]:
+</p>
+
+<blockquote><pre>template<class T, StrictWeakOrder<auto, T> Compare>
+ <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
+ const T& min(const T& a, const T& b, Compare comp);
+...
+template<class T, StrictWeakOrder<auto, T> Compare>
+ <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
+ const T& max(const T& a, const T& b, Compare comp);
+...
+template<class T, StrictWeakOrder<auto, T> Compare>
+ <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
+ pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp);
+</pre></blockquote>
+
+<p>
+Change 25.5.7 [alg.min.max], p1, p9 and p17:
+</p>
+
+<blockquote><pre>template<class T, StrictWeakOrder<auto, T> Compare>
+ <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
+ const T& min(const T& a, const T& b, Compare comp);
+...
+template<class T, StrictWeakOrder<auto, T> Compare>
+ <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
+ const T& max(const T& a, const T& b, Compare comp);
+...
+template<class T, StrictWeakOrder<auto, T> Compare>
+ <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
+ pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1014"></a>1014. Response to UK 317 and JP 74</h3>
+<p><b>Section:</b> 28.9.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex.construct">issues</a> in [re.regex.construct].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 317 and JP 74</b></p>
+
+<p>
+UK 317:
+</p>
+
+<blockquote>
+<tt>basic_string</tt> has both a constructor and an assignment operator that
+accepts an initializer list, <tt>basic_regex</tt> should have the same.
+</blockquote>
+
+<p>
+JP 74:
+</p>
+
+<blockquote>
+<tt>basic_regx & operator= (initializer_list<T>);</tt> is not defined.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+UK 317 asks for both assignment and constructor,
+but the requested constructor is already present in the current Working Paper.
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 28.9 [re.regex]:
+</p>
+
+<blockquote><pre>template <class charT,
+ class traits = regex_traits<charT> >
+class basic_regex {
+ ...
+ basic_regex& operator=(const charT* ptr);
+ <ins>basic_regex& operator=(initializer_list<charT> il);</ins>
+ template <class ST, class SA>
+ basic_regex& operator=(const basic_string<charT, ST, SA>& p);
+ ...
+};
+</pre></blockquote>
+
+<p>
+Add in 28.9.2 [re.regex.construct]:
+</p>
+
+<blockquote>
+<blockquote>
+-20- ...
+</blockquote>
+<pre>basic_regex& operator=(initializer_list<charT> il);
+</pre>
+<blockquote>
+-21- <i>Effects:</i> returns <tt>assign(il.begin(), il.end());</tt>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1015"></a>1015. Response to UK 199</h3>
+<p><b>Section:</b> 20.2.1 [concept.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#concept.transform">active issues</a> in [concept.transform].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.transform">issues</a> in [concept.transform].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 199</b></p>
+
+<p>
+The requirement that programs do not supply <tt>concept_maps</tt> should
+probably be users do not supply their own <tt>concept_map</tt>
+specializations. The program will almost certainly supply
+<tt>concept_maps</tt> - the standard itself supplies a specialization
+for <tt>RvalueOf</tt> references. Note that the term <i>program</i> is
+defined in 3.5 [basic.link]p1 and makes no account of the
+standard library being treated differently to user written code.
+</p>
+
+<p><i>[
+2009-05-09 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+The same problem is present in the words added for the
+<tt>LvalueReference/RvalueReference</tt> concepts last meeting.
+</p>
+<p>
+With three subsections requiring the same constraint, I'm wondering if there
+is a better way to organise this section.
+Possible 20.2.1 -> 20.2.3 belong in the fundamental concepts clause in
+14.10.4 [concept.support]? While they can be implemented purely as a
+library feature without additional compiler support, they are pretty
+fundamental and we want the same restriction on user-concept maps as is
+mandated there.
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the issue,
+but believe the wording needs further improvement.
+We want to investigate current definitions for nomenclature such as
+"user" and "program."
+Move to Open pending the recommended investigation.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.2.1 [concept.transform] p2:
+</p>
+
+<blockquote>
+-2- A <del>program</del> <ins>user</ins> shall not provide concept maps for
+any concept in 20.1.1.
+</blockquote>
+
+<p>
+Change 20.2.2 [concept.true] p2:
+</p>
+
+<blockquote>
+-2- <i>Requires:</i> a <del>program</del> <ins>user</ins> shall not
+provide a concept map for the <tt>True</tt> concept.
+</blockquote>
+
+<p>
+Change 20.2.3 [concept.classify] p2:
+</p>
+
+<blockquote>
+-2- <i>Requires:</i> a <del>program</del><ins>user</ins> shall not provide concept
+maps for any concept in this section.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1016"></a>1016. Response to JP 33</h3>
+<p><b>Section:</b> 20.2.6 [concept.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#concept.comparison">active issues</a> in [concept.comparison].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.comparison">issues</a> in [concept.comparison].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses JP 33</b></p>
+
+<p>
+<tt>LessThanComparable</tt> and <tt>EqualityComparable</tt> don't correspond to NaN.
+</p>
+
+<p><b>Original proposed resolution:</b></p>
+
+<p>
+Apply <tt>concept_map</tt> to these concepts at <tt>FloatingPointType</tt>.
+</p>
+
+<p><i>[
+Post Summit, Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I don't understand the proposed resolution - there is no such thing as a
+'negative' concept_map, and these concepts are auto concepts that match
+float/double etc. Also not clear how we are supposed to match values to
+concepts.
+</p>
+<p>
+Recommend NAD and treat as a subset of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Recommend NAD.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1017"></a>1017. Response to US 66</h3>
+<p><b>Section:</b> 20.2.11 [concept.regular] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses US 66</b></p>
+
+<p>
+Application of the <tt>Regular</tt> concept to floating-point types appears to be
+controversial (see long discussion on std-lib reflector).
+</p>
+
+<p><b>Original proposed resolution:</b></p>
+
+<p>
+State that the <tt>Regular</tt> concept does not apply to floating-point types.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Recommend that we handle the same as JP 33 / <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1016">1016</a>.
+</p>
+</blockquote>
+
+<p><i>[
+Post Summit, Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Recommend Open, and review after resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a> and revised axiom
+feature.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1018"></a>1018. Response to US 70</h3>
+<p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses US 70</b></p>
+
+<p>
+Specifications now expressed via narrative text are more accurately and
+clearly expressed via executable code.
+</p>
+<p>
+Wherever concepts are available that directly match this section's type
+traits, express the traits in terms of the concepts instead of via
+narrative text. Where the type traits do not quite match the
+corresponding concepts, bring the two into alignment so as to avoid two
+nearly-identical notions.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+We think that this is a good idea, but it requires a lot of work. If someone
+submits a paper proposing specific changes, we would be happy to review it
+at the next meeting.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1019"></a>1019. Response to UK 205</h3>
+<p><b>Section:</b> 20.6.3 [meta.help] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.help">active issues</a> in [meta.help].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.help">issues</a> in [meta.help].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 205</b></p>
+
+<p>
+<tt>integral_constant</tt> objects should be usable in integral-constant-expressions.
+The addition to the language of literal types and the enhanced rules for
+constant expressions make this possible.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree that the <tt>static</tt> data member
+ought be declared <tt>constexpr</tt>,
+but do not see a need for the proposed <tt>operator value_type()</tt>.
+(A use case would be helpful.)
+Move to Open.
+</blockquote>
+
+<p><i>[
+2009-05-23 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+The motivating case in my mind is that we can then use
+<tt>true_type</tt> and <tt>false_type</tt> as integral Boolean expressions, for example inside
+a <tt>static_assert</tt> declaration. In that sense it is purely a matter of style.
+</p>
+<p>
+Note that Boost has applied the non-explicit conversion operator for many
+years as it has valuable properties for extension into other metaprogramming
+libraries, such as MPL. If additional rationale is desired I will poll the
+Boost lists for why this extension was originally applied. I would argue
+that explicit conversion is more appropriate for 0x though.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to the <tt>integral_constant</tt> struct definition in 20.6.3 [meta.help]:
+</p>
+
+<blockquote><pre>template <class T, T v>
+struct integral_constant {
+ static const<ins>expr</ins> T value = v;
+ typedef T value_type;
+ typedef integral_constant<T,v> type;
+ <ins>constexpr operator value_type() { return value; }</ins>
+};
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1020"></a>1020. Response to UK 204</h3>
+<p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 204</b></p>
+
+<p>
+It is not possible to create a variant union based on a parameter pack
+expansion, e.g. to implement a classic discriminated union template.
+</p>
+
+<p><b>Original proposed resolutuion:</b></p>
+
+<p>
+Restore <tt>aligned_union</tt> template that was removed by LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree. The need for <tt>aligned_union</tt> is compelling enough to reinstate.
+</blockquote>
+
+<p><i>[
+Post Summit, Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2843.html">N2843</a>
+proposes an extension to the <tt>[[align]]</tt> attribute
+that further diminishes the need for this template. Recommend NAD.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1021"></a>1021. Response to UK 211</h3>
+<p><b>Section:</b> 20.8.12.2.3 [unique.ptr.single.asgn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 211</b></p>
+
+<p>
+The <tt>nullptr_t</tt> type was introduced to resolve the null pointer literal
+problem. It should be used for the assignemnt operator, as with the
+constructor and elsewhere through the library.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 20.8.12.2 [unique.ptr.single]:
+</p>
+
+<blockquote><pre>unique_ptr& operator=(<del><i>unspecified-pointer-type</i></del> <ins>nullptr_t</ins>);
+</pre></blockquote>
+
+<p>
+Change 20.8.12.2.3 [unique.ptr.single.asgn]:
+</p>
+
+<blockquote><pre>unique_ptr& operator=(<del><i>unspecified-pointer-type</i></del> <ins>nullptr_t</ins>);
+</pre>
+<blockquote>
+<del>Assigns from the literal 0 or <tt>NULL</tt>. [<i>Note:</i> The
+<i>unspecified-pointer-type</i> is often implemented as a pointer to a
+private data member, avoiding many of the implicit conversion pitfalls.
+<i>-- end note</i>]</del>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1023"></a>1023. Response to DE 22</h3>
+<p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses DE 22</b></p>
+
+<p>Related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.</p>
+
+<p>
+The conditions for deriving from <tt>std::unary_function</tt> and
+<tt>std::binary_function</tt> are unclear: The condition would also be satisfied if
+<tt>ArgTypes</tt> were <tt>std::vector<T1></tt>, because it (arguably)
+"contains" <tt>T1</tt>.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree. <tt>std::reference_wrapper</tt> has the same structure, and we
+suggest that <tt>std::function</tt> be presented in the same way as
+<tt>std::reference_wrapper</tt>.
+</blockquote>
+
+<p><i>[
+2009-05-09 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+Phrasing should be "publicly and
+unambiguously derived from" and probably back in reference_wrapper too. Updated
+wording supplied.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed wording.
+Move to NAD Editorial.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+(no changes to <tt><functional></tt> synopsis required)
+</p>
+
+<p>
+Change synopsis in Class template function 20.7.16.2 [func.wrap.func]:
+</p>
+
+<blockquote><pre>template<Returnable R, CopyConstructible... ArgTypes>
+class function<R(ArgTypes...)>
+ : public unary_function<T1, R> // <del><i>iff</i> sizeof...(ArgTypes) == 1 <i>and</i></del> <ins><i>see below</i></ins>
+ <del>// ArgTypes <i>contains</i> T1</del>
+ : public binary_function<T1, T2, R> // <del><i>iff</i> sizeof...(ArgTypes) == 2 <i>and</i></del> <ins><i>see below</i></ins>
+ <del>// ArgTypes <i>contains</i> T1 <i>and</i> T2</del>
+{
+ ...
+</pre></blockquote>
+
+<p>
+Add new p1/p2 before 20.7.16.2.1 [func.wrap.func.con]:
+</p>
+
+<blockquote>
+<p><ins>
+The template instantiation <tt>function<R(T1)></tt> shall be publicly and
+unambiguously derived from
+<tt>std::unary_function<T1,R></tt> if and only if the template type parameter
+is a function type taking one argument of type <tt>T1</tt> and returning <tt>R</tt>.
+</ins></p>
+
+<p><ins>
+The template instantiation <tt>function<R(T1,T2)></tt> shall be publicly and
+unambiguously derived from
+<tt>std::binary_function<T1,T2,R></tt> if and only if the template type
+parameter is a function type taking two arguments of type <tt>T1</tt> and <tt>T2</tt> and
+returning <tt>R</tt>.
+</ins></p>
+
+<pre>explicit function();
+</pre>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1024"></a>1024. Response to JP 39</h3>
+<p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses JP 39</b></p>
+
+<p>
+There are no requires corresponding to <tt>F</tt> of <tt>std::function</tt>.
+</p>
+
+<p><i>[
+2009-05-01 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a> removes the second constructor.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+If issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a> is accepted,
+the changes to the second constructor
+in this issue are moot.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Correct as follows in 20.7.16.2 [func.wrap.func] (class definition)
+</p>
+
+<blockquote><pre> template<class F, Allocator Alloc>
+ <ins>requires ConstructibleWithAllocator<F, Alloc>
+ && call=Callable<F, ArgTypes...>
+ && Convertible<call::result_type, R></ins>
+ function(allocator_arg_t, const Alloc&, F);
+ template<class F, Allocator Alloc>
+ <ins>requires ConstructibleWithAllocator<F,Alloc>
+ && call=Callable<F, ArgTypes...>
+ && Convertible<call::result_type, R></ins>
+ function(allocator_arg_t, const Alloc&, F&&);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1026"></a>1026. Response to UK 209</h3>
+<p><b>Section:</b> 20.8 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#memory">active issues</a> in [memory].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#memory">issues</a> in [memory].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 209</b></p>
+
+<p>
+Smart pointers cannot be used in constrained templates.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+We look forward to a paper on this topic. We recommend no action until a
+paper is available. We understand that a paper is forthcoming.
+</blockquote>
+
+<p><i>[
+Peter Dimov adds:
+]</i></p>
+
+
+<blockquote>
+<tt>shared_ptr<T></tt> and <tt>weak_ptr<T></tt> support all
+types <tt>T</tt> for which <tt>T*</tt> is valid. In other words, a
+possible (partial) resolution is to change class <tt>T</tt> to
+<tt>PointeeType T</tt> for <tt>shared_ptr</tt>, <tt>weak_ptr</tt> and
+possibly <tt>enable_shared_from_this</tt>.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1027"></a>1027. Response to UK 213</h3>
+<p><b>Section:</b> 20.8.6 [default.allocator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-13</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 213</b></p>
+
+<p>
+<tt>std::allocator</tt> should be constrained to simplify its use on constrained
+contexts. This library component models allocation from free store via the
+new operator so choose constraints to
+match. The Allocator concept allows for a wider variety of allocators that
+users may choose to supply if their allocation model does not require
+operator new, without impacting the
+requirements of this template.
+</p>
+
+<p>
+Suggested direction:
+</p>
+<p>
+The primary allocator template should be constrained to require
+<tt>ObjectType<T></tt> and <tt>FreeStoreAllocatable<T></tt>.
+Further operations to be constrained as required.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree as stated. A future paper will address additional related issues.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1028"></a>1028. Response to UK 214</h3>
+<p><b>Section:</b> 20.8.8 [storage.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-15</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 214</b></p>
+
+<p>
+<tt>raw_storage_iterator</tt> needs constraining as an iterator adaptor to be safely
+used in constrained templates
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+We look forward to a paper on this topic. We recommend no action until a
+paper is available.
+</blockquote>
+
+<p><i>[
+Post Summit Alisdair provided wording and rationale.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+20.8 [memory] p2
+</p>
+<p>
+Update the synopsis for <tt><memory></tt>
+</p>
+<blockquote><pre>// 20.7.8, raw storage iterator:
+template <<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T>
+ <ins>requires OutputIterator< OutIter, T ></ins>
+ class raw_storage_iterator;
+
+<ins>template <ForwardIterator OutIter, ObjectType T>
+ requires OutputIterator< OutIter, T >
+ concept_map Iterator<raw_storage_iterator< OutIter, T > > { }</ins>
+</pre></blockquote>
+
+
+<p>
+20.8.8 [storage.iterator] p1
+</p>
+<p>
+Replace class template definition with:
+</p>
+<blockquote><pre>namespace std {
+ template <<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T>
+ <ins>requires OutputIterator< OutIter, T ></ins>
+ class raw_storage_iterator
+ : public iterator<output_iterator_tag,void,void,void,void> {
+ public:
+ explicit raw_storage_iterator(Out<del>put</del>Iter<del>ator</del> x);
+
+ raw_storage_iterator<del><OutputIterator,T></del>& operator*();
+ raw_storage_iterator<del><OutputIterator,T></del>& operator=(const T& element);
+ raw_storage_iterator<del><OutputIterator,T></del>& operator++();
+ raw_storage_iterator<del><OutputIterator,T></del> operator++(int);
+ };
+
+ <ins>template <ForwardIterator OutIter, ObjectType T>
+ requires OutputIterator< OutIter, T >
+ concept_map Iterator<raw_storage_iterator< OutIter, T > > { }</ins>
+}
+</pre></blockquote>
+
+
+<p><b>Rationale:</b></p>
+<p>
+<tt>raw_storage_iterator</tt> has to adapt a <tt>ForwardIterator</tt>,
+rather than just an <tt>InputIterator</tt> for two reasons:
+</p>
+
+<ol type="i">
+<li>
+The initial iterator passed by value is expected to remain valid,
+pointing to the initialized region of memory.
+</li>
+<li>
+to avoid breaking the declaration of post-increment operator which would
+require some kind of proxy formulation to support generalised InputIterators.
+</li>
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="1029"></a>1029. Response to UK 210</h3>
+<p><b>Section:</b> 20.8.11 [specialized.algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-15</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#specialized.algorithms">issues</a> in [specialized.algorithms].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 210</b></p>
+
+<p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a></p>
+
+<p>
+Specialized algorithms for memory managenment need requirements to be
+easily usable in constrained templates.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+We look forward to a paper on this topic. We recommend no action until a
+paper is available.
+</blockquote>
+
+<p><i>[
+Post Summit Alisdair provided wording.
+]</i></p>
+
+
+<p><i>[
+Post Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Daniel adds:
+</p>
+
+<blockquote>
+<ol>
+<li>
+I suggest <tt>Size</tt> should require <tt>IntegralLike</tt> and not <tt>UnsignedIntegralLike</tt>,
+because otherwise simple int-literals could not be provided as arguments
+and it would conflict with other algorithms that only require <tt>IntegralLike</tt>.
+</li>
+<li>
+<p>
+The current for-loop-test relies on evaluation in boolean context which is
+not provided by <tt>ArithmeticLike</tt> and it's refinements. I propose to change the
+corresponding for-loop-headers to:
+</p>
+<ol type="a">
+<li>
+for <tt>uninitialized_copy_n</tt>: <tt>for ( ; n > Size(0); ++result, ++first, --n) {</tt>
+</li>
+<li>
+for <tt>uninitialized_fill_n</tt>: <tt>for (; n > Size(0); ++first, --n) {</tt>
+</li>
+</ol>
+</li>
+</ol>
+</blockquote>
+
+<p>
+Alisdair adds:
+</p>
+<blockquote>
+For the record I agree with Daniel's suggestion.
+</blockquote>
+
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+20.8 [memory] p2
+</p>
+<p>
+Update the synopsis for <tt><memory></tt>
+</p>
+<blockquote><pre>template <<del>class</del> InputIterator <ins>InIter</ins>,
+ <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>>
+ <ins>requires ForwardIterator<OutIter></ins>
+ <del>ForwardIterator</del> <ins>OutIter</ins>
+ uninitialized_copy(<del>InputIterator</del> <ins>InIter</ins> first, <del>InputIterator</del> <ins>InIter</ins> last,
+ <del>ForwardIterator</del> <ins>OutIter</ins> result);
+
+template <<del>class</del> InputIterator <ins>InIter</ins>,
+ <del>class</del> <ins>IntegralLike</ins> Size,
+ <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>>
+ <ins>requires ForwardIterator<OutIter></ins>
+ <del>ForwardIterator</del> <ins>OutIter</ins>
+ uninitialized_copy_n(<del>InputIterator</del> <ins>InIter</ins> first, Size n,
+ <del>ForwardIterator</del> <ins>OutIter</ins> result);
+
+template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T>
+ <ins>requires Constructible< Iter::value_type, const T& ></ins>
+ void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last,
+ const T& x);
+
+template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T>
+ <ins>requires Constructible< Iter::value_type, const T& ></ins>
+ void
+ uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T& x);
+</pre></blockquote>
+
+<p>
+Update as follows:
+</p>
+
+<p>
+uninitialized_copy 20.8.11.2 [uninitialized.copy]
+</p>
+
+<blockquote><pre>template <<del>class</del> InputIterator <ins>InIter</ins>,
+ <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>>
+ <ins>requires ForwardIterator<OutIter></ins>
+ <del>ForwardIterator</del> <ins>OutIter</ins>
+ uninitialized_copy(<del>InputIterator</del> <ins>InIter</ins> first, <del>InputIterator</del> <ins>InIter</ins> last,
+ <del>ForwardIterator</del> <ins>OutIter</ins> result);
+</pre>
+
+<blockquote>
+<p>
+-1- <i>Effects:</i>
+</p>
+<blockquote><pre>for (; first != last; ++result, ++first) {
+ new (static_cast<void*>(&*result))
+ <del>typename iterator_traits<ForwardIterator></del> <ins>OutIter</ins>::value_type(*first);
+}
+</pre></blockquote>
+
+<p>
+-2- <i>Returns:</i> <tt>result</tt>
+</p>
+
+</blockquote>
+
+<pre>template <<del>class</del> InputIterator <ins>InIter</ins>,
+ <del>class</del> <ins>IntegralLike</ins> Size,
+ <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>>
+ <ins>requires ForwardIterator<OutIter></ins>
+ <del>ForwardIterator</del> <ins>OutIter</ins>
+ uninitialized_copy_n(<del>InputIterator</del> <ins>InIter</ins> first, Size n,
+ <del>ForwardIterator</del> <ins>OutIter</ins> result);
+</pre>
+
+<blockquote>
+<p>
+-3- Effects:
+</p>
+<blockquote><pre>for ( ; n > <ins>Size(</ins>0<ins>)</ins>; ++result, ++first, --n) {
+ new (static_cast<void*>(&*result))
+ <del>typename iterator_traits<ForwardIterator></del> <ins>OutIter</ins>::value_type(*first);
+}
+</pre></blockquote>
+<p>
+-4- <i>Returns:</i> result
+</p>
+</blockquote>
+
+</blockquote>
+
+
+<p>
+uninitialized_fill 20.8.11.3 [uninitialized.fill]
+</p>
+
+<blockquote><pre>template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T>
+ <ins>requires Constructible< Iter::value_type, const T& ></ins>
+ void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last,
+ const T& x);
+</pre>
+
+<blockquote>
+<p>
+-1- <i>Effects:</i>
+</p>
+<blockquote><pre>for (; first != last; ++first) {
+ new ( static_cast<void*>( &*first) )
+ <del>typename iterator_traits<ForwardIterator></del> <ins>Iter</ins>::value_type(x);
+}
+</pre></blockquote>
+</blockquote>
+</blockquote>
+
+
+<p>
+uninitialized_fill_n 20.8.11.4 [uninitialized.fill.n]
+</p>
+
+<blockquote><pre>template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T>
+ <ins>requires Constructible< Iter::value_type, const T& ></ins>
+ void
+ uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T& x);
+</pre>
+
+<blockquote>
+<p>
+-1- <i>Effects:</i>
+</p>
+<blockquote><pre>for (; n<del>--</del> <ins>> Size(0)</ins>; ++first<ins>, --n</ins>) {
+ new ( static_cast<void*>( &*first) )
+ <del>typename iterator_traits<ForwardIterator></del> <ins>Iter</ins>::value_type(x);
+}
+</pre></blockquote>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1030"></a>1030. Response to JP 44</h3>
+<p><b>Section:</b> 20.8.13.6 [util.smartptr.shared.atomic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses JP 44</b></p>
+
+<p>
+The 1st parameter <tt>p</tt> and 2nd parameter <tt>v</tt> is now
+<tt>shared_ptr<T>*</tt>.
+</p>
+<p>
+It should be <tt>shared_ptr<T>&</tt>, or if these are
+<tt>shared_ptr<T>*</tt> then add the "<tt>p</tt> shall not be a
+null pointer" at the requires.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree. All of the functions need a requirement that <tt>p</tt> (or
+<tt>v</tt>) is a pointer to a valid object.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1031"></a>1031. Response to US 78</h3>
+<p><b>Section:</b> 20.8.13.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses US 78</b></p>
+
+<p>
+There is presently no way to convert directly from a <tt>shared_ptr</tt> to a
+<tt>unique_ptr</tt>. Add an interface that performs the conversion.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+We look forward to a paper on this topic. We recommend no action until a
+paper is available. We believe that the shared pointer must use the default
+deleter for the conversion to succeed.
+</blockquote>
+
+<p><i>[
+Peter Dimov adds:
+]</i></p>
+
+
+<blockquote>
+This is basically a request for <tt>shared_ptr<>::release</tt> in
+disguise, with all the associated problems. Not a good idea.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1032"></a>1032. Response to JP 45</h3>
+<p><b>Section:</b> 20.9 [time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time">issues</a> in [time].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses JP 45</b></p>
+
+<p>
+<tt>Rep</tt>, <tt>Period</tt>, <tt>Clock</tt> and <tt>Duration</tt>
+don't correspond to concept.
+</p>
+<blockquote><pre>template <class Rep, class Period = ratio<1>> class duration;
+template <class Clock, class Duration = typename Clock::duration> class time_point;
+</pre></blockquote>
+<p>
+Make concept for <tt>Rep</tt>, <tt>Period</tt>, <tt>Clock</tt> and <tt>Duration</tt>.
+Fix 20.9 [time] and <tt>wait_until</tt>
+and <tt>wait_for</tt>'s template parameter at 30 [thread].
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+We agree that this section needs concepts. We look forward to a paper on
+this topic. We recommend no action until a paper is available.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1033"></a>1033. <tt>thread::join()</tt> effects?</h3>
+<p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.member">active issues</a> in [thread.thread.member].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+While looking at <tt>thread::join()</tt> I think I spotted a couple of
+possible defects in the specifications. I could not find a previous
+issue or NB comment about that, but I might have missed it.
+</p>
+
+<p>
+The postconditions clause for <tt>thread::join()</tt> is:
+</p>
+
+<blockquote>
+<i>Postconditions:</i> If <tt>join()</tt> throws an exception, the value
+returned by <tt>get_id()</tt> is unchanged. Otherwise, <tt>get_id() == id()</tt>.
+</blockquote>
+
+<p>
+and the throws clause is:
+</p>
+
+<blockquote>
+<i>Throws:</i> <tt>std::system_error</tt> when the postconditions cannot be achieved.
+</blockquote>
+
+<p>
+Now... how could the postconditions <em>not</em> be achieved?
+It's just a matter of resetting the value of <tt>get_id()</tt> or leave it
+unchanged! I bet we can always do that. Moreover, it's a chicken-and-egg
+problem: in order to decide whether to throw or not I depend on the
+postconditions, but the postconditions are different in the two cases.
+</p>
+
+<p>
+I believe the throws clause should be:
+</p>
+
+<blockquote>
+<i>Throws:</i> <tt>std::system_error</tt> when the effects or postconditions
+cannot be achieved.
+</blockquote>
+
+<p>
+as it is in <tt>detach()</tt>, or, even better, as the postcondition is
+trivially satisfiable and to remove the circular dependency:
+</p>
+
+
+<blockquote>
+<i>Throws:</i> <tt>std::system_error</tt> if the effects cannot be achieved.
+</blockquote>
+
+<p>
+Problem is that... ehm... <tt>join()</tt> has no "Effects" clause. Is that intentional?
+</p>
+
+<p><i>[
+See the thread starting at c++std-lib-23204 for more discussion.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Pete believes there may be some more general language (in frontmatter)
+that can address this and related issues such as <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1034"></a>1034. Response to UK 222</h3>
+<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 222</b></p>
+
+<p>
+It is not clear what purpose the Requirement tables serve in the
+Containers clause. Are they the definition of a library Container? Or
+simply a conventient shorthand to factor common semantics into a single
+place, simplifying the description of each subsequent container? This
+becomes an issue for 'containers' like <tt>array</tt>, which does not meet the
+default-construct-to-empty requirement, or <tt>forward_list</tt> which does not
+support the size operation. Are these components no longer containers?
+Does that mean the remaining requirements don't apply? Or are these
+contradictions that need fixing, despite being a clear design decision?
+</p>
+
+<p>
+Recommend:
+</p>
+
+<p>
+Clarify all the tables in 23.2 [container.requirements] are
+there as a convenience for documentation, rather than a strict set of
+requirements. Containers should be allowed to relax specific
+requirements if they call attention to them in their documentation. The
+introductory text for <tt>array</tt> should be expanded to mention a
+default constructed <tt>array</tt> is not empty, and
+<tt>forward_list</tt> introduction should mention it does not provide
+the required <tt>size</tt> operation as it cannot be implemented
+efficiently.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree in principle.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1035"></a>1035. Response to UK 226</h3>
+<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-02</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 226</b></p>
+
+<p>
+<tt><array></tt> must be added to this list. In particular it
+doesn't satisfy: - no <tt>swap()</tt> function invalidates any
+references, pointers, or iterators referring to the elements of the
+containers being swapped. and probably doesn't satisfy: - no
+<tt>swap()</tt> function throws an exception.
+</p>
+<p>
+If <tt><array></tt> remains a container, this will have to also
+reference <tt>array</tt>, which will then have to say which of these
+points it satisfies.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree. The proposed resolution is incomplete. Further work required.
+</blockquote>
+
+<p><i>[
+2009-05-01 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a> also suggests
+adding move constructor to this.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1036"></a>1036. Response to UK 231</h3>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 231</b></p>
+
+<p>
+p9-p11 are redundant now that Concepts define what it means to be an
+Iterator and guide overload resolution accordingly.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree with issue and change to 23.2.3 [sequence.reqmts]. The
+changes required to 21 [strings] will be part of the general
+concept support for that clause.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Strike 23.2.3 [sequence.reqmts]p9-11. Make sure <tt>std::basic_string</tt>
+has constraints similar to
+<tt>std::vector</tt> to meet this old guarantee.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1037"></a>1037. Response to UK 232</h3>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 232</b></p>
+
+<p>
+<tt>match_results</tt> may follow the requirements but is not listed a general
+purpose library container.
+</p>
+
+<p>
+Remove reference to <tt>match_results</tt> against <tt>a[n]</tt> operation.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree. <tt>operator[]</tt> is defined elsewhere.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 23.2.3 [sequence.reqmts] Table 84, remove reference to
+<tt>match_results</tt> in the row describing the <tt>a[n]</tt> operation.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1038"></a>1038. Response to UK 233</h3>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 233</b></p>
+
+<p>
+Table 84 is missing references to several new container types.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 23.2.3 [sequence.reqmts] Table 84, Add reference to listed
+containers to the following rows:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 84 -- Optional sequence container operations</caption>
+<tbody><tr>
+<th>Expression</th>
+<th>Return type</th>
+<th>Operational semantics</th>
+<th>Container</th>
+</tr>
+<tr>
+<td><tt>a.front()</tt></td>
+<td>...</td>
+<td>...</td>
+<td><tt>vector, list, deque, basic_string<ins>, array, forward_list</ins></tt></td>
+</tr>
+<tr>
+<td><tt>a.back()</tt></td>
+<td>...</td>
+<td>...</td>
+<td><tt>vector, list, deque, basic_string<ins>, array</ins></tt></td>
+</tr>
+<tr>
+<td><tt>a.emplace_front(args)</tt></td>
+<td>...</td>
+<td>...</td>
+<td><tt>list, deque<ins>, forward_list</ins></tt></td>
+</tr>
+<tr>
+<td><tt>a.push_front(t)</tt></td>
+<td>...</td>
+<td>...</td>
+<td><tt>list, deque<ins>, forward_list</ins></tt></td>
+</tr>
+<tr>
+<td><tt>a.push_front(rv)</tt></td>
+<td>...</td>
+<td>...</td>
+<td><tt>list, deque<ins>, forward_list</ins></tt></td>
+</tr>
+<tr>
+<td><tt>a.pop_front()</tt></td>
+<td>...</td>
+<td>...</td>
+<td><tt>list, deque<ins>, forward_list</ins></tt></td>
+</tr>
+<tr>
+<td><tt>a[n]</tt></td>
+<td>...</td>
+<td>...</td>
+<td><tt>vector, deque, basic_string<ins>, array</ins></tt></td>
+</tr>
+<tr>
+<td><tt>a.at(n)</tt></td>
+<td>...</td>
+<td>...</td>
+<td><tt>vector, deque<ins>, basic_string, array</ins></tt></td>
+</tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1039"></a>1039. Response to UK 234</h3>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 234</b></p>
+
+<p>
+The reference to <tt>iterator</tt> in semantics for <tt>back</tt> should
+also allow for <tt>const_iterator</tt> when called on a const-qualified
+container. This would be ugly to specify in the 03 standard, but is
+quite easy with the addition of <tt>auto</tt> in this new standard.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 23.2.3 [sequence.reqmts] Table 84, replace iterator with auto in semantics for back:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 84 -- Optional sequence container operations</caption>
+<tbody><tr>
+<th>Expression</th>
+<th>Return type</th>
+<th>Operational semantics</th>
+<th>Container</th>
+</tr>
+<tr>
+<td><tt>a.back()</tt></td>
+<td><tt>reference; const_reference</tt> for constant <tt>a</tt></td>
+<td><tt>{ <del>iterator</del> <ins>auto</ins> tmp = a.end();<br>--tmp;<br>return *tmp; }</tt></td>
+<td><tt>vector, list, deque, basic_string</tt></td>
+</tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1040"></a>1040. Response to UK 238</h3>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 238</b></p>
+
+<p>
+Leaving it unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt> are the
+same type is dangerous, as user code may or may not violate the One
+Definition Rule by providing overloads for
+both types. It is probably too late to specify a single behaviour, but
+implementors should document what to expect. Observing that problems can be
+avoided by users restricting themselves to using <tt>const_iterator</tt>, add a note to that effect.
+</p>
+<p>
+Suggest Change 'unspecified' to 'implementation defined'.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree with issue. Agree with adding the note but not with changing the
+normative text. We believe the note provides sufficient guidance.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 23.2.4 [associative.reqmts] p6, add:
+</p>
+
+<blockquote>
+-6- <tt>iterator</tt> of an associative container meets the requirements
+of the <tt>BidirectionalIterator</tt> concept. For associative
+containers where the value type is the same as the key type, both
+<tt>iterator</tt> and <tt>const_iterator</tt> are constant iterators. It
+is unspecified whether or not <tt>iterator</tt> and
+<tt>const_iterator</tt> are the same type.
+<ins>[<i>Note:</i> <tt>iterator</tt> and <tt>const_iterator</tt> have identical semantics in
+this case, and <tt>iterator</tt> is convertible to <tt>const_iterator</tt>. Users can avoid
+violating the One Definition Rule by always using <tt>const_iterator</tt>
+in their function parameter lists <i>-- end note</i>]</ins>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1041"></a>1041. Response to UK 239</h3>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 239</b></p>
+
+<p>
+It is not possible to take a move-only key out of an unordered
+container, such as (<tt>multi</tt>)<tt>set</tt> or
+(<tt>multi</tt>)<tt>map</tt>, or the new unordered containers.
+</p>
+
+<p>
+Add below <tt>a.erase(q)</tt>, <tt>a.extract(q)</tt>, with the following notation:
+</p>
+<p>
+<tt>a.extract(q)></tt>, Return type <tt>pair<key, iterator></tt>
+Extracts the element pointed to by <tt>q</tt> and erases it from the
+<tt>set</tt>. Returns a <tt>pair</tt> containing the value pointed to by
+<tt>q</tt> and an <tt>iterator</tt> pointing to the element immediately
+following <tt>q</tt> prior to the element being erased. If no such
+element exists,returns <tt>a.end()</tt>.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+We look forward to a paper on this topic. We recommend no action until a
+paper is available. The paper would need to address exception safety.
+</blockquote>
+
+<p><i>[
+Post Summit Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+Would <tt>value_type</tt> be a better return type than <tt>key_type</tt>?
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 23.2.4 [associative.reqmts] Table 85, add:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 85 -- Associative container requirements (in addition to container)</caption>
+<tbody><tr>
+<th>Expression</th>
+<th>Return type</th>
+<th>Assertion/note<br>pre-/post-condition</th>
+<th>Complexity</th>
+</tr>
+<tr><td><tt>a.erase(q)</tt></td>
+<td>...</td>
+<td>...</td>
+<td>...</td>
+</tr><tr>
+<td><ins><tt>a.extract(q)</tt></ins></td>
+<td><ins><tt>pair<key_type, iterator></tt></ins></td>
+<td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>.
+Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
+pointing to the element immediately following <tt>q</tt> prior to the element being
+erased. If no such element
+exists, returns <tt>a.end()</tt>.</ins></td>
+<td><ins>amortized constant</ins></td>
+</tr>
+</tbody></table>
+</blockquote>
+
+<p>
+In 23.2.5 [unord.req] Table 87, add:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 87 -- Unordered associative container requirements (in addition to container)</caption>
+<tbody><tr>
+<th>Expression</th>
+<th>Return type</th>
+<th>Assertion/note<br>pre-/post-condition</th>
+<th>Complexity</th>
+</tr>
+<tr><td><tt>a.erase(q)</tt></td>
+<td>...</td>
+<td>...</td>
+<td>...</td>
+</tr><tr>
+<td><ins><tt>a.extract(q)</tt></ins></td>
+<td><ins><tt>pair<key_type, iterator></tt></ins></td>
+<td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>.
+Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
+pointing to the element immediately following <tt>q</tt> prior to the element being
+erased. If no such element
+exists, returns <tt>a.end()</tt>.</ins></td>
+<td><ins>amortized constant</ins></td>
+</tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1042"></a>1042. Response to UK 244</h3>
+<p><b>Section:</b> 23.3 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-14</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequences">issues</a> in [sequences].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 244</b></p>
+
+<p>
+The validity of the expression <tt>&a[n] == &a[0] + n</tt> is contingent on
+<tt>operator&</tt> doing the "right thing" (as captured by the <tt>CopyConstructible</tt>
+requirements in table 30 in C++2003). However this constraint has been
+lost in the Concepts of C++0x. This applies to <tt>vector</tt> and <tt>array</tt> (it
+actually applies to <tt>string</tt> also, but that's a different chapter, so I'll
+file a separate comment there and cross-reference).
+</p>
+
+<p>
+Suggested solution:
+</p>
+
+<p>
+Define a <tt>ContiguousStrorage</tt> and apply it to
+<tt>vector</tt>, <tt>array</tt> and <tt>string</tt>.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree with the issue but not the details of the proposed solution. Walter to
+provide wording for the new concept.
+</blockquote>
+
+<p><i>[
+Post Summit Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+Another LWG subgroup wondered if this concept
+should extend to <tt>complex<T></tt>, and so not be built on the container concept at
+all?
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to <tt><container_concepts></tt> synopsis in 23.2.6 [container.concepts]
+</p>
+
+<blockquote><pre><ins>concept< typename C > ContiguousStorageContainer <i>see below</i>;</ins>
+</pre></blockquote>
+
+<p>
+Add a new section to the end of 23.2.6 [container.concepts]
+</p>
+
+<blockquote>
+<p>
+23.1.6.x ContiguousStorageContainer concept [container.concepts.contiguous]
+</p>
+
+<pre>concept ContiguousStorageContainer< typename C >
+ : Container<C>
+{
+ value_type* data(C&);
+
+ axiom Contiguity(C& c, size_type i) {
+ if( i < size(c) ) {
+ addressof( * (data(c) + i) )
+ == addressof( * advance(data(c), i) );
+ }
+ }
+}
+</pre>
+
+<p>
+The <tt>ContiguousStorageContainer</tt> concept describes a container whose elements
+are allocated in a single region of memory, and are stored sequentially
+without intervening padding other than to meet alignment requirements.
+For example, the elements may be stored in a
+single array of suitable length.
+</p>
+
+<pre>value_type * data( C& );
+</pre>
+
+<blockquote>
+<i>Returns:</i> a pointer to the first element in the region of storage.
+Result is unspecified for an empty container.
+</blockquote>
+
+</blockquote>
+
+<p>
+Change 23.3.1 [array] p1:
+</p>
+
+<blockquote>
+-1- The header <tt><array></tt> defines a class template for
+storing fixed-size sequences of objects. An <tt>array</tt> supports
+random access iterators. An instance of <tt>array<T, N></tt>
+stores <tt>N</tt> elements of type <tt>T</tt>, so that <tt>size() ==
+N</tt> is an invariant. The elements of an <tt>array</tt> are stored
+contiguously, meaning that <del>if <tt>a</tt> is</del> an
+<tt>array<T, N></tt> <del>then it obeys the identity <tt>&a[n]
+== &a[0] + n</tt> for all <tt>0 <= n < N</tt></del>
+<ins>satisfies the concept <tt>ContiguousStorageContainer< array<T,
+N>></tt></ins>.
+</blockquote>
+
+<p>
+Add to the synopsis in 23.3.1 [array]:
+</p>
+
+<blockquote><pre> ...
+ T * data();
+ const T * data() const;
+ };
+
+ <ins>template< typename T, size_t N ></ins>
+ <ins>concept_map ContiguousStorageContainer< array<T, N>> {};</ins>
+}
+</pre></blockquote>
+
+<p>
+Change 23.3.6 [vector] p1:
+</p>
+
+<blockquote>
+A <tt>vector</tt> is a sequence container that supports random access
+iterators. In addition, it supports (amortized) constant time insert and
+erase operations at the end; insert and erase in the middle take linear
+time. Storage management is handled automatically, though hints can be
+given to improve efficiency. The elements of a vector are stored
+contiguously, meaning that <del>if <tt>v</tt> is</del> a
+<tt>vector<T, Alloc></tt> <ins>(</ins>where <tt>T</tt> is some
+type other than <tt>bool</tt><ins>)</ins><del>, then it obeys the
+identity <tt>&v[n] == &v[0] + n</tt> for all <tt>0 <= n <
+v.size()</tt></del> <ins>satisfies the concept <tt>ContiguousStorageContainer<
+vector< T, Alloc>></tt></ins>.
+</blockquote>
+
+<p>
+Add at the end of the synopsis in 23.3.6 [vector] p2:
+</p>
+
+<blockquote><pre><ins>template< typename T, typename A >
+ requires !SameType< T, bool >
+ concept_map ContiguousStorageContainer< vector<T, A>> {};</ins>
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1043"></a>1043. Response to US 91</h3>
+<p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses US 91</b></p>
+
+<p>
+It is unclear whether or not a failed <tt>compare_exchange</tt> is a RMW operation
+(as used in 1.10 [intro.multithread]).
+</p>
+
+<p>
+Suggested solution:
+</p>
+
+<p>
+Make failing <tt>compare_exchange</tt> operations <b>not</b> be RMW.
+</p>
+
+<p><i>[
+Anthony Williams adds:
+]</i></p>
+
+
+<blockquote>
+In 29.6 [atomics.types.operations] p18 it says that "These
+operations are atomic read-modify-write operations" (final sentence).
+This is overly restrictive on the implementations of
+<tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> on platforms without a
+native CAS instruction.
+</blockquote>
+
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Group agrees with the resolution as proposed by Anthony Williams in the attached note.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We recommend the proposed resolution be reviewed
+by members of the Concurrency Subgroup.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 29.6 [atomics.types.operations] p18:
+</p>
+
+<blockquote>
+-18- <i>Effects:</i> Atomically, compares the value pointed to by
+<tt>object</tt> or by <tt>this</tt> for equality with that in
+<tt>expected</tt>, and if true, replaces the value pointed to by
+<tt>object</tt> or by <tt>this</tt> with desired, and if false, updates
+the value in <tt>expected</tt> with the value pointed to by
+<tt>object</tt> or by <tt>this</tt>. Further, if the comparison is true,
+memory is affected according to the value of <tt>success</tt>, and if the
+comparison is false, memory is affected according to the value of
+<tt>failure</tt>. When only one <tt>memory_order</tt> argument is
+supplied, the value of <tt>success</tt> is <tt>order</tt>, and the value
+of <tt>failure</tt> is <tt>order</tt> except that a value of
+<tt>memory_order_acq_rel</tt> shall be replaced by the value
+<tt>memory_order_acquire</tt> and a value of
+<tt>memory_order_release</tt> shall be replaced by the value
+<tt>memory_order_relaxed</tt>. <ins>If the comparison is <tt>true</tt>, </ins>
+<del>T</del><ins>t</ins>hese operations are atomic
+read-modify-write operations (1.10).
+<ins>If the comparison is <tt>false</tt>, these
+operations are atomic load operations.</ins>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1044"></a>1044. Response to UK 325</h3>
+<p><b>Section:</b> 30.4 [thread.mutex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 325</b></p>
+
+<p>
+We believe constexpr literal values should be a more natural expression
+of empty tag types than extern objects as it should improve the
+compiler's ability to optimize the empty object away completely.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Move to review. The current specification is a "hack", and the proposed
+specification is a better "hack".
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 30.4 [thread.mutex]:
+</p>
+
+<blockquote><pre>struct defer_lock_t <ins>{}</ins>;
+struct try_to_lock_t <ins>{}</ins>;
+struct adopt_lock_t <ins>{}</ins>;
+
+<del>extern</del> const<ins>expr</ins> defer_lock_t defer_lock <ins>{}</ins>;
+<del>extern</del> const<ins>expr</ins> try_to_lock_t try_to_lock <ins>{}</ins>;
+<del>extern</del> const<ins>expr</ins> adopt_lock_t adopt_lock <ins>{}</ins>;
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1045"></a>1045. Response to UK 326</h3>
+<p><b>Section:</b> 30.4.3.2.1 [thread.lock.unique.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 326</b></p>
+
+<p>
+The precondition that the mutex is not owned by this thread offers
+introduces the risk of un-necessary undefined behaviour into the
+program. The only time it matters whether the current thread owns the
+mutex is in the lock operation, and that will happen subsequent to
+construction in this case. The lock operation has the identical
+pre-condition, so there is nothing gained by asserting that precondition
+earlier and denying the program the right to get into a valid state
+before calling lock.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+Agree, move to review.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Strike 30.4.3.2.1 [thread.lock.unique.cons] p7:
+</p>
+
+<blockquote><pre>unique_lock(mutex_type& m, defer_lock_t);
+</pre>
+<blockquote>
+<del>-7- <i>Precondition:</i> If <tt>mutex_type</tt> is not a recursive mutex
+the calling thread does not own the mutex.</del>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1046"></a>1046. Response to UK 329</h3>
+<p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-13</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 329</b></p>
+
+<p>
+<tt>future</tt>, <tt>promise</tt> and <tt>packaged_task</tt> provide a
+framework for creating future values, but a simple function to tie all
+three components together is missing. Note that we only need a *simple*
+facility for C++0x. Advanced thread pools are to be left for TR2.
+</p>
+
+<p>
+Simple Proposal:
+</p>
+
+<p>
+Provide a simple function along the lines of:
+</p>
+<blockquote><pre>template< typename F, typename ... Args >
+ requires Callable< F, Args... >
+ future< Callable::result_type > async( F&& f, Args && ... );
+</pre></blockquote>
+
+<p>
+Semantics are similar to creating a <tt>thread</tt> object with a <tt>packaged_task</tt>
+invoking <tt>f</tt> with <tt>forward<Args>(args...)</tt>
+but details are left unspecified to allow different scheduling and thread
+spawning implementations.
+</p>
+<p>
+It is unspecified whether a task submitted to async is run on its own thread
+or a thread previously used for another async task. If a call to <tt>async</tt>
+succeeds, it shall be safe to wait for it from any thread.
+</p>
+<p>
+The state of <tt>thread_local</tt> variables shall be preserved during <tt>async</tt> calls.
+</p>
+<p>
+No two incomplete async tasks shall see the same value of
+<tt>this_thread::get_id()</tt>.
+</p>
+<p>
+[<i>Note:</i> this effectively forces new tasks to be run on a new thread, or a
+fixed-size pool with no queue. If the
+library is unable to spawn a new thread or there are no free worker threads
+then the <tt>async</tt> call should fail. <i>--end note</i>]
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+The concurrency subgroup has revisited this issue and decided that it
+could be considered a defect according to the Kona compromise. A task
+group was formed lead by Lawrence Crowl and Bjarne Stroustrup to write a
+paper for Frankfort proposing a simple asynchronous launch facility
+returning a <tt>future</tt>. It was agreed that the callable must be run on a
+separate thread from the caller, but not necessarily a brand-new thread.
+The proposal might or might not allow for an implementation that uses
+fixed-size or unlimited thread pools.
+</p>
+<p>
+Bjarne in c++std-lib-23121: I think that what we agreed was that to
+avoid deadlock <tt>async()</tt> would almost certainly be specified to launch in
+a different thread from the thread that executed <tt>async()</tt>, but I don't
+think it was a specific design constraint.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1047"></a>1047. Response to UK 334</h3>
+<p><b>Section:</b> 30.6.4 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 334</b></p>
+
+<p>
+Behaviour of <tt>get()</tt> is undefined if calling <tt>get()</tt> while
+not <tt>is_ready()</tt>. The intent is that <tt>get()</tt> is a blocking
+call, and will wait for the future to become ready.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Agree, move to Review.
+</p>
+</blockquote>
+
+<p><i>[
+2009-04-03 Thomas J. Gritzan adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+This issue also applies to <tt>shared_future::get()</tt>.
+</p>
+
+<p>
+Suggested wording:
+</p>
+
+<p>
+Add a paragraph to [futures.shared_future]:
+</p>
+
+<blockquote><pre>void shared_future<void>::get() const;
+</pre>
+<blockquote>
+<i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>, block on the asynchronous
+result associated with <tt>*this</tt>.
+</blockquote>
+</blockquote>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+It is not clear to us that this is an issue,
+because the proposed resolution's Effects clause seems to duplicate
+information already present in the Synchronization clause.
+Keep in Review status.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a paragraph to 30.6.4 [futures.unique_future]:
+</p>
+
+<blockquote><pre>R&& unique_future::get();
+R& unique_future<R&>::get();
+void unique_future<void>::get();
+</pre>
+<blockquote>
+<p><i>Note:</i>...</p>
+<p>
+<ins><i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>,
+block on the asynchronous result associated with <tt>*this</tt>.</ins>
+</p>
+<p>
+<i>Synchronization:</i> if <tt>*this</tt> is associated with a
+<tt>promise</tt> object, the completion of <tt>set_value()</tt> or
+<tt>set_exception()</tt> to that <tt>promise</tt> happens before (1.10)
+<tt>get()</tt> returns.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1048"></a>1048. Response to UK 335</h3>
+<p><b>Section:</b> 30.6.4 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-13</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 335</b></p>
+
+<p>
+<tt>std::unique_future</tt> is <tt>MoveConstructible</tt>, so you can transfer the
+association with an asynchronous result from one instance to another.
+However, there is no way to determine whether or not an instance has
+been moved from, and therefore whether or not it is safe to wait for it.
+</p>
+
+<blockquote><pre>std::promise<int> p;
+std::unique_future<int> uf(p.get_future());
+std::unique_future<int> uf2(std::move(uf));
+uf.wait(); <font color="#c80000">// oops, uf has no result to wait for. </font>
+</pre></blockquote>
+
+<p>
+Suggest we add a <tt>waitable()</tt> function to <tt>unique_future</tt>
+(and <tt>shared_future</tt>) akin to <tt>std::thread::joinable()</tt>,
+which returns <tt>true</tt> if there is an associated result to wait for
+(whether or not it is ready).
+</p>
+
+<p>
+Then we can say:
+</p>
+
+<blockquote><pre>if(uf.waitable()) uf.wait();
+</pre></blockquote>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Create an issue. Requires input from Howard. Probably NAD.
+</p>
+</blockquote>
+
+<p><i>[
+Post Summit, Howard thows in his two cents:
+]</i></p>
+
+
+<blockquote>
+<p>
+Here is a copy/paste of my last prototype of <tt>unique_future</tt> which was
+several years ago. At that time I was calling <tt>unique_future</tt> <tt>future</tt>:
+</p>
+
+<blockquote><pre>template <class R>
+class future
+{
+public:
+ typedef R result_type;
+private:
+ future(const future&);// = delete;
+ future& operator=(const future&);// = delete;
+
+ template <class R1, class F1> friend class prommise;
+public:
+ future();
+ ~future();
+
+ future(future&& f);
+ future& operator=(future&& f);
+
+ void swap(future&& f);
+
+ <b>bool joinable() const;</b>
+ bool is_normal() const;
+ bool is_exceptional() const;
+ bool is_ready() const;
+
+ R get();
+
+ void join();
+ template <class ElapsedTime>
+ bool timed_join(const ElapsedTime&);
+};
+</pre></blockquote>
+
+<p>
+<tt>shared_future</tt> had a similar interface. I intentionally reused
+the <tt>thread</tt> interface where possible to lessen the learning
+curve std::lib clients will be faced with.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1049"></a>1049. Response to UK 339</h3>
+<p><b>Section:</b> 30.6.6 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 339</b></p>
+
+<p>
+Move assignment is goiing in the wrong direction, assigning from
+<tt>*this</tt> to the passed rvalue, and then returning a reference to
+an unusable <tt>*this</tt>.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Agree, move to Review.
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We recommend deferring this issue until after Detlef's paper (on futures)
+has been issued.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Strike 30.6.6 [futures.promise] p6 and change p7:
+</p>
+
+<blockquote><pre>promise& operator=(promise&& rhs);
+</pre>
+<blockquote>
+<p>
+<del>-6- <i>Effects:</i> move assigns its associated state to <tt>rhs</tt>.</del>
+</p>
+<p>
+-7- <i>Postcondition:</i> <del><tt>*this</tt> has no associated
+state.</del> <ins>associated state of <tt>*this</tt> is the same as the
+associated state of <tt>rhs</tt> before the call. <tt>rhs</tt> has no
+associated state.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1050"></a>1050. Response to UK 340</h3>
+<p><b>Section:</b> 30.6.6 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 340</b></p>
+
+<p>
+There is an implied postcondition for <tt>get_future()</tt> that the state of the
+<tt>promise</tt> is transferred into the <tt>future</tt> leaving the <tt>promise</tt> with no
+associated state. It should be spelled out.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Agree, move to Review.
+</p>
+</blockquote>
+
+<p><i>[
+2009-04-03 Thomas J. Gritzan adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+<tt>promise::get_future()</tt> must not invalidate the state of the promise object.
+</p>
+<p>
+A promise is used like this:
+</p>
+<blockquote><pre>promise<int> p;
+unique_future<int> f = p.get_future();
+<font color="#c80000">// post 'p' to a thread that calculates a value </font>
+<font color="#c80000">// use 'f' to retrieve the value. </font>
+</pre></blockquote>
+<p>
+So <tt>get_future()</tt> must return an object that shares the same associated
+state with <tt>*this</tt>.
+</p>
+<p>
+But still, this function should throw an <tt>future_already_retrieved</tt> error
+when it is called twice.
+</p>
+<p>
+<tt>packaged_task::get_future()</tt> throws <tt>std::bad_function_call</tt> if its <tt>future</tt>
+was already retrieved. It should throw
+<tt>future_error(future_already_retrieved)</tt>, too.
+</p>
+<p>
+Suggested resolution:
+</p>
+<p>
+Replace p12/p13 30.6.6 [futures.promise]:
+</p>
+<blockquote>
+<p>
+-12- <i>Throws:</i> <tt>future_error</tt> if <del><tt>*this</tt> has no associated state</del>
+<ins>the <tt>future</tt> has already been retrieved</ins>.
+</p>
+<p>
+-13- <i>Error conditions:</i> <tt>future_already_retrieved</tt> if <del><tt>*this</tt>
+has no associated state</del>
+<ins>the <tt>future</tt> associated with
+the associated state has already been retrieved</ins>.
+</p>
+<p>
+<ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated state.</ins>
+</p>
+</blockquote>
+<p>
+Replace p14 30.6.8 [futures.task]:
+</p>
+<blockquote>
+<p>
+-14- <i>Throws:</i> <tt><del>std::bad_function_call</del> <ins>future_error</ins></tt> if the future <del>associated with
+the task</del> has already been retrieved.
+</p>
+
+<p><ins>
+<i>Error conditions:</i> <tt>future_already_retrieved</tt> if the <tt>future</tt> associated with
+the task has already been retrieved.
+</ins></p>
+<p>
+<ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated task.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Keep in Review status
+pending Detlef's forthcoming paper on futures.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add after p13 30.6.6 [futures.promise]:
+</p>
+
+<blockquote><pre>unique_future<R> get_future();
+</pre>
+<blockquote>
+<p>
+-13- ...
+</p>
+<p>
+<i>Postcondition:</i> <tt>*this</tt> has no associated state.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1051"></a>1051. Response to UK 279</h3>
+<p><b>Section:</b> 24.5.1.2.12 [reverse.iter.opindex], 24.5.3.2.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-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><b>Addresses UK 279</b></p>
+
+<p>
+The reason the return type became unspecified is LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>. This
+reasoning no longer applies as there are at least two ways to get the right
+return type with the new language facilities added since the previous
+standard.
+</p>
+
+<p>
+Proposal: Specify the return type using either decltype or the Iter concept_map.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+Under discussion. This is a general question about all iterator
+adapters.
+</p>
+</blockquote>
+
+<p><i>[
+Howard adds post Summit:
+]</i></p>
+
+
+<blockquote>
+I am requesting test cases to demonstrate a position.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1052"></a>1052. Response to UK 281</h3>
+<p><b>Section:</b> 24.5.1.2.5 [reverse.iter.opref] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-13</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 281</b></p>
+
+<p>
+The current specification for return value for <tt>reverse_iterator::operator-></tt>
+will always be a true pointer type, but <tt>reverse_iterator</tt> supports proxy
+iterators where the pointer type may be some kind of 'smart pointer'.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+<tt>move_iterator</tt> avoids this problem by returning a value of the wrapped
+Iterator type.
+study group formed to come up with a suggested resolution.
+</p>
+<p>
+<tt>move_iterator</tt> solution shown in proposed wording.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change synopsis in 24.5.1.1 [reverse.iterator]:
+</p>
+
+<blockquote><pre>template <BidirectionalIterator Iter>
+class reverse_iterator {
+ ...
+ typedef Iter<del>::pointer</del> pointer;
+</pre></blockquote>
+
+<p>
+Change 24.5.1.2.5 [reverse.iter.opref]:
+</p>
+
+<blockquote><pre>pointer operator->() const;
+</pre>
+<blockquote>
+<i>Returns:</i>
+<blockquote><pre><del>&(operator*());</del>
+<ins>this->tmp = current;</ins>
+<ins>--this->tmp;</ins>
+<ins>return this->tmp;</ins>
+</pre></blockquote>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1053"></a>1053. Response to UK 295</h3>
+<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-13</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 295</b></p>
+
+<p>
+There is a level of redundancy in the library specification for many
+algorithms that can be eliminated with the combination of concepts and
+default parameters for function templates. Eliminating redundancy simplified
+specification and reduces the risk of introducing accidental
+inconsistencies.
+</p>
+<p>
+Proposed resolution: Adopt
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2743.pdf">N2743</a>.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+
+<blockquote>
+<p>
+NAD, this change would break code that takes the address of an
+algorithm.
+</p>
+</blockquote>
+
+<p><i>[
+Post Summit Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Request 'Open'. The issues in the paper go beyond just reducing
+the number of signatures, but cover unifying the idea of the ordering
+operation used by algorithms, containers and other library components. At
+least, it takes a first pass at the problem.
+</p>
+
+<p>
+For me (personally) that was the more important part of the paper, and not
+clearly addressed by the Summit resolution.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1054"></a>1054. <tt>forward</tt> broken</h3>
+<p><b>Section:</b> 20.3.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</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#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+This is a placeholder issue to track the fact that we (well I) put the standard
+into an inconsistent state by requesting that we accept
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
+except for the proposed changes to [forward].
+</p>
+
+<p>
+There will exist in the post meeting mailing
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2835.html">N2835</a>
+which in its current state reflects the state of affairs prior to the Summit
+meeting. I hope to update it in time for the post Summit mailing, but as I write
+this issue I have not done so yet.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open, awaiting the promised paper.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1055"></a>1055. Response to UK 98</h3>
+<p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 98</b></p>
+
+<p>
+It would be useful to be able to determine the underlying
+type of an arbitrary enumeration type. This would allow
+safe casting to an integral type (especially needed for
+scoped enums, which do not promote), and would allow
+use of <tt>numeric_limits</tt>. In general it makes generic
+programming with enumerations easier.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Pete observes (and Tom concurs)
+that the proposed resolution seems to require compiler support
+for its implementation,
+as it seems necessary to look at the range of values
+of the enumerated type.
+To a first approximation,
+a library solution could give an answer based on the size of the type.
+If the user has specialized <tt>numeric_limits</tt> for the enumerated type,
+then the library might be able to do better,
+but there is no such requirement.
+Keep status as Open
+and solicit input from CWG.
+</blockquote>
+
+<p><i>[
+2009-05-23 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+Just to confirm that the BSI originator of this comment assumed it did
+indeed imply a compiler intrinsic. Rather than request a Core extension, it
+seemed in keeping with that the type traits interface provides a library API
+to unspecified compiler features - where we require several other traits
+(e.g. <tt>has_trivial_*</tt>) to get the 'right' answer now, unlike in TR1.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a new row to the table in 20.6.7 [meta.trans.other]:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 41 -- Other transformations</caption>
+<tbody><tr>
+<th>Template</th>
+<th>Condition</th>
+<th>Comments</th>
+</tr>
+<tr>
+<td>
+<tt>template< class T > struct enum_base;</tt>
+</td>
+<td>
+<tt>T</tt> shall be an enumeration type (7.2 [dcl.enum])
+</td>
+<td>
+The member typedef <tt>type</tt> shall name the underlying type
+of the enum <tt>T</tt>.
+</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1056"></a>1056. Must all Engines and Distributions be Streamable?</h3>
+<p><b>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-31</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</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#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+Both the concepts <tt>RandomNumberEngine</tt> and <tt>RandomNumberDistribution</tt> have
+requirements to be <tt>InputStreamable</tt> and <tt>OutputStreamable</tt>.
+</p>
+<p>
+I have no problems leaving the WP in an inconsistent state on the best-faith
+assumption these concepts will be provided later, however disagree with the
+proposers that these constraints are not separable, orthogonal to the basic
+concepts of generating random number distributions.
+</p>
+<p>
+These constraints should be dropped, and applied to specific algorithms as
+needed.
+</p>
+<p>
+If a more refined concept (certainly deemed useful by the proposers) is
+proposed there is no objection, but the basic concept should not require
+persistence via streaming.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open.
+</blockquote>
+
+<p><i>[
+2009-05-31 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Working on constraining the stream iterators, I have a few more observations
+to make on the concepts proposed while constraining the random number
+facility.
+</p>
+<p>
+While I still believe the concerns are orthogonal, I don't believe the
+existing constraints go far enough either! The goal we want to achieve is
+not that a <tt>RandomNumberEngine</tt> / <tt>RandomNumberDistribution</tt> supports the stream
+operators, but that it is <tt>Serializable</tt>. I.e. there is a relationship
+between the insert and extract operations that guarantees to restore the
+state of the original object. This implies a coupling of the concepts
+together in a broader concept (<tt>Serializable</tt>) with at least one axiom to
+assert the semantics.
+</p>
+<p>
+One problem is that <tt>istream</tt> and <tt>ostream</tt> may be fundamentally different
+types, although we can hook a relation if we are prepared to drop down to
+the <tt>char</tt> type and <tt>char_traits</tt> template parameters. Doing so ties us to a
+form of serialization that demands implementation via the std iostreams
+framework, which seems overly prescriptive. I believe the goal is generally
+to support serialization without regard to how it is expressed - although
+this is getting even more inventive in terms of concepts we do not have
+today.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1057"></a>1057. <tt>RandomNumberEngineAdaptor</tt></h3>
+<p><b>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</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#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+The <tt>RandomNumberEngineAdaptor</tt> concept breaks precedent in the
+way the library has been specified by grouping requirements into a
+concept that is never actually used in the library.
+</p>
+<p>
+This is undoubtedly a very helpful device for documentation, but we are not
+comfortable with the precedent - especially as we have rejected national
+body comments on the same grounds.
+</p>
+<p>
+Suggest either removing the concept, or providing an algorithm/type that
+requires this concept in their definition (such as a factory function to
+create new engines).
+</p>
+<p>
+The preference is to create a single new algorithm and retain the value of
+the existing documentation.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Walter points out that it is unlikely that any algorithm would ever
+require this concept, but that the concept nonetheless is useful as
+documentation, and (via concept maps) as a means of checking specific adapters.
+</p>
+<p>
+Alisdair disagrees as to the concept's value as documentation.
+</p>
+<p>
+Marc points out that the <tt>RandomNumberDistribution</tt>
+is also a concept not used elsewhere in the Standard.
+</p>
+<p>
+Pete agrees that a policy of not inventing concepts
+that aren't used in the Standard is a good starting point,
+but should not be used as a criterion for rejecting a concept.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1058"></a>1058. New container issue</h3>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+Sequence containers 23.2.3 [sequence.reqmts]:
+</p>
+
+<p>
+The return value of new calls added to table 83 are not specified.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the proposed resolution.
+</p>
+<p>
+Move to NAD Editorial.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add after p6 23.2.3 [sequence.reqmts]:
+</p>
+
+<blockquote>
+<p>
+-6- ...
+</p>
+<p><ins>
+The iterator returned from <tt>a.insert(p,rv)</tt> points to the copy of <tt>rv</tt>
+inserted into <tt>a</tt>.
+</ins></p>
+<p><ins>
+The iterator returned from <tt>a.emplace(p, args)</tt> points to the new
+element constructed from <tt>args</tt> inserted into <tt>a</tt>.
+</ins></p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1059"></a>1059. Usage of no longer existing FunctionType concept</h3>
+<p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Due to a deliberate core language decision, the earlier called
+"foundation" concept <tt>std::FunctionType</tt> had been removed in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2773.pdf">N2773</a>
+shortly
+before the first "conceptualized" version of the WP
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>)
+had been
+prepared. This caused a break of the library, which already used this
+concept in the adapted definition of <tt>std::function</tt>
+(20.7 [function.objects]/2, header <tt><functional></tt> synopsis and
+20.7.16.2 [func.wrap.func]).
+</p>
+<p>
+A simple fix would be to either (a) make <tt>std::function</tt>'s primary template
+unconstrained or to (b) add constraints based on existing (support) concepts.
+A more advanced fix would (c) introduce a new library concept.
+</p>
+<p>
+The big disadvantage of (a) is, that users can define templates which
+cause compiler errors during instantiation time because of under-constrainedness
+and would thus violate the basic advantage of constrained
+code.
+</p>
+<p>
+For (b), the ideal constraints for <tt>std::function</tt>'s template parameter would
+be one which excludes everything else but the single provided partial
+specialization that matches every "free function" type (i.e. any function
+type w/o cv-qualifier-seq and w/o ref-qualifier).
+Expressing such a type as as single requirement would be written as
+</p>
+<blockquote><pre>template<typename T>
+requires ReferentType<T> // Eliminate cv void and function types with cv-qual-seq
+ // or ref-qual (depending on core issue #749)
+ && PointeeType<T> // Eliminate reference types
+ && !ObjectType<T> // Eliminate object types
+</pre></blockquote>
+<p>
+Just for completeness approach (c), which would make sense, if the
+library has more reasons to constrain for free function types:
+</p>
+<blockquote><pre>auto concept FreeFunctionType<typename T>
+ : ReferentType<T>, PointeeType<T>, MemberPointeeType<T>
+{
+ requires !ObjectType<T>;
+}
+</pre></blockquote>
+<p>
+I mention that approach because I expect that free function types belong
+to the most natural type categories for every days coders. Potential
+candidates in the library are <tt>addressof</tt> and class template <tt>packaged_task</tt>.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Alisdair would prefer to have a core-supported <tt>FunctionType</tt> concept
+in order that any future changes be automatically correct
+without need for a library solution to catch up;
+he points to type traits as a precedent.
+Further, he believes that a published concept can't in the future
+be changed.
+</p>
+<p>
+Bill feels this category of entity would change sufficiently slowly
+that he would be willing to take the risk.
+</p>
+<p>
+Of the discussed solutions, we tend toward option (c).
+We like the idea of having a complete taxonomy of native types,
+and perhaps erred in trimming the set.
+</p>
+<p>
+We would like to have this issue reviewed by Core and would like
+their feedback. Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+Change in 20.7 [function.objects]/2, Header <tt><functional></tt> synopsis:
+</p>
+<blockquote><pre>// 20.6.16 polymorphic function wrappers:
+class bad_function_call;
+template<<del>FunctionType</del><ins>ReferentType F</ins>>
+<ins>requires PointeeType<F> && !ObjectType<F></ins>
+class function; // undefined
+</pre></blockquote>
+</li>
+<li>
+<p>
+Change in 20.7.16.2 [func.wrap.func]:
+</p>
+<blockquote><pre>namespace std {
+template<<del>FunctionType</del><ins>ReferentType F</ins>>
+<ins>requires PointeeType<F> && !ObjectType<F></ins>
+class function; // undefined
+</pre></blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="1060"></a>1060. Embedded nulls in NTBS</h3>
+<p><b>Section:</b> 17.5.2.1.4.1 [byte.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+Definition of null-terminated sequences allow for embedded nulls. This is
+surprising, and probably not supportable with the intended use cases.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the issue, but believe this can be handled editorially.
+Move to NAD Editorial.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1061"></a>1061. Bad indexing for tuple access to pair (Editorial?)</h3>
+<p><b>Section:</b> 20.3.4 [pair.astuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+The definition of <tt>get</tt> implies that <tt>get</tt> must return the second element if
+given a negative integer.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to NAD Editorial.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+20.3.4 [pair.astuple] p5:
+</p>
+
+<blockquote><pre>template<<del>int</del> <ins>size_t</ins> I, class T1, class T2>
+ requires True<(I < 2)>
+ const P& get(const pair<T1, T2>&);
+</pre>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1062"></a>1062. Missing insert_iterator for stacks/queues</h3>
+<p><b>Section:</b> 24.7 [insert.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#insert.iterators">active issues</a> in [insert.iterators].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.iterators].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+It is odd that we have an iterator to insert into a <tt>vector</tt>, but not an
+iterator to insert into a <tt>vector</tt> that is adapted as a <tt>stack</tt>. The standard
+container adapters all have a common interface to <tt>push</tt> and <tt>pop</tt> so it should
+be simple to create an iterator adapter to complete the library support.
+</p>
+
+<p>
+We should provide an <tt>AdaptedContainer</tt> concept supporting <tt>push</tt> and <tt>pop</tt>
+operations. Create a new insert iterator and factory function that inserts
+values into the container by calling <tt>push</tt>.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Walter recommends NAD Future.
+</p>
+<p>
+Move to Open, and recommend deferring the issue until after the next
+Committee Draft is issued.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1063"></a>1063. 03 iterator compatibilty</h3>
+<p><b>Section:</b> D.10.4 [iterator.backward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+Which header must a user <tt>#include</tt> to obtain the library-supplied
+<tt>concept_maps</tt> declared in this paragraph?
+</p>
+
+<p>
+This is important information, as existing user code will break if this
+header is not included, and we should make a point of mandating this header
+is <tt>#include</tt>-d by library headers likely to make use of it, notably
+<tt><algorithm></tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a> for more details.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the direction of the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p><i>Change D.10 [depr.lib.iterator.primitives], Iterator primitives, as
+indicated:</i></p>
+
+<blockquote>
+ <p>To simplify the use of iterators and provide backward compatibility with
+ previous C++ Standard Libraries,
+ the library provides several classes and functions. <ins>Unless otherwise
+ specified, these classes and functions shall be defined in header <tt><iterator></tt>.</ins></p>
+</blockquote>
+<p><i>Change D.10.4 [iterator.backward], Iterator backward compatibility, as
+indicated:</i></p>
+<blockquote>
+ <p>The library provides concept maps that allow iterators specified with
+ <tt>iterator_traits</tt> to interoperate with
+ algorithms that require iterator concepts. <ins>These concept maps shall be
+ defined in the same header that defines the iterator.</ins> [<i>Example:</i></p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1064"></a>1064. Response to UK 152</h3>
+<p><b>Section:</b> 17.3.15 [defns.obj.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2009-03-15</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 152</b></p>
+
+<p>
+Object state is using a definition of object (instance of a class) from
+outside the standard, rather than the 'region of storage' definiton in
+1.8 [intro.object]p1
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+We think we're removing this; See 20.7.18.1 [func.referenceclosure.cons].
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1065"></a>1065. Response to UK 168</h3>
+<p><b>Section:</b> 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#contents">active issues</a> in [contents].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#contents">issues</a> in [contents].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses UK 168</b></p>
+<p>
+We should make it clear (either by note or normatively) that namespace
+<tt>std</tt> may contain inline namespaces, and that entities specified to be
+defined in std may in fact be defined in one of these inline namespaces.
+(If we're going to use them for versioning, eg when TR2 comes along,
+we're going to need that.)
+</p>
+
+<p>
+Replace "namespace std or namespaces nested within namespace std" with
+"namespace std or namespaces nested within namespace std or inline
+namespaces nested directly or indirectly within namespace std"
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+adopt UK words (some have reservations whether it is correct)
+</blockquote>
+
+<p><i>[
+2009-05-09 Alisdair improves the wording.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Bill believes there is strictly speaking no need to say that
+because no portable test can detect the difference.
+However he agrees that it doesn't hurt to say this.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 17.6.1.1 [contents] p2:
+</p>
+
+<blockquote>
+All library entities except macros, <tt>operator new</tt> and
+<tt>operator delete</tt> are defined within the namespace <tt>std</tt> or
+namespaces nested within namespace <tt>std</tt>.
+<ins>It is unspecified whether names declared in a specific namespace
+are declared directly in that namespace, or in an inline namespace inside
+that namespace. [<i>Footnote:</i> This gives implementers freedom to support
+multiple configurations of the library.]</ins>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1066"></a>1066. Response to UK 189 and JP 27</h3>
+<p><b>Section:</b> 18 [language.support] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses UK 189 and JP 27</b></p>
+<p>
+The addition of the <tt>[[noreturn]]</tt> attribute to the language will be an
+important aid for static analysis tools.
+</p>
+
+<p>
+The following functions should be declared in C++ with the
+<tt>[[noreturn]]</tt> attribute: <tt>abort</tt> <tt>exit</tt>
+<tt>quick_exit</tt> <tt>terminate</tt> <tt>unexpected</tt>
+<tt>rethrow_exception</tt> <tt>throw_with_nested</tt>.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+Agreed.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 18.5 [support.start.term] p3:
+</p>
+
+<blockquote>
+<p>-2- ...</p>
+<pre><ins>void</ins> abort <ins>[[noreturn]]</ins> (void)
+</pre>
+<p>-3- ...</p>
+<p>-6- ...</p>
+<pre><ins>void</ins> exit<ins> [[noreturn]] </ins>(int status)
+</pre>
+<p>-7- ...</p>
+<p>-11- ...</p>
+<pre>void quick_exit<ins> [[noreturn]] </ins>(int status)
+</pre>
+<p>-12- ...</p>
+</blockquote>
+
+<p>
+Change the <tt><exception></tt> synopsis in 18.8 [support.exception]:
+</p>
+
+<blockquote><pre>void unexpected<ins> [[noreturn]] </ins>();
+...
+void terminate<ins> [[noreturn]] </ins>();
+...
+void rethrow_exception<ins> [[noreturn]] </ins>(exception_ptr p);
+...
+template <class T> void throw_with_nested<ins> [[noreturn]] </ins>(T&& t); <del>// [[noreturn]]</del>
+</pre></blockquote>
+
+<p>
+Change 18.8.2.4 [unexpected]:
+</p>
+
+<blockquote><pre>void unexpected<ins> [[noreturn]] </ins>();
+</pre></blockquote>
+
+<p>
+Change 18.8.3.3 [terminate]:
+</p>
+
+<blockquote><pre>void terminate<ins> [[noreturn]] </ins>();
+</pre></blockquote>
+
+<p>
+Change 18.8.5 [propagation]:
+</p>
+
+<blockquote><pre>void rethrow_exception<ins> [[noreturn]] </ins>(exception_ptr p);
+</pre></blockquote>
+
+<p>
+In the synopsis of 18.8.6 [except.nested] and the definition area change:
+</p>
+
+<blockquote><pre>template <class T> void throw_with_nested<ins> [[noreturn]] </ins>(T&& t); <del>// [[noreturn]]</del>
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1067"></a>1067. simplified wording for inner_product</h3>
+<p><b>Section:</b> 26.7 [numeric.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-17 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+One of the motivating examples for introducing requirements-aliases was to
+simplify the wording of the <tt>inner_product</tt> requirements. As the paper
+adopting the feature and constrained wording for the library went through in
+the same meeting, it was not possible to make the change at the time. The
+simpler form should be adopted now though. Similarly, most the other
+numerical algorithms can benefit from a minor cleanup.
+</p>
+<p>
+Note that in each case, the second more generalised form of the algorithm
+does not benefit, as there are already named constraints supplied by the
+template type parameters.
+</p>
+
+<p><i>[
+2009-05-02 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+one part of the suggested resolution suggests the removal of the
+<tt>MoveConstructible<T></tt> requirement from
+<tt>inner_product</tt>. According to 26.7.2 [inner.product]
+</p>
+
+<blockquote>
+Computes its result by initializing the accumulator <tt>acc</tt> with the
+initial value <tt>init</tt>
+</blockquote>
+
+<p>
+this step requires at least <tt>MoveConstructible</tt>.
+</p>
+
+<p>
+Therefore I strongly suggest to take this removal back (Note also
+that the corresponding overload with a functor argument still has
+the same <tt>MoveConstructible<T></tt> requirement).
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the proposed resolution as amended by Daniel's suggestion
+to restore <tt>MoveConstructible</tt>,
+reflected in the updated proposed resolution below.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change in 26.7 [numeric.ops] and [accumulate]:
+</p>
+
+<blockquote><pre>template <InputIterator Iter, MoveConstructible T>
+ requires <ins>add =</ins> HasPlus<T, Iter::reference>
+ && HasAssign<T, <del>HasPlus<T, Iter::reference></del> <ins>add</ins>::result_type>
+ T accumulate(Iter first, Iter last, T init);
+</pre></blockquote>
+
+<p>
+Change in 26.7 [numeric.ops] and 26.7.2 [inner.product]:
+</p>
+
+<blockquote><pre>template <InputIterator Iter1, InputIterator Iter2, MoveConstructible T>
+ requires <ins>mult =</ins> HasMultiply<Iter1::reference, Iter2::reference>
+ && <ins>add =</ins> HasPlus<T, <del>HasMultiply<Iter1::reference, Iter2::reference></del> <ins>mult</ins>::result_type>
+ && HasAssign<
+ T,
+ <del>HasPlus<T,
+ HasMultiply<Iter1::reference, Iter2::reference>::result_type></del> <ins>add</ins>::result_type>
+ T inner_product(Iter1 first1, Iter1 last1, Iter2 first2, T init);
+</pre></blockquote>
+
+<p>
+Change in 26.7 [numeric.ops] and 26.7.3 [partial.sum]:
+</p>
+
+<blockquote><pre>template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter>
+ requires <ins>add =</ins> HasPlus<InIter::value_type, InIter::reference>
+ && HasAssign<InIter::value_type,
+ <del>HasPlus<InIter::value_type, InIter::reference></del> <ins>add</ins>::result_type>
+ && Constructible<InIter::value_type, InIter::reference>
+ OutIter partial_sum(InIter first, InIter last, OutIter result);
+</pre></blockquote>
+
+<p>
+Change in 26.7 [numeric.ops] and 26.7.4 [adjacent.difference]:
+</p>
+
+<blockquote><pre>template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter>
+ requires <ins>sub =</ins> HasMinus<InIter::value_type, InIter::value_type>
+ && Constructible<InIter::value_type, InIter::reference>
+ && OutputIterator<OutIter, <del>HasMinus<InIter::value_type, InIter::value_type></del> <ins>sub</ins>::result_type>
+ && MoveAssignable<InIter::value_type>
+ OutIter adjacent_difference(InIter first, InIter last, OutIter result);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1068"></a>1068. class random_device should be movable</h3>
+<p><b>Section:</b> 26.5.6 [rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-18 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.device">issues</a> in [rand.device].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+class <tt>random_device</tt> should be movable.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open, and recommend this issue be deferred until after the next
+Committee Draft is issued.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1069"></a>1069. class seed_seq should support efficient move operations</h3>
+<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-18 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+class <tt>seed_seq</tt> should support efficient move operations.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open, and recommend this issue be deferred until after the next
+Committee Draft is issued.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1070"></a>1070. Ambiguous move overloads in function</h3>
+<p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The synopsis in 20.7.16.2 [func.wrap.func] says:
+</p>
+
+<blockquote><pre>template<Returnable R, CopyConstructible... ArgTypes>
+class function<R(ArgTypes...)>
+{
+ ...
+ template<class F>
+ requires CopyConstructible<F> && Callable<F, ArgTypes...>
+ && Convertible<Callable<F, ArgTypes...>::result_type, R>
+ function(F);
+ template<class F>
+ requires CopyConstructible<F> && Callable<F, ArgTypes...>
+ && Convertible<Callable<F, ArgTypes...>::result_type, R>
+ function(F&&);
+ ...
+ template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F);
+ template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F&&);
+ ...
+ template<class F>
+ requires CopyConstructible<F> && Callable<F, ArgTypes..>
+ && Convertible<Callable<F, ArgTypes...>::result_type
+ function& operator=(F);
+ template<class F>
+ requires CopyConstructible<F> && Callable<F, ArgTypes...>
+ && Convertible<Callable<F, ArgTypes...>::result_type, R>
+ function& operator=(F&&);
+ ...
+};
+</pre></blockquote>
+
+<p>
+Each of the 3 pairs above are ambiguous. We need only one of each pair, and we
+could do it with either one. If we choose the <tt>F&&</tt> version we
+need to bring <tt>decay</tt> into the definition to get the pass-by-value behavior.
+In the proposed wording I've gotten lazy and just used the pass-by-value signature.
+</p>
+
+<p><i>[
+2009-05-01 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a> modifies the second removed constructor.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We briefly discussed whether we ought support moveable function objects,
+but decided that should be a separate issue if someone cares to propose it.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis of 20.7.16.2 [func.wrap.func], and remove the associated definitions in
+20.7.16.2.1 [func.wrap.func.con]:
+</p>
+
+<blockquote><pre>template<Returnable R, CopyConstructible... ArgTypes>
+class function<R(ArgTypes...)>
+{
+ ...
+ template<class F>
+ requires CopyConstructible<F> && Callable<F, ArgTypes...>
+ && Convertible<Callable<F, ArgTypes...>::result_type, R>
+ function(F);
+ <del>template<class F>
+ requires CopyConstructible<F> && Callable<F, ArgTypes...>
+ && Convertible<Callable<F, ArgTypes...>::result_type, R>
+ function(F&&);</del>
+ ...
+ template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F);
+ <del>template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F&&);</del>
+ ...
+ template<class F>
+ requires CopyConstructible<F> && Callable<F, ArgTypes..>
+ && Convertible<Callable<F, ArgTypes...>::result_type
+ function& operator=(F);
+ <del>template<class F>
+ requires CopyConstructible<F> && Callable<F, ArgTypes...>
+ && Convertible<Callable<F, ArgTypes...>::result_type, R>
+ function& operator=(F&&);</del>
+ ...
+};
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1071"></a>1071. is_bind_expression should derive from integral_constant<bool></h3>
+<p><b>Section:</b> 20.7.12.1.1 [func.bind.isbind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-31</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+Class template is_bind_expression 20.7.12.1.1 [func.bind.isbind]:
+</p>
+
+<blockquote><pre>namespace std {
+ template<class T> struct is_bind_expression {
+ static const bool value = see below;
+ };
+}
+</pre></blockquote>
+<p>
+<tt>is_bind_expression</tt> should derive from <tt>std::integral_constant<bool></tt> like
+other similar trait types.
+</p>
+
+<p><i>[
+Daniel adds:
+]</i></p>
+
+<blockquote>
+We need the same thing for the trait <tt>is_placeholder</tt> as well.
+</blockquote>
+<p><i>[
+2009-03-22 Daniel provided wording.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We recommend this be deferred until after the next Committee Draft is issued.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+<p><i>[
+2009-05-31 Peter adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I am opposed to the proposed resolution and to the premise of the issue
+in general. The traits's default definitions should NOT derive from
+<tt>integral_constant</tt>, because this is harmful, as it misleads people into
+thinking that <tt>is_bind_expression<E></tt> always derives from
+<tt>integral_constant</tt>, whereas it may not.
+</p>
+<p>
+<tt>is_bind_expression</tt> and <tt>is_placeholder</tt> allow user
+specializations, and in fact, this is their primary purpose. Such user
+specializations may not derive from <tt>integral_constant</tt>, and the
+places where <tt>is_bind_expression</tt> and <tt>is_placeholder</tt> are
+used intentionally do not require such derivation.
+</p>
+<p>
+The long-term approach here is to switch to
+<tt>BindExpression<E></tt> and <tt>Placeholder<P></tt>
+explicit concepts, of course, but until that happens, I say leave them
+alone.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+In 20.7.12.1.1 [func.bind.isbind] change as indicated:
+</p>
+<blockquote><pre>namespace std {
+ template<class T> struct is_bind_expression <ins>: integral_constant<bool, <i>see below</i>> { };</ins><del>{
+ static const bool value = <i>see below</i>;
+ };</del>
+}
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 20.7.12.1.1 [func.bind.isbind]/2 change as indicated:
+</p>
+<blockquote><pre><del>static const bool value;</del>
+</pre>
+<blockquote>
+-2- <del><tt>true</tt> if <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>false</tt> otherwise.</del>
+ <ins>If <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>is_bind_expression<T></tt> shall
+be publicly derived from
+ <tt>integral_constant<bool, true></tt>, otherwise it shall be
+publicly derived from
+ <tt>integral_constant<bool, false></tt>.</ins>
+</blockquote>
+</blockquote>
+</li>
+<li>
+<p>
+In 20.7.12.1.2 [func.bind.isplace] change as indicated:
+</p>
+<blockquote><pre>namespace std {
+ template<class T> struct is_placeholder <ins>: integral_constant<int, <i>see below</i>> { };</ins><del>{
+ static const int value = <i>see below</i>;
+ };</del>
+}
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 20.7.12.1.2 [func.bind.isplace]/2 change as indicated:
+</p>
+<blockquote><pre><del>static const int value;</del>
+</pre>
+<blockquote>
+-2- <del>value is <tt>J</tt> if <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, 0 otherwise.</del>
+ <ins>If <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, <tt>is_placeholder<T></tt>
+shall be publicly
+ derived from <tt>integral_constant<int, J></tt> otherwise it shall
+be publicly derived
+ from <tt>integral_constant<int, 0></tt>.</ins>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="1072"></a>1072. Is std::hash a constrained template or not?</h3>
+<p><b>Section:</b> 20.7.17 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+Is <tt>std::hash</tt> a constrained template or not?
+</p>
+<p>
+According to Class template hash 20.7.17 [unord.hash], the definition is:
+</p>
+
+<blockquote><pre>template <class T>
+struct hash : public std::unary_function<T, std::size_t> {
+ std::size_t operator()(T val) const;
+};
+</pre></blockquote>
+
+<p>
+And so unconstrained.
+</p>
+<p>
+According to the <tt><functional></tt> synopsis in p2 Function objects
+20.7 [function.objects] the template is declared as:
+</p>
+
+<blockquote><pre>template <ReferentType T> struct hash;
+</pre></blockquote>
+
+<p>
+which would make hash a constrained template.
+</p>
+
+<p><i>[
+2009-03-22 Daniel provided wording.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Alisdair is not certain that Daniel's proposed resolution is sufficient,
+and recommends we leave the hash template unconstrained for now.
+</p>
+<p>
+Recommend that the Project Editor make the constrained declaration consistent
+with the definition in order to make the Working Paper internally consistent,
+and that the issue then be revisited.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+[To the editor: This resolution is merge-compatible to the
+resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1078">1078</a>]
+</p>
+
+<ol>
+<li>
+<p>
+In 20.7 [function.objects]/2, header <tt><functional></tt> synopsis, change as indicated:
+</p>
+
+<blockquote><pre>// 20.6.17, hash function base template:
+template <ReferentType T> struct hash; <ins>// undefined</ins>
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 20.7.17 [unord.hash]/1 change as indicated:
+</p>
+<blockquote><pre>namespace std {
+ <del>template <class T>
+ struct hash : public std::unary_function<T, std::size_t> {
+ std::size_t operator()(T val) const;
+ };</del>
+ <ins>template <ReferentType T> struct hash; // undefined</ins>
+}
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 20.7.17 [unord.hash]/2 change as indicated:
+</p>
+
+<blockquote>
+-2- <ins>For all library-provided specializations, the template
+instantiation <tt>hash<T></tt>
+ shall provide a public <tt>operator()</tt> with return type <tt>std::size_t</tt> to
+satisfy the concept
+ requirement <tt>Callable<const hash<T>, const T&></tt>. If <tt>T</tt> is an object
+type or reference to
+ object, <tt>hash<T></tt> shall be publicly derived from
+<tt>std::unary_function<T, std::size_t></tt>.
+ </ins> The return value of <tt>operator()</tt> is unspecified, except that
+equal arguments
+ shall yield the same result. <tt>operator()</tt> shall not throw exceptions.
+</blockquote>
+</li>
+<li>
+<p>
+In 18.7 [support.rtti]/1, header <tt><typeinfo></tt> synopsis change as indicated:
+</p>
+<blockquote><pre>namespace std {
+ class type_info;
+ class type_index;
+ template <<del>class</del><ins>ReferentType</ins> T> struct hash;
+</pre></blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="1073"></a>1073. Declaration of <tt>allocator_arg</tt> should be <tt>constexpr</tt></h3>
+<p><b>Section:</b> 20.8 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#memory">active issues</a> in [memory].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#memory">issues</a> in [memory].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+Declaration of <tt>allocator_arg</tt> should be <tt>constexpr</tt> to ensure constant
+initialization.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution. Move to Tentatively Ready.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.8 [memory] p2:
+</p>
+
+<blockquote><pre>// 20.8.1, allocator argument tag
+struct allocator_arg_t { };
+const<ins>expr</ins> allocator_arg_t allocator_arg = allocator_arg_t();
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1074"></a>1074. concept map broken by N2840</h3>
+<p><b>Section:</b> 20.8.3 [allocator.element.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+p7 Allocator-related element concepts 20.8.3 [allocator.element.concepts]
+</p>
+
+<p>
+The changes to the <tt>AllocatableElement</tt> concept mean this <tt>concept_map</tt>
+specialization no longer matches the original concept:
+</p>
+
+<blockquote><pre>template <Allocator Alloc, class T, class ... Args>
+ requires HasConstructor<T, Args...>
+ concept_map AllocatableElement<Alloc, T, Args&&...> {
+ void construct_element(Alloc& a, T* t, Args&&... args) {
+ Alloc::rebind<T>(a).construct(t, forward(args)...);
+ }
+ }
+</pre></blockquote>
+
+<p><i>[
+2009-03-23 Pablo adds:
+]</i></p>
+
+
+<blockquote>
+Actually, this is incorrect,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
+says. "In section
+20.8.3 [allocator.element.concepts] paragraph 8, modify the definition of the
+<tt>AllocatableElement</tt> concept and eliminate the related concept map:" but
+then neglects to include the red-lined text of the concept map that was
+to be eliminated. Pete also missed this, but I caught it he asked me to
+review his edits. Pete's updated WP removes the concept map entirely,
+which was the original intent. The issue is, therefore, moot. Note, as
+per my presentation of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
+in summit, <tt>construct()</tt> no longer has a
+default implementation. This regrettable fact was deemed (by David
+Abrahams, Doug, and myself) to be preferable to the complexity of
+providing a default implementation that would not under-constrain a more
+restrictive allocator (like the scoped allocators).
+</blockquote>
+
+<p><i>[
+2009-05-01 Daniel adds:
+]</i></p>
+
+<blockquote>
+<p>
+it seems to me that #1074 should be resolved as a NAD, because the
+current WP has already removed the previous AllocatableElement concept map.
+It introduced auto concept AllocatableElement instead, but as of
+20.8.3 [allocator.element.concepts]/7 this guy contains now
+</p>
+<blockquote><pre>requires FreeStoreAllocatable<T>;
+void Alloc::construct(T*, Args&&...);
+</pre></blockquote>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+The affected code is no longer part of the Working Draft.
+</p>
+<p>
+Move to NAD.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.8.3 [allocator.element.concepts]:
+</p>
+
+<blockquote><pre>template <Allocator Alloc, class T, class ... Args>
+ requires HasConstructor<T, Args...>
+ concept_map AllocatableElement<Alloc, T, Args&&...> {
+ void construct_element(<del>Alloc& a,</del> T* t, Args&&... args) {
+ Alloc::rebind<T>(a).construct(t, forward(args)...);
+ }
+ }
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1075"></a>1075. Response to US 65, US 74.1</h3>
+<p><b>Section:</b> 20 [utilities], 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-06-10</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utilities">issues</a> in [utilities].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses US 65 and US 74.1</b></p>
+
+<p>US 65:</p>
+
+<blockquote>
+Scoped allocators and allocator propagation traits add a small amount of
+utility at the cost of a great deal of machinery. The machinery is user
+visible, and it extends to library components that don't have any
+obvious connection to allocators, including basic concepts and simple
+components like <tt>pair</tt> and <tt>tuple</tt>.
+
+<p>Suggested resolution:</p>
+
+<p>
+Sketch of proposed resolution: Eliminate scoped allocators, replace
+allocator propagation traits with a simple uniform rule (e.g. always
+propagate on copy and move), remove all mention of allocators from
+components that don't explicitly allocate memory (e.g. pair), and adjust
+container interfaces to reflect this simplification.
+</p>
+<p>
+Components that I propose eliminating include HasAllocatorType,
+is_scoped_allocator, allocator_propagation_map, scoped_allocator_adaptor,
+and ConstructibleAsElement.
+</p>
+</blockquote>
+
+<p>US 74.1:</p>
+
+<blockquote>
+<p>
+Scoped allocators represent a poor trade-off for standardization, since
+(1) scoped-allocator--aware containers can be implemented outside the
+C++ standard library but used with its algorithms, (2) scoped
+allocators only benefit a tiny proportion of the C++ community
+(since few C++ programmers even use today's allocators), and (3) all C++
+users, especially the vast majority of the C++ community that won't ever
+use scoped allocators are forced to cope with the interface complexity
+introduced by scoped allocators.
+</p>
+<p>
+In essence, the larger community will suffer to support a very small
+subset of the community who can already implement their own
+data structures outside of the standard library. Therefore, scoped
+allocators should be removed from the working paper.
+</p>
+<p>
+Some evidence of the complexity introduced by scoped allocators:
+</p>
+<blockquote>
+<p>
+20.3.3 [pairs], 20.5 [tuple]: Large increase in the
+number of pair and tuple constructors.
+</p>
+<p>
+23 [containers]: Confusing "AllocatableElement" requirements throughout.
+</p>
+</blockquote>
+<p>Suggested resolution:</p>
+
+<p>
+Remove support for scoped allocators from the working paper. This
+includes at least the following changes:
+</p>
+
+<blockquote>
+<p>
+Remove 20.8.3 [allocator.element.concepts]
+</p>
+<p>
+Remove 20.8.7 [allocator.adaptor]
+</p>
+<p>
+Remove 20.8.10 [construct.element]
+</p>
+<p>
+In Clause 23 [containers]: replace requirements naming the
+<tt>AllocatableElement</tt> concept with requirements naming <tt>CopyConstructible</tt>,
+<tt>MoveConstructible</tt>, <tt>DefaultConstructible</tt>, or <tt>Constructible</tt>, as
+appropriate.
+</p>
+</blockquote>
+
+</blockquote>
+
+<p><i>[
+Post Summit Alan moved from NAD to Open.
+]</i></p>
+
+
+<p><i>[
+2009-05-15 Ganesh adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+The requirement <tt>AllocatableElement</tt> should not be replaced with
+<tt>Constructible</tt> on the <tt>emplace_xxx()</tt> functions as suggested. In the
+one-parameter case the <tt>Constructible</tt> requirement is not satisfied when
+the constructor is explicit (as per 14.10.2.1 [concept.map.fct], twelfth
+bullet) but we do want to allow explicit constructors in emplace, as the
+following example shows:
+</p>
+
+<blockquote><pre>vector<shared_ptr<int>> v;
+v.emplace_back(new int); <font color="#c80000">// should be allowed</font>
+</pre></blockquote>
+
+<p>
+If the issue is accepted and scoped allocators are removed, I suggest to
+add a new pair of concepts to 20.2.7 [concept.construct], namely:
+</p>
+
+<blockquote><pre>auto concept HasExplicitConstructor<typename T, typename... Args> {
+ explicit T::T(Args...);
+}
+
+auto concept ExplicitConstructible<typename T, typename... Args>
+ : HasExplicitConstructor<T, Args...>, NothrowDestructible<T>
+{ }
+</pre></blockquote>
+
+<p>
+We should then use <tt>ExplicitConstructible</tt> as the requirement for all
+<tt>emplace_xxx()</tt> member functions.
+</p>
+<p>
+For coherence and consistency with the similar concepts
+<tt>Convertible/ExplicitlyConvertible</tt>, we might also consider changing
+<tt>Constructible</tt> to:
+</p>
+
+<blockquote><pre>auto concept Constructible<typename T, typename... Args>
+ : HasConstructor<T, Args...>, ExplicitConstructible<T, Args...>
+{ }
+</pre></blockquote>
+
+<p>
+Moreover, all emplace-related concepts in 23.2.6 [container.concepts]
+should also use <tt>ExplicitConstructible</tt> instead of <tt>Constructible</tt> in the
+definitions of their axioms. In fact the concepts in 23.2.6 [container.concepts] should be
+corrected even if the issue is not accepted.
+</p>
+<p>
+On the other hand, if the issue is not accepted, the scoped allocator
+adaptors should be fixed because the following code:
+</p>
+
+<blockquote><pre>template <typename T> using scoped_allocator = scoped_allocator_adaptor<allocator<T>>;
+
+vector<shared_ptr<int>, scoped_allocator<shared_ptr<int>>> v;
+v.emplace_back(new int); <font color="#c80000">// ops! doesn't compile</font>
+</pre></blockquote>
+
+<p>
+doesn't compile, as the member function <tt>construct()</tt> of the scoped
+allocator requires non-explicit constructors through concept
+<tt>ConstructibleWithAllocator</tt>. Fixing that is not difficult but probably
+more work than it's worth and is therefore, IMHO, one more reason in
+support of the complete removal of scoped allocators.
+</p>
+</blockquote>
+
+<p><i>[
+2009-06-09 Alan adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I reopened this issue because I did not think that these National Body
+comments were adequately addressed by marking them NAD. My understanding
+is that something can be marked NAD if it is clearly a misunderstanding
+or trivial, but a substantive issue that has any technical merit
+requires a disposition that addresses the concerns.
+</p>
+<p>
+The notes in the NB comment list (US 65 & US 74.1) say that:
+</p>
+<ol type="a">
+<li>
+this issue has not introduced any new arguments not previously discussed,
+</li>
+<li>
+the vote (4-9-3) was not a consensus for removing scoped allocators,
+</li>
+<li>
+the issue is resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>.
+</li>
+</ol>
+<p>
+My opinion is:
+</p>
+<ol type="a">
+<li>
+there are new arguments in both comments regarding concepts (which were
+not present in the library when the scoped allocator proposal was voted
+in),
+</li>
+<li>
+the vote was clearly not a consensus for removal, but just saying there
+was a vote does not provide a rationale,
+</li>
+<li>
+I do not believe that N2840 addresses these comments (although it does
+many other things and was voted in with strong approval).
+</li>
+</ol>
+
+<p>
+My motivation to open the issue was to ensure that the NB comments were
+adequately addressed in a way that would not risk a "no" vote on our
+FCD. If there are responses to the technical concerns raised, then
+perhaps they should be recorded. If the members of the NB who authored
+the comments are satisfied with N2840 and the other disposition remarks
+in the comment list, then I am sure they will say so. In either case,
+this issue can be closed very quickly in Frankfurt, and hopefully will
+have helped make us more confident of approval with little effort. If in
+fact there is controversy, my thought is that it is better to know now
+rather than later so there is more time to deal with it.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1076"></a>1076. unary/binary_negate need constraining and move support</h3>
+<p><b>Section:</b> 20.7.11 [negators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The class templates <tt>unary/binary_negate</tt> need constraining and move support.
+</p>
+<p>
+Ideally these classes would be deprecated, allowing <tt>unary/binary_function</tt> to
+also be deprecated. However, until a generic negate adaptor is introduced
+that can negate any <tt>Callable</tt> type, they must be supported so should be
+constrained. Likewise, they should be movable, and support adopting a
+move-only predicate type.
+</p>
+<p>
+In order to preserve ABI compatibility, new rvalue overloads are supplied in
+preference to changing the existing pass-by-const-ref to pass-by-value.
+</p>
+<p>
+Do not consider the issue of forwarding mutable lvalues at this point,
+although remain open to another issue on the topic.
+</p>
+
+<p><i>[
+2009-05-01 Daniel adds:
+]</i></p>
+
+<blockquote>
+<p>
+IMO the currently proposed resolution needs some updates
+because it is ill-formed at several places:
+</p>
+
+<ol>
+<li>
+<p>
+In concept AdaptableUnaryFunction change
+</p>
+<blockquote><pre>typename X::result_type;
+typename X::argument_type;
+</pre></blockquote>
+<p>
+to
+</p>
+<blockquote><pre>Returnable result_type = typename X::result_type;
+typename argument_type = typename X::argument_type;
+</pre></blockquote>
+<p>
+[The replacement "Returnable result_type" instead of "typename
+result_type" is non-editorial, but maybe you prefer that as well]
+</p>
+</li>
+<li>
+<p>
+In concept AdaptableBinaryFunction change
+</p>
+<blockquote><pre>typename X::result_type;
+typename X::first_argument_type;
+typename X::second_argument_type;
+</pre></blockquote>
+<p>
+to
+</p>
+<blockquote><pre>Returnable result_type = typename X::result_type;
+typename first_argument_type = typename X::first_argument_type;
+typename second_argument_type = typename X::second_argument_type;
+</pre></blockquote>
+<p>
+[The replacement "Returnable result_type" instead of "typename
+result_type" is non-editorial, but maybe you prefer that as well.]
+</p>
+</li>
+
+<li>
+<p>
+In class unary/binary_function
+</p>
+<ol type="a">
+<li>
+I suggest to change "ReturnType" to "Returnable" in both cases.
+</li>
+<li>
+I think you want to replace the remaining occurrences of "Predicate" by "P"
+(in both classes in copy/move from a predicate)
+</li>
+</ol>
+</li>
+<li>
+<p>
+I think you need to change the proposed signatures of not1 and not2, because
+they would still remain unconstrained: To make them constrained at least a
+single requirement needs to be added to enable requirement implication. This
+could be done via a dummy ("requires True<true>") or just explicit as follows:
+</p>
+<ol type="a">
+<li>
+<blockquote><pre>template <AdaptableUnaryFunction P>
+requires Predicate< P, P::argument_type>
+unary_negate<P> not1(const P&& pred);
+template <AdaptableUnaryFunction P>
+requires Predicate< P, P::argument_type >
+unary_negate<P> not1(P&& pred);
+</pre>
+<blockquote>
+-3- Returns: unary_negate<P>(pred).
+</blockquote>
+</blockquote>
+<p>
+[Don't we want a move call for the second overload as in
+</p>
+<blockquote><pre>unary_negate<P>(std::move(pred))
+</pre></blockquote>
+<p>
+in the Returns clause ?]
+</p>
+</li>
+<li>
+<pre>template <AdaptableBinaryFunction P>
+requires Predicate< P, P::first_argument_type, P::second_argument_type >
+binary_negate<P> not2(const P& pred);
+template <AdaptableBinaryFunction P>
+requires Predicate< P, P::first_argument_type, P::second_argument_type >
+binary_negate<P> not2(P&& pred);
+</pre>
+<p>
+-5- Returns: binary_negate<P>(pred).
+</p>
+<p>
+[Don't we want a move call for the second overload as in
+</p>
+<blockquote><pre>binary_negate<P>(std::move(pred))
+</pre></blockquote>
+<p>
+in the Returns clause ?]
+</p>
+</li>
+</ol>
+</li>
+</ol>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+There is concern that complicating the solution
+to preserve the ABI seems unnecessary,
+since we're not in general preserving the ABI.
+</p>
+<p>
+We would prefer a separate paper consolidating all Clause 20
+issues that are for the purpose of providing constrained versions
+of the existing facilities.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add new concepts where appropriate::
+</p>
+
+<blockquote><pre>auto concept AdaptableUnaryFunction< typename X > {
+ typename X::result_type;
+ typename X::argument_type;
+}
+
+auto concept AdaptableBinaryFunction< typename X > {
+ typename X::result_type;
+ typename X::first_argument_type;
+ typename X::second_argument_type;
+}
+</pre></blockquote>
+
+<p>
+Revise as follows:
+</p>
+
+<p>
+Base 20.7.3 [base] (Only change is constrained Result)
+</p>
+
+<blockquote>
+<p>
+-1- The following classes are provided to simplify the typedefs of the
+argument and result types:
+</p>
+<pre>namespace std {
+ template <class Arg, <del>class</del> <ins>ReturnType</ins> Result>
+ struct unary_function {
+ typedef Arg argument_type;
+ typedef Result result_type;
+ };
+
+ template <class Arg1, class Arg2, <del>class</del> <ins>ReturnType</ins> Result>
+ struct binary_function {
+ typedef Arg1 first_argument_type;
+ typedef Arg2 second_argument_type;
+ typedef Result result_type;
+ };
+}
+</pre></blockquote>
+
+<p>
+Negators 20.7.11 [negators]:
+</p>
+
+<blockquote>
+<p>
+-1- Negators <tt>not1</tt> and <tt>not2</tt> take a unary and a binary predicate,
+respectively, and return their complements (5.3.1).
+</p>
+
+<pre>template <<del>class</del> <ins>AdaptableUnaryFunction</ins> P<del>redicate</del>>
+ <ins>requires Predicate< P, P::argument_type ></ins>
+ class unary_negate
+ : public unary_function<<del>typename</del> P<del>redicate</del>::argument_type,bool> {
+ public:
+ <ins>unary_negate(const unary_negate & ) = default;</ins>
+ <ins>unary_negate(unary_negate && );</ins>
+
+ <ins>requires CopyConstructible< P ></ins>
+ explicit unary_negate(const Predicate& pred);
+ <ins>requires MoveConstructible< P >
+ explicit unary_negate(Predicate && pred);</ins>
+
+ bool operator()(const <del>typename</del> P<del>redicate</del>::argument_type& x) const;
+ };
+</pre>
+<blockquote>
+-2 <tt>operator()</tt> returns <tt>!pred(x)</tt>.
+</blockquote>
+
+<pre>template <class Predicate>
+ unary_negate<Predicate> not1(const Predicate&amp; pred);
+<ins>template <class Predicate>
+ unary_negate<Predicate> not1(Predicate&& pred);</ins>
+</pre>
+<blockquote>
+-3- <i>Returns:</i> <tt>unary_negate<Predicate>(pred)</tt>.
+</blockquote>
+
+<pre>template <<del>class</del> <ins>AdaptableBinaryFunction</ins> P<del>redicate</del> >
+ <ins>requires Predicate< P, P::first_argument_type, P::second_argument_type ></ins>
+ class binary_negate
+ : public binary_function<<del>typename</del> P<del>redicate</del>::first_argument_type,
+ <del>typename</del> P<del>redicate</del>::second_argument_type, bool> {
+ public:
+ <ins>biary_negate(const binary_negate & ) = default;</ins>
+ <ins>binary_negate(binary_negate && );</ins>
+
+ <ins>requires CopyConstructible< P ></ins>
+ explicit binary_negate(const Predicate& pred);
+ <ins>requires MoveConstructible< P >
+ explicit binary_negate(const Predicate& pred);</ins>
+
+ bool operator()(const <del>typename</del> P<del>redicate</del>::first_argument_type& x,
+ const <del>typename</del> P<del>redicate</del>::second_argument_type& y) const;
+ };
+</pre>
+<blockquote>
+-4- <tt>operator()</tt> returns <tt>!pred(x,y)</tt>.
+</blockquote>
+
+<pre>template <class Predicate>
+ binary_negate<Predicate> not2(const Predicate& pred);
+<ins>template <class Predicate>
+ binary_negate<Predicate> not2(Predicate&& pred);</ins>
+</pre>
+
+<blockquote>
+-5- <i>Returns:</i> <tt>binary_negate<Predicate>(pred)</tt>.
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1077"></a>1077. Nonesense <tt>tuple</tt> declarations</h3>
+<p><b>Section:</b> 20.5.2 [tuple.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.tuple">active issues</a> in [tuple.tuple].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Class template tuple 20.5.2 [tuple.tuple]:
+</p>
+
+<blockquote><pre>template <class... UTypes>
+ requires Constructible<Types, const UTypes&>...
+template <class... UTypes>
+ requires Constructible<Types, RvalueOf<UTypes>::type>...
+</pre></blockquote>
+
+<p>
+Somebody needs to look at this and say what it should be.
+</p>
+
+<p><i>[
+2009-03-21 Daniel provided wording.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+The resolution looks correct; move to NAD Editorial.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.5.2 [tuple.tuple], class <tt>tuple</tt>, change as indicated:
+</p>
+
+<blockquote><pre>template <class... UTypes>
+ requires Constructible<Types, const UTypes&>...
+ <ins>tuple(const pair<UTypes...>&);</ins>
+template <class... UTypes>
+ requires Constructible<Types, RvalueOf<UTypes>::type>...
+ <ins>tuple(pair<UTypes...>&&);</ins>
+</pre></blockquote>
+
+<p>
+[NB.: The corresponding prototypes do already exist in 20.5.2.1 [tuple.cnstr]/7+8]
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1078"></a>1078. DE-17: Remove class type_index</h3>
+<p><b>Section:</b> 18.7.2 [type.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-03-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><b>Addresses DE 17</b></p>
+
+<p>
+DE-17:
+</p>
+<p>
+The class <tt>type_index</tt> should be removed; it provides no additional
+functionality beyond providing appropriate concept maps.
+</p>
+
+<p><i>[
+2009-03-31 Peter adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+It is not true, in principle, that <tt>std::type_index</tt> provides no utility
+compared to bare <tt>std::type_info*</tt>.
+</p>
+<p>
+<tt>std::type_index</tt> can avoid the lifetime issues with <tt>type_info</tt> when the
+DLL that has produced the <tt>type_info</tt> object is unloaded. A raw
+<tt>type_info*</tt> does not, and cannot, provide any protection in this case.
+A <tt>type_index</tt> can (if the implementor so chooses) because it can wrap a
+smart (counted or even cloning) pointer to the <tt>type_info</tt> data that is
+needed for <tt>name()</tt> and <tt>before()</tt> to work.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>Modify the header <typeinfo> synopsis in
+ 18.7 [support.rtti]p1 as follows:</p>
+
+<blockquote><pre>namespace std {
+ class type_info;
+ <del>class type_index;</del>
+ template <class T> struct hash;
+ template<> struct hash<<del>type_index</del><ins>const type_info *</ins>> : public std::unary_function<<del>type_index</del><ins>const type_info *</ins>, size_t> {
+ size_t operator()(<del>type_index</del><ins>const type_info *</ins> <del>index</del><ins>t</ins>) const;
+ }<ins>;</ins>
+ <ins>concept_map LessThanComparable<const type_info *> <i>see below</i></ins>
+ class bad_cast;
+ class bad_typeid;
+}
+</pre></blockquote>
+
+<p>Add the following new subsection</p>
+<blockquote>
+<p>
+<ins>18.7.1.1 Template specialization <code>hash<const type_info *></code>
+[type.info.hash]</ins></p>
+
+<pre><ins>size_t operator()(const type_info *x) const;</ins>
+</pre>
+<ol>
+<li><ins><i>Returns</i>: <code>x->hash_code()</code></ins></li>
+</ol>
+</blockquote>
+
+ <p>Add the following new subsection</p>
+ <blockquote>
+<p><ins>18.7.1.2 <code>type_info</code> concept map [type.info.concepts]</ins></p>
+
+
+<pre><ins>concept_map LessThanComparable<const type_info *> {</ins>
+ <ins>bool operator<(const type_info *x, const type_info *y) { return x->before(*y); }</ins>
+ <ins>bool operator<=(const type_info *x, const type_info *y) { return !y->before(*x); }</ins>
+ <ins>bool operator>(const type_info *x, const type_info *y) { return y->before(*x); }</ins>
+ <ins>bool operator>=(const type_info *x, const type_info *y) { return !x->before(*y); }</ins>
+<ins>}</ins>
+</pre>
+<ol>
+ <li><ins><i>Note</i>: provides a well-defined ordering among
+ <code>type_info const</code> pointers, which makes such pointers
+ usable in associative containers (23.4).</ins></li>
+</ol>
+</blockquote>
+
+<p>Remove section 18.7.2 [type.index]</p>
+
+
+
+
+
+<hr>
+<h3><a name="1079"></a>1079. UK-265: <code>RandomAccessIterator</code>'s <code>operator-</code> has nonsensical effects clause</h3>
+<p><b>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses UK 265</b></p>
+
+<p>UK-265:</p>
+<p>
+This effects clause is nonesense. It looks more like an axiom stating
+equivalence, and certainly an effects clause cannot change the state of
+two arguments passed by const reference
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>Modify 24.2.6 [random.access.iterators]p7-9 as follows:</p>
+
+<blockquote><pre>difference_type operator-(const X& a, const X& b);
+</pre>
+<ol start="7">
+ <li><i>Precondition</i>: there exists a value <code>n</code> of
+ <code>difference_type</code> such that <code>a == b + n</code>.</li>
+ <li><del><i>Effects</i>: <code>b == a + (b - a)</code></del></li>
+ <li><i>Returns</i>: <del><code>(a < b) ? distance(a,b) :
+ -distance(b,a)</code></del><ins><code>n</code></ins></li>
+</ol>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1080"></a>1080. Concept ArithmeticLike should provide explicit boolean conversion</h3>
+<p><b>Section:</b> 20.2.13 [concept.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-21 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Astonishingly, the current concept ArithmeticLike as specified in
+20.2.13 [concept.arithmetic] does not provide explicit conversion
+to <tt>bool</tt> although this is a common property of arithmetic types
+(4.12 [conv.bool]). Recent proposals that introduced such types
+(integers of arbitrary precision,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2143.pdf">n2143</a>,
+decimals
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2732.pdf">n2732</a>
+indirectly
+via conversion to <tt>long long</tt>) also took care of such a feature.
+</p>
+<p>
+Adding such an explicit conversion associated function would also
+partly solve a currently invalid effects clause in library, which bases
+on this property, 24.2.6 [random.access.iterators]/2:
+</p>
+<blockquote><pre>{ difference_type m = n;
+ if (m >= 0) while (m--) ++r;
+ else while (m++) --r;
+ return r; }
+</pre></blockquote>
+
+<p>
+Both while-loops take advantage of a contextual conversion to <tt>bool</tt>
+(Another problem is that the >= comparison uses the no
+longer supported existing implicit conversion from <tt>int</tt> to <tt>IntegralLike</tt>).
+</p>
+
+<b>Original proposed resolution:</b>
+<ol>
+<li>
+<p>
+In 20.2.13 [concept.arithmetic], add to the list of less refined
+concepts one further concept:
+</p>
+
+<blockquote><pre>concept ArithmeticLike<typename T>
+ : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>,
+ HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>,
+ HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>,
+ HasPostdecrement<T>,
+ HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>,
+ HasMultiplyAssign<T, const T&>,
+ HasDivideAssign<T, const T&><ins>, ExplicitlyConvertible<T, bool></ins> {
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 24.2.6 [random.access.iterators]/2 change the current effects clause
+as indicated [The proposed insertion fixes the problem that the previous
+implicit construction from integrals has been changed to an explicit
+constructor]:
+</p>
+<blockquote><pre>{ difference_type m = n;
+ if (m >= <ins>difference_type(</ins>0<ins>)</ins>) while (m--) ++r;
+ else while (m++) --r;
+ return r; }
+</pre></blockquote>
+</li>
+</ol>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree that arithmetic types ought be convertible to <tt>bool</tt>,
+and we therefore agree with the proposed resolution's paragraph 1.
+</p>
+<p>
+We do not agree that the cited effects clause is invalid,
+as it expresses intent rather than specific code.
+</p>
+<p>
+Move to Review, pending input from concepts experts.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.2.13 [concept.arithmetic], add to the list of less refined
+concepts one further concept:
+</p>
+
+<blockquote><pre>concept ArithmeticLike<typename T>
+ : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>,
+ HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>,
+ HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>,
+ HasPostdecrement<T>,
+ HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>,
+ HasMultiplyAssign<T, const T&>,
+ HasDivideAssign<T, const T&><ins>, ExplicitlyConvertible<T, bool></ins> {
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1081"></a>1081. Response to UK 216</h3>
+<p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses UK 216, JP 46, JP 48</b></p>
+
+<p>
+All the containers use concepts for their iterator usage, exect for
+<tt>basic_string</tt>. This needs fixing.
+</p>
+
+<p>
+Use concepts for iterator template parameters throughout the chapter.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+NB comments to be handled by Dave Abrahams and Howard Hinnant with
+advice from PJP: UK216 (which duplicates) JP46, JP48. JP46 supplies
+extensive proposed wording; start there.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1082"></a>1082. Response to JP 49</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> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</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><b>Addresses JP 49</b></p>
+
+<p>
+<tt>codecvt</tt> does not use concept. For example, create <tt>CodeConvert</tt>
+concept and change as follows.
+</p>
+
+<blockquote><pre>template<CodeConvert Codecvt, class Elem = wchar_t>
+ class wstring_convert {
+</pre></blockquote>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1083"></a>1083. Response to JP 52, 53</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> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</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><b>Addresses JP 52, JP 53</b></p>
+
+<p>
+<tt>InputIterator</tt> does not use concept.
+</p>
+
+<p>
+<tt>OutputIterator</tt> does not use concept.
+</p>
+
+<p>
+Comments include proposed wording.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1084"></a>1084. Response to UK 250</h3>
+<p><b>Section:</b> 24.2.4 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-06-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses UK 250</b></p>
+
+<p>
+A default implementation should be supplied for the post-increment
+operator to simplify implementation of iterators by users.
+</p>
+
+<p>
+Copy the Effects clause into the concept description as the default
+implementation. Assumes a default value for postincrement_result
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+Howard will open an issue.
+</blockquote>
+
+<p><i>[
+2009-06-07 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+This issue cannot currently be resolved as suggested, because
+that would render auto-detection of the return type
+<tt>postincrement_result</tt> invalid, see 14.10.2.2 [concept.map.assoc]/4+5. The
+best fix would be to add a default type to that associated type, but
+unfortunately any default type will prevent auto-deduction of types of
+associated functions as quoted above. A corresponding core issue
+is in preparation.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p><i>[
+This wording assumes the acceptance of UK 251 / <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>. Both
+wordings change the same paragraphs.
+]</i></p>
+
+
+<p>
+Change 24.2.4 [forward.iterators]:
+</p>
+
+<blockquote>
+<pre>concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> {
+
+ MoveConstructible postincrement_result;
+ requires HasDereference<postincrement_result>
+ && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;
+
+ postincrement_result operator++(X& r, int)<del>;</del> <ins>{
+ X tmp = r;
+ ++r;
+ return tmp;
+ }</ins>
+
+ axiom MultiPass(X a, X b) {
+ if (a == b) *a == *b;
+ if (a == b) ++a == ++b;
+ }
+}
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1085"></a>1085. Response to UK 258</h3>
+<p><b>Section:</b> 24.2.5 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-06-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses UK 258</b></p>
+
+<p>
+A default implementation should be supplied for the post-decrement
+operator to simplify implementation of iterators by users.
+</p>
+
+<p>
+Copy the Effects clause into the concept description as the default
+implementation. Assumes a default value for postincrement_result
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+Howard will open an issue.
+</blockquote>
+
+<p><i>[
+2009-06-07 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+This issue cannot currently be resolved as suggested, because
+that would render auto-detection of the return type
+<tt>postdecrement_result</tt> invalid, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a>.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change 24.2.5 [bidirectional.iterators]:
+</p>
+
+<blockquote>
+<pre>concept BidirectionalIterator<typename X> : ForwardIterator<X> {
+ MoveConstructible postdecrement_result;
+ requires HasDereference<postdecrement_result>
+ && Convertible<HasDereference<postdecrement_result>::result_type, const value_type&>
+ && Convertible<postdecrement_result, const X&>;
+ X& operator--(X&);
+ postdecrement_result operator--(X& <ins>r</ins>, int)<del>;</del> <ins>{
+ X tmp = r;
+ --r;
+ return tmp;
+ }</ins>
+}
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1086"></a>1086. Response to UK 284</h3>
+<p><b>Section:</b> 24.6 [stream.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses UK 284</b></p>
+
+<p>
+The stream iterators need constraining with concepts/requrires clauses.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+We agree. To be handled by Howard, Martin and PJ.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1087"></a>1087. Response to UK 301</h3>
+<p><b>Section:</b> 25.4.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-06-11</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.replace">active issues</a> in [alg.replace].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses UK 301</b></p>
+
+<p>
+<tt>replace</tt> and <tt>replace_if</tt> have the requirement: <tt>OutputIterator<Iter,
+Iter::reference></tt> Which implies they need to copy some values in the
+range the algorithm is iterating over. This is not however the case, the
+only thing that happens is <tt>const T&</tt>s might be copied over existing
+elements (hence the <tt>OutputIterator<Iter, const T&></tt>.
+</p>
+
+<p>
+Remove <tt>OutputIterator<Iter, Iter::reference></tt> from <tt>replace</tt>
+and <tt>replace_if</tt>.
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+We agree. To be handled by Howard.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change in 25.2 [algorithms.syn] and 25.4.5 [alg.replace]:
+</p>
+
+<blockquote><pre>template<ForwardIterator Iter, class T>
+ requires <del>OutputIterator<Iter, Iter::reference>
+ &&</del> OutputIterator<Iter, const T&>
+ && HasEqualTo<Iter::value_type, T>
+ void replace(Iter first, Iter last,
+ const T& old_value, const T& new_value);
+
+template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T>
+ requires <del>OutputIterator<Iter, Iter::reference>
+ &&</del> OutputIterator<Iter, const T&>
+ && CopyConstructible<Pred>
+ void replace_if(Iter first, Iter last,
+ Pred pred, const T& new_value);
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1088"></a>1088. Response to UK 342</h3>
+<p><b>Section:</b> 30.6.6 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses UK 342</b></p>
+
+<p>
+<tt>std::promise</tt> is missing a non-member overload of <tt>swap</tt>. This is
+inconsistent with other types that provide a <tt>swap</tt> member function.
+</p>
+
+<p>
+Add a non-member overload <tt>void swap(promise&& x,promise&& y){ x.swap(y); }</tt>
+</p>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+Create an issue. Move to review, attention: Howard. Detlef will also
+look into it.
+</blockquote>
+
+<p><i>[
+Post Summit Daniel provided wording.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+In 30.6.6 [futures.promise], before p.1, immediately after class template
+promise add:
+</p>
+<blockquote><pre><ins>
+template <class R>
+void swap(promise<R>& x, promise<R>& y);
+</ins>
+</pre></blockquote>
+</li>
+<li>
+<p>
+Change 30.6.6 [futures.promise]/10 as indicated (to fix a circular definition):
+</p>
+<blockquote>
+<p>
+-10- <i>Effects:</i> <del>swap(*this, other)</del><ins>Swaps the associated state
+of <tt>*this</tt> and <tt>other</tt></ins>
+</p>
+<p>
+<ins><i>Throws:</i> Nothing.</ins>
+</p>
+</blockquote>
+</li>
+<li>
+<p>
+After the last paragraph in 30.6.6 [futures.promise] add the following
+prototype description:
+</p>
+<blockquote><pre><ins>
+template <class R>
+void swap(promise<R>& x, promise<R>& y);
+</ins></pre>
+<blockquote>
+<p>
+<ins><i>Effects:</i> <tt>x.swap(y)</tt></ins>
+</p>
+<p>
+<ins><i>Throws:</i> Nothing.</ins>
+</p>
+</blockquote>
+</blockquote>
+</li>
+
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="1089"></a>1089. Response to JP 76</h3>
+<p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread">active issues</a> in [thread].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses JP 76</b></p>
+
+<p>
+A description for "Throws: Nothing." are not unified.
+</p>
+
+<p>
+At the part without throw, "Throws: Nothing." should be described.
+</p>
+
+<p>
+Add "Throws: Nothing." to the following.
+</p>
+
+<ul>
+<li>
+30.3.1.6 [thread.thread.static] p1
+</li>
+<li>
+30.4.3.1 [thread.lock.guard] p4
+</li>
+<li>
+30.4.3.2.1 [thread.lock.unique.cons] p6
+</li>
+<li>
+30.5.1 [thread.condition.condvar] p7 and p8
+</li>
+<li>
+30.5.2 [thread.condition.condvarany] p6, p7, p19, p21 and p25
+</li>
+</ul>
+
+<p><i>[
+Summit:
+]</i></p>
+
+<blockquote>
+Pass on to editor.
+</blockquote>
+
+<p><i>[
+Post Summit: Editor declares this non-editorial.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1090"></a>1090. Missing description of <tt>packaged_task</tt> member <tt>swap</tt>, missing non-member <tt>swap</tt></h3>
+<p><b>Section:</b> 30.6.8 [futures.task] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-05-24</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Class template <tt>packaged_task</tt> in 30.6.8 [futures.task] shows a member <tt>swap</tt>
+declaration, but misses to
+document it's effects (No prototype provided). Further on this class
+misses to provide a non-member
+swap.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Alisdair notes that paragraph 2 of the proposed resolution has already been
+applied in the current Working Draft.
+</p>
+<p>
+We note a pending <tt>future</tt>-related paper by Detlef;
+we would like to wait for this paper before proceeding.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+<p><i>[
+2009-05-24 Daniel removed part 2 of the proposed resolution.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+In 30.6.8 [futures.task], immediately after the definition of class
+template packaged_task add:
+</p>
+<blockquote><pre><ins>
+template<class R, class... Argtypes>
+void swap(packaged_task<R(ArgTypes...)>&, packaged_task<R(ArgTypes...)>&);
+</ins>
+</pre></blockquote>
+</li>
+</ol>
+
+<ol start="3">
+<li>
+<p>
+In 30.6.8 [futures.task], immediately after <tt>operator=</tt> prototype
+description (After p. 8) add:
+</p>
+<blockquote><pre><ins>void swap(packaged_task& other);</ins>
+</pre>
+<blockquote>
+<p><ins>
+<i>Effects:</i> Swaps the associated state of <tt>*this</tt> and <tt>other</tt>.
+</ins></p>
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
+</blockquote>
+</blockquote>
+</li>
+<li>
+<p>
+At the end of 30.6.8 [futures.task] (after p. 20), add add the following
+prototype description:
+</p>
+
+<blockquote><pre><ins>
+template<class R, class... Argtypes>
+void swap(packaged_task<R(ArgTypes...)>& x, packaged_task<R(ArgTypes...)>& y);
+</ins></pre>
+<blockquote>
+<p><ins>
+<i>Effects:</i> <tt>x.swap(y)</tt>
+</ins></p>
+<p><ins>
+<i>Throws:</i> Nothing.
+</ins></p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="1091"></a>1091. Response to UK 246</h3>
+<p><b>Section:</b> 23.4.2.2 [multimap.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 246</b></p>
+<p>
+The content of this sub-clause is purely trying to describe in words the
+effect of the requires clauses on these operations, now that we have
+Concepts. As such, the description is more confusing than the signature
+itself. The semantic for these functions is adequately covered in the
+requirements tables in 23.2.4 [associative.reqmts].
+</p>
+
+<p><i>[
+Beman adds:
+]</i></p>
+
+
+<blockquote>
+Pete is clearly right that
+this one is technical rather than editorial.
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the proposed resolution.
+</p>
+<p>
+Move to Review.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Strike 23.4.2.2 [multimap.modifiers] entirely
+(but do NOT strike these signatures from the class template definition!).
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1092"></a>1092. Class template <tt>integral_constant</tt> should be a constrained template</h3>
+<p><b>Section:</b> 20.6.3 [meta.help] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.help">active issues</a> in [meta.help].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.help">issues</a> in [meta.help].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+A first step to change the type traits predicates to constrained templates is to
+constrain their common base template <tt>integral_constant</tt>. This can be done,
+without enforcing depending classes to be constrained as well, but not
+vice versa
+without brute force <tt>late_check</tt> usages. The following proposed resolution depends
+on the resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open, pending a paper that looks at constraints
+for the entirety of the type traits
+and their relationship to the foundation concepts.
+We recommend this be deferred
+until after the next Committee Draft is issued.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+In 20.6.2 [meta.type.synop], Header <tt><type_traits></tt>
+synopsis change as indicated:
+</p>
+<blockquote><pre>namespace std {
+// 20.5.3, helper class:
+template <<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v> struct integral_constant;
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 20.6.3 [meta.help] change as indicated:
+</p>
+<blockquote><pre>template <<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v>
+struct integral_constant {
+ static constexpr T value = v;
+ typedef T value_type;
+ typedef integral_constant<T,v> type;
+ constexpr operator value_type() { return value; }
+};
+</pre></blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="1093"></a>1093. Multiple definitions for random_shuffle algorithm</h3>
+<p><b>Section:</b> 25.4.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-06-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.random.shuffle">issues</a> in [alg.random.shuffle].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+There are a couple of issues with the declaration of the <tt>random_shuffle</tt>
+algorithm accepting a random number engine.
+</p>
+
+<ol type="i">
+<li>
+The Iterators must be shuffle iterators, yet this requirement is missing.
+</li>
+<li>
+The <tt>RandomNumberEngine</tt> concept is now provided by the random number
+library
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">n2836</a>)
+and the placeholder should be removed.
+</li>
+</ol>
+
+<p><i>[
+2009-05-02 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+this issue completes adding necessary requirement to the
+third new <tt>random_shuffle</tt> overload. The current suggestion is:
+</p>
+
+<blockquote><pre>template<RandomAccessIterator Iter, UniformRandomNumberGenerator Rand>
+requires ShuffleIterator<Iter>
+void random_shuffle(Iter first, Iter last, Rand&& g);
+</pre></blockquote>
+
+<p>
+IMO this is still insufficient and I suggest to add the requirement
+</p>
+<blockquote><pre>Convertible<Rand::result_type, Iter::difference_type>
+</pre></blockquote>
+<p>
+to the list (as the two other overloads already have).
+</p>
+
+<p>
+Rationale:
+</p>
+
+<blockquote>
+<p>
+Its true that this third overload is somewhat different from the remaining
+two. Nevertheless we know from <tt>UniformRandomNumberGenerator</tt>, that
+it's <tt>result_type</tt> is an integral type and that it satisfies
+<tt>UnsignedIntegralLike<result_type></tt>.
+</p>
+<p>
+To realize it's designated task, the algorithm has to invoke the
+<tt>Callable</tt> aspect of <tt>g</tt> and needs to perform some algebra involving
+it's <tt>min()/max()</tt> limits to compute another index value that
+at this point is converted into <tt>Iter::difference_type</tt>. This is so,
+because 24.2.6 [random.access.iterators] uses this type as argument
+of it's algebraic operators. Alternatively consider the equivalent
+iterator algorithms in 24.4 [iterator.operations] with the same result.
+</p>
+<p>
+This argument leads us to the conclusion that we also need
+<tt>Convertible<Rand::result_type, Iter::difference_type></tt> here.
+</p>
+</blockquote>
+
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Alisdair notes that point (ii) has already been addressed.
+</p>
+<p>
+We agree with the proposed resolution to point (i)
+with Daniel's added requirement.
+</p>
+<p>
+Move to Review.
+</p>
+</blockquote>
+
+<p><i>[
+2009-06-05 Daniel updated proposed wording as recommended in Batavia.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change in 25.2 [algorithms.syn] and 25.4.12 [alg.random.shuffle]:
+</p>
+
+<blockquote><pre><del>concept UniformRandomNumberGenerator<typename Rand> { }</del>
+template<RandomAccessIterator Iter, UniformRandomNumberGenerator Rand>
+ <ins>requires ShuffleIterator<Iter> &&
+ Convertible<Rand::result_type, Iter::difference_type></ins>
+ void random_shuffle(Iter first, Iter last, Rand&& g);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1094"></a>1094. Response to JP 65 and JP 66</h3>
+<p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-24 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses JP 65 and JP 66</b></p>
+
+<p>
+Switch from "unspecified-bool-type" to "explicit operator bool() const".
+</p>
+
+<p>
+Replace <tt>operator unspecified-bool-type() const;</tt>" with <tt>explicit operator bool() const;</tt>
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to Review.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopis in 27.5.4 [ios]:
+</p>
+
+<blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
+</pre></blockquote>
+
+<p>
+Change 27.5.4.3 [iostate.flags]:
+</p>
+
+<blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
+</pre>
+
+<blockquote>
+<p>
+-1- <i>Returns:</i> <ins><tt>!fail()</tt></ins> <del>If <tt>fail()</tt> then a value that will evaluate
+false in a boolean context; otherwise a value that will evaluate true in
+a boolean context. The value type returned shall not be convertible to
+int.</del>
+</p>
+<p>
+<del>[<i>Note:</i> This conversion can be used in contexts where a bool is expected
+(e.g., an <tt>if</tt> condition); however, implicit conversions (e.g.,
+to <tt>int</tt>) that can occur with <tt>bool</tt> are not allowed,
+eliminating some sources of user error. One possible implementation
+choice for this type is pointer-to-member. <i>-- end note</i>]</del>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="1095"></a>1095. <i>Shared objects and the library</i> wording unclear</h3>
+<p><b>Section:</b> 17.6.3.10 [res.on.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-03-27 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2775.htm">N2775</a>,
+<i>Small library thread-safety revisions</i>, among other changes, removed a note from
+17.6.3.10 [res.on.objects] that read:
+</p>
+
+<blockquote>
+[<i>Note:</i> This prohibition against concurrent non-const access means that
+modifying an object of a standard library type shared between threads
+without using a locking mechanism may result in a data race. <i>--end note</i>.]
+</blockquote>
+
+<p>
+That resulted in wording which is technically correct but can only be
+understood by reading the lengthy and complex 17.6.4.7 [res.on.data.races]
+Data race avoidance. This has the effect of making
+17.6.3.10 [res.on.objects] unclear, and has already resulted in a query
+to the LWG reflector. See c++std-lib-23194.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+The proposed wording seems to need a bit of tweaking
+("really bad idea" isn't quite up to standardese).
+We would like feedback
+as to whether the original Note's removal was intentional.
+</p>
+<p>
+Change the phrase "is a really bad idea"
+to "risks undefined behavior" and
+move to Review status.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 17.6.3.10 [res.on.objects] as indicated:
+</p>
+
+<blockquote>
+<p>
+The behavior of a program is undefined if calls to standard library
+functions from different threads may introduce a data race. The
+conditions under which this may occur are specified in 17.6.4.7.
+</p>
+<p><ins>
+[<i>Note:</i> Thus modifying an object of a standard library type shared between
+threads risks undefined behavior unless objects of the type are explicitly
+specified as being sharable without data races or the user supplies a
+locking mechanism. <i>--end note</i>]
+</ins></p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1096"></a>1096. unconstrained rvalue ref parameters</h3>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-21 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+TODO: Look at all cases of unconstrained rvalue ref parameters and check
+that concept req'ts work when <tt>T</tt> deduced as reference.
+</p>
+
+<p>
+ We found some instances where that was not done correctly and we figure
+ the possibility of deducing <tt>T</tt> to be an lvalue reference was probably
+ overlooked elsewhere.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open, pending proposed wording from Dave for further review.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1097"></a>1097. #define __STDCPP_THREADS</h3>
+<p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses DE 18</b></p>
+
+<p>
+Freestanding implementations do not (necessarily) have
+ support for multiple threads (see 1.10 [intro.multithread]).
+ Applications and libraries may want to optimize for the
+ absence of threads. I therefore propose a preprocessor
+ macro to indicate whether multiple threads can occur.
+</p>
+
+<p>
+There is ample prior implementation experience for this
+ feature with various spellings of the macro name. For
+ example, gcc implicitly defines <tt>_REENTRANT</tt>
+ if multi-threading support is selected on the compiler
+ command-line.
+</p>
+
+<p>
+While this is submitted as a library issue, it may be more
+ appropriate to add the macro in 16.8 cpp.predefined in the
+ core language.
+</p>
+
+<p>
+See also
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the issue, and believe it is properly a library issue.
+</p>
+<p>
+We prefer that the macro be conditionally defined
+as part of the <tt><thread></tt> header.
+</p>
+<p>
+Move to Review.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Insert a new subsection before 18.2 [support.types], entitled
+"Feature Macros" (support.macros):
+</p>
+<blockquote>
+<p>
+The standard library defines the following macros; no explicit
+prior inclusion of any header file is necessary.
+</p>
+<blockquote>
+<dl>
+<dt><tt>__STDCPP_THREADS</tt></dt>
+<dd>
+The macro <tt>__STDCPP_THREADS</tt> shall be defined if and only if a
+ program can have more than one thread of execution (1.10 [intro.multithread]).
+If the macro is defined, it shall have the same
+ value as the predefined macro <tt>__cplusplus</tt> (16.8 [cpp.predefined]).
+</dd>
+</dl>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1098"></a>1098. definition of get_pointer_safety()</h3>
+<p><b>Section:</b> 20.8.13.7 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses DE 18</b></p>
+
+<p>
+ In 20.8.13.7 [util.dynamic.safety], <tt>get_pointer_safety()</tt> purports
+to define behavior for
+ non-safely derived pointers (3.7.4.3 [basic.stc.dynamic.safety]). However,
+ the cited core-language section in paragraph 4 specifies undefined behavior
+ for the use of such pointer values. This seems an unfortunate near-contradiction.
+ I suggest to specify the term <i>relaxed pointer safety</i> in
+ the core language section and refer to it from the library description.
+ This issue deals with the library part, the corresponding core issue (c++std-core-13940)
+ deals with the core modifications.
+</p>
+
+<p>
+See also
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We recommend if this issue is to be moved,
+the issue be moved concurrently with the cited Core issue.
+</p>
+<p>
+We agree with the intent of the proposed resolution.
+We would like input from garbage collection specialists.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.8.13.7 [util.dynamic.safety] p16, replace the description of
+<tt>get_pointer_safety()</tt> with:
+</p>
+
+<blockquote>
+<p>
+<tt>pointer_safety get_pointer_safety();</tt>
+</p>
+<blockquote>
+<p>
+<del><i>Returns:</i> an enumeration value indicating the implementation's treatment
+of pointers that are not safely derived (3.7.4.3). Returns
+<tt>pointer_safety::relaxed</tt> if pointers that are not safely derived will be
+treated the same as pointers that are safely derived for the duration of
+the program. Returns <tt>pointer_safety::preferred</tt> if pointers that are not
+safely derived will be treated the same as pointers that are safely
+derived for the duration of the program but allows the implementation to
+hint that it could be desirable to avoid dereferencing pointers that are
+not safely derived as described. [<i>Example:</i> <tt>pointer_safety::preferred</tt>
+might be returned to detect if a leak detector is running to avoid
+spurious leak reports. -- <i>end note</i>] Returns <tt>pointer_safety::strict</tt> if
+pointers that are not safely derived might be treated differently than
+pointers that are safely derived.</del>
+</p>
+<p><ins>
+<i>Returns:</i> Returns <tt>pointer_safety::strict</tt> if the implementation has
+ strict pointer safety (3.7.4.3 [basic.stc.dynamic.safety]). It is
+ implementation-defined whether <tt>get_pointer_safety</tt> returns
+ <tt>pointer_safety::relaxed</tt> or <tt>pointer_safety::preferred</tt> if the
+ implementation has relaxed pointer safety
+ (3.7.4.3 [basic.stc.dynamic.safety]).<sup>Footnote</sup>
+</ins></p>
+
+<p><ins>
+<i>Throws:</i> nothing
+</ins></p>
+
+<p><ins>
+Footnote) <tt>pointer_safety::preferred</tt> might be returned to indicate to the
+ program that a leak detector is running so that the program can avoid
+ spurious leak reports.
+</ins>
+</p>
+
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1099"></a>1099. Various issues</h3>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-21 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Notes
+</p>
+<blockquote>
+<p>
+[2009-03-21 Sat] p. 535 at the top we need MoveConstructible V1,
+MoveConstructible V2 (where V1,V2 are defined on 539). Also make_tuple
+on 550
+</p>
+<p>
+[2009-03-21 Sat] p1183 thread ctor, and in general, we need a way to
+talk about "copiable from generalized rvalue ref argument" for cases
+where we're going to forward and copy.
+</p>
+<blockquote>
+<p>
+ This issue may well be quite large. Language in para 4 about "if
+ an lvalue" is wrong because types aren't expressions.
+</p>
+<p>
+ p1199, call_once has all the same issues.
+</p>
+</blockquote>
+<p>
+[2009-03-21 Sat] p869 InputIterator pointer type should not be required
+to be convertible to const value_type*, rather it needs to have a
+operator-> of its own that can be used for the value type.
+</p>
+<p>
+[2009-03-21 Sat] p818 stack has the same problem with default ctor.
+</p>
+<p>
+[2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so
+</p>
+<blockquote><pre> requires MoveConstructible<Cont>
+ explicit priority_queue(const Compare& x = Compare(), Cont&& = Cont());
+</pre>
+<p>
+ Don't require MoveConstructible when default constructing Cont.
+ Also missing semantics for move ctor.
+</p>
+</blockquote>
+<p>
+ [2009-03-21 Sat] Why are Allocators required to be CopyConstructible as
+ opposed to MoveConstructible?
+</p>
+<p>
+ [2009-03-21 Sat] p813 queue needs a separate default ctor (Cont needn't
+ be MoveConstructible). No documented semantics for move c'tor. Or
+ *any* of its 7 ctors!
+</p>
+<p>
+ [2009-03-21 Sat] std::array should have constructors for C++0x,
+ consequently must consider move construction.
+</p>
+
+<p><i>[
+2009-05-01 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+This could be done as part of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, which already handles
+deviation of <tt>std::array</tt> from container tables.
+</blockquote>
+
+<p>
+ [2009-03-21 Sat] p622 all messed up.
+</p>
+<blockquote>
+<p>
+ para 8 "implementation-defined" is the wrong term; should be "see
+ below" or something.
+</p>
+<p>
+ para 12 "will be selected" doesn't make any sense because we're not
+ talking about actual arg types.
+</p>
+<p>
+ paras 9-13 need to be totally rewritten for concepts.
+</p>
+</blockquote>
+
+<p>
+ [2009-03-21 Sat] Null pointer comparisons (p587) have all become
+ unconstrained. Need to fix that
+</p>
+<p>
+ [2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration.
+ We think CopyConstructible is the right reqt.
+</p>
+<p>
+ make_pair needs Constructible<V1, T1&&> requirements!
+</p>
+<p>
+ make_tuple needs something similar
+</p>
+<p>
+ tuple bug in synopsis:
+</p>
+<blockquote><pre> template <class... UTypes>
+ requires Constructible<Types, const UTypes&>...
+ template <class... UTypes>
+ requires Constructible<Types, RvalueOf<UTypes>::type>...
+</pre>
+<p>
+ Note: removal of MoveConstructible requirements in std::function makes
+ these routines unconstrained!
+</p>
+</blockquote>
+
+<p><i>[
+2009-05-02 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+This part of the issue is already covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>.
+</blockquote>
+
+<p>
+ these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ]
+</p>
+<blockquote><pre> unique_ptr(pointer p, implementation-defined d);
+ unique_ptr(pointer p, implementation-defined d);
+</pre></blockquote>
+<p>
+ multimap range constructor should not have MoveConstructible<value_type> requirement.
+</p>
+<blockquote>
+ same with insert(..., P&&); multiset has the same issue, as do
+ unordered_multiset and unordered_multimap. Review these!
+</blockquote>
+
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open, pending proposed wording from Dave for further review.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1100"></a>1100. <tt>auto_ptr</tt> to <tt>unique_ptr</tt> conversion</h3>
+<p><b>Section:</b> D.9 [depr.auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Message c++std-lib-23182 led to a discussion in which several people
+expressed interest in being able to convert an <tt>auto_ptr</tt> to a
+<tt>unique_ptr</tt> without the need to call <tt>release</tt>. Below is
+wording to accomplish this.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Pete believes it not a good idea to separate parts of a class's definition.
+Therefore, if we do this,
+it should be part of <tt>unique-ptr</tt>'s specification.
+</p>
+<p>
+Alisdair believes the lvalue overload may be not necessary.
+</p>
+<p>
+Marc believes it is more than just sugar,
+as it does ease the transition to <tt>unique-ptr</tt>.
+</p>
+<p>
+We agree with the resolution as presented.
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to D.9 [depr.auto.ptr]:
+</p>
+
+<blockquote>
+<p>
+The following <tt>unique_ptr</tt> constructors are in addition to those specified
+in 20.8.12.2.1 [unique.ptr.single.ctor].
+</p>
+<pre>template <class T, class D>
+class unique_ptr
+{
+public:
+ template <class U>
+ requires SameType<D, default_delete<T>>
+ && Convertible<U*, T*>
+ unique_ptr(auto_ptr<U>& u);
+ template <class U>
+ requires SameType<D, default_delete<T>>
+ && Convertible<U*, T*>
+ unique_ptr(auto_ptr<U>&& u);
+};
+</pre>
+<p>
+<i>Effects:</i> Constructs a <tt>unique_ptr</tt> with <tt>u.release()</tt>.
+</p>
+
+<p>
+<i>Postconditions:</i> <tt>get() == </tt> the value <tt>u.get()</tt> had before
+the construciton, modulo any required offset adjustments resulting from the cast from
+<tt>U*</tt> to <tt>T*</tt>. <tt>u.get() == nullptr</tt>.
+</p>
+
+<p>
+<i>Throws:</i> nothing.
+</p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1101"></a>1101. <tt>unique</tt> requirements</h3>
+<p><b>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+From Message c++std-core-14160 Howard wrote:
+</p>
+
+<blockquote>
+It was the intent of the rvalue reference proposal for unique to only require MoveAssignable:
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1860.html#25.2.9%20-%20Unique">N1860</a>.
+</blockquote>
+
+<p>
+And Pete replied:
+</p>
+
+<blockquote>
+That was overridden by the subsequent changes made for concepts in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2573.pdf">N2573</a>,
+which reimposed the C++03 requirements.
+</blockquote>
+
+<p>
+My impression is that this overwrite was a simple (unintentional) mistake.
+Wording below to correct it.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Howard notes this issue resolves a discrepancy between the synopsis
+and the description.
+</p>
+<p>
+Move to NAD Editorial.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 25.4.9 [alg.unique]:
+</p>
+
+<blockquote><pre>template<ForwardIterator Iter>
+ requires OutputIterator<Iter, <ins>RvalueOf<</ins>Iter::reference<ins>>::type</ins>>
+ && EqualityComparable<Iter::value_type>
+ Iter unique(Iter first, Iter last);
+
+template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred>
+ requires OutputIterator<Iter, RvalueOf<Iter::reference>::type>
+ && CopyConstructible<Pred>
+ Iter unique(Iter first, Iter last, Pred pred);
+</pre></blockquote>
+
+<p>
+Note that the synopsis in 25.2 [algorithms.syn] is already correct.
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="1102"></a>1102. <tt>std::vector</tt>'s reallocation policy still unclear</h3>
+<p><b>Section:</b> 23.3.6.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-04-20 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I have the impression that even the wording of current draft
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
+does insufficiently express the intent of <tt>vector</tt>'s
+reallocation strategy. This has produced not too old library
+implementations which release memory in the <tt>clear()</tt> function
+and even modern articles about C++ programming cultivate
+the belief that <tt>clear</tt> is allowed to do exactly this. A typical
+example is something like this:
+</p>
+
+<blockquote><pre>const int buf_size = ...;
+std::vector<T> buf(buf_size);
+for (int i = 0; i < some_condition; ++i) {
+ buf.resize(buf_size);
+ write_or_read_data(buf.data());
+ buf.clear(); // Ensure that the next round get's 'zeroed' elements
+}
+</pre></blockquote>
+<p>
+where still the myth is ubiquitous that <tt>buf</tt> might be
+allowed to reallocate it's memory *inside* the <tt>for</tt> loop.
+</p>
+<p>
+IMO the problem is due to the fact, that
+</p>
+
+<ol type="a">
+<li>
+the actual memory-reallocation stability of <tt>std::vector</tt>
+is explained in 23.3.6.2 [vector.capacity]/3 and /6 which
+are describing just the effects of the <tt>reserve</tt>
+function, but in many examples (like above) there
+is no explicit call to <tt>reserve</tt> involved. Further-more
+23.3.6.2 [vector.capacity]/6 does only mention <em>insertions</em>
+and never mentions the consequences of erasing
+elements.
+</li>
+<li>
+<p>
+the effects clause of <tt>std::vector</tt>'s <tt>erase</tt> overloads in
+23.3.6.4 [vector.modifiers]/4 is silent about capacity changes. This
+easily causes a misunderstanding, because the counter
+parting insert functions described in 23.3.6.4 [vector.modifiers]/2
+explicitly say, that
+</p>
+<blockquote>
+Causes reallocation if the new size is greater than the
+old capacity. If no reallocation happens, all the iterators
+and references before the insertion point remain valid.
+</blockquote>
+<p>
+It requires a complex argumentation chain about four
+different places in the standard to provide the - possibly
+weak - proof that calling <tt>clear()</tt> also does <em>never</em> change
+the capacity of the <tt>std::vector</tt> container. Since <tt>std::vector</tt>
+is the de-facto replacement of C99's dynamic arrays this
+type is near to a built-in type and it's specification should
+be clear enough that usual programmers can trust their
+own reading.
+</p>
+</li>
+</ol>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Bill believes paragraph 1 of the proposed resolution is unnecessary
+because it is already implied (even if tortuously) by the current wording.
+</p>
+<p>
+Move to Review.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p><i>[
+This is a minimum version. I also
+suggest that the wording explaining the allocation strategy
+of <tt>std::vector</tt> in 23.3.6.2 [vector.capacity]/3 and /6 is moved into
+a separate sub paragraph of 23.3.6.2 [vector.capacity] <em>before</em>
+any of the prototype's are discussed, but I cannot provide
+reasonable wording changes now
+]</i></p>
+
+
+<ol>
+<li>
+<p>
+Change 23.3.6.2 [vector.capacity]/6 as follows:
+</p>
+<blockquote>
+It is guaranteed that no reallocation takes place during
+insertions <ins>or erasures</ins> that happen after a call
+to <tt>reserve()</tt> until the time when an insertion would make
+the size of the vector greater than the value of <tt>capacity()</tt>.
+</blockquote>
+</li>
+<li>
+<p>
+Change 23.3.6.4 [vector.modifiers]/4 as follows:
+</p>
+<blockquote>
+<i>Effects:</i> <ins>The capacity shall remain unchanged and no reallocation shall
+happen.</ins>
+Invalidates iterators and references at or after the point
+of the erase.
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="1103"></a>1103. <tt>system_error</tt> constructor postcondition overly strict</h3>
+<p><b>Section:</b> 19.5.5.2 [syserr.syserr.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+19.5.5.2 [syserr.syserr.members] says:
+</p>
+
+<blockquote><pre>system_error(error_code ec, const string& what_arg);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+However the intent is for:
+</p>
+
+<blockquote><pre>std::system_error se(std::errc::not_a_directory, "In FooBar");
+...
+se.what(); <font color="#c80000">// returns something along the lines of:</font>
+ <font color="#c80000">// "In FooBar: Not a directory"</font>
+</pre></blockquote>
+
+<p>
+The way the constructor postconditions are set up now, to achieve both
+conformance, and the desired intent in the <tt>what()</tt> string, the
+<tt>system_error</tt> constructor must store "In FooBar" in the base class,
+and then form the desired output each time <tt>what()</tt> is called. Or
+alternatively, store "In FooBar" in the base class, and store the desired
+<tt>what()</tt> string in the derived <tt>system_error</tt>, and override
+<tt>what()</tt> to return the string in the derived part.
+</p>
+
+<p>
+Both of the above implementations seem suboptimal to me. In one I'm computing
+a new string every time <tt>what()</tt> is called. And since <tt>what()</tt>
+can't propagate exceptions, the client may get a different string on different
+calls.
+</p>
+
+<p>
+The second solution requires storing two strings instead of one.
+</p>
+
+<p>
+What I would like to be able to do is form the desired <tt>what()</tt> string
+once in the <tt>system_error</tt> constructor, and store <em>that</em> in the
+base class. Now I'm:
+</p>
+
+<ol>
+<li>Computing the desired <tt>what()</tt> only once.</li>
+<li>The base class <tt>what()</tt> definition is sufficient and nothrow.</li>
+<li>I'm not storing multiple strings.</li>
+</ol>
+
+<p>
+This is smaller code, smaller data, and faster.
+</p>
+
+<p>
+<tt>ios_base::failure</tt> has the same issue.
+</p>
+
+<p><i>[
+Comments about this change received favorable comments from the <tt>system_error</tt>
+designers.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+
+<blockquote>
+<p>
+We agree with the proposed resolution.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 19.5.5.2 [syserr.syserr.members], change the following constructor postconditions:
+</p>
+
+<blockquote>
+<pre>system_error(error_code ec, const string& what_arg);
+</pre>
+<blockquote>
+-2- <i>Postconditions:</i> <tt>code() == ec</tt>
+and <tt><del>strcmp(runtime_error::what(), what_arg.c_str()) == 0</del>
+<ins>string(what()).find(what_arg) != string::npos</ins></tt>.
+</blockquote>
+
+<pre>system_error(error_code ec, const char* what_arg);
+</pre>
+<blockquote>
+-4- <i>Postconditions:</i> <tt>code() == ec</tt>
+and <tt><del>strcmp(runtime_error::what(), what_arg) == 0</del>
+<ins>string(what()).find(what_arg) != string::npos</ins></tt>.
+</blockquote>
+
+<pre>system_error(error_code ec);
+</pre>
+<blockquote>
+-6- <i>Postconditions:</i> <tt>code() == ec</tt>
+<del>and <tt>strcmp(runtime_error::what(), ""</tt></del>.
+</blockquote>
+
+<pre>system_error(int ev, const error_category& ecat, const string& what_arg);
+</pre>
+<blockquote>
+-8- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
+and <tt><del>strcmp(runtime_error::what(), what_arg.c_str()) == 0</del>
+<ins>string(what()).find(what_arg) != string::npos</ins></tt>.
+</blockquote>
+
+<pre>system_error(int ev, const error_category& ecat, const char* what_arg);
+</pre>
+<blockquote>
+-10- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
+and <tt><del>strcmp(runtime_error::what(), what_arg) == 0</del>
+<ins>string(what()).find(what_arg) != string::npos</ins></tt>.
+</blockquote>
+
+<pre>system_error(int ev, const error_category& ecat);
+</pre>
+<blockquote>
+-12- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
+<del>and <tt>strcmp(runtime_error::what(), "") == 0</tt></del>.
+</blockquote>
+
+</blockquote>
+
+<p>
+In 19.5.5.2 [syserr.syserr.members], change the description of <tt>what()</tt>:
+</p>
+
+<blockquote>
+<pre>const char *what() const throw();
+</pre>
+<blockquote>
+<p>
+-14- <i>Returns:</i> An NTBS incorporating <del><tt>runtime_error::what()</tt> and
+<tt>code().message()</tt></del> <ins>the arguments supplied in the constructor</ins>.
+</p>
+<p>
+[<i>Note:</i> <del>One possible implementation would be:</del>
+<ins>The return NTBS might take the form: <tt>what_arg + ": " + code().message()</tt></ins>
+</p>
+<blockquote><pre><del>
+if (msg.empty()) {
+ try {
+ string tmp = runtime_error::what();
+ if (code()) {
+ if (!tmp.empty())
+ tmp += ": ";
+ tmp += code().message();
+ }
+ swap(msg, tmp);
+ } catch(...) {
+ return runtime_error::what();
+ }
+return msg.c_str();
+</del></pre></blockquote>
+<p>
+— <i>end note</i>]
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+In 27.5.2.1.1 [ios::failure], change the synopsis:
+</p>
+
+<blockquote><pre>namespace std {
+ class ios_base::failure : public system_error {
+ public:
+ explicit failure(const string& msg, const error_code& ec = io_errc::stream);
+ explicit failure(const char* msg, const error_code& ec = io_errc::stream);
+ <del>virtual const char* what() const throw();</del>
+ };
+}
+</pre></blockquote>
+
+<p>
+In 27.5.2.1.1 [ios::failure], change the description of the constructors:
+</p>
+
+<blockquote>
+
+<pre>explicit failure(const string& msg, , const error_code& ec = io_errc::stream);
+</pre>
+<blockquote>
+<p>
+-3- <i>Effects:</i> Constructs an object of class <tt>failure</tt>
+<ins>by constructing the base class with <tt>msg</tt> and <tt>ec</tt></ins>.
+</p>
+<p>
+<del>-4- <i>Postcondition:</i> <tt>code() == ec</tt> and <tt>strcmp(what(), msg.c_str()) == 0</tt></del>
+</p>
+</blockquote>
+
+<pre>explicit failure(const char* msg, const error_code& ec = io_errc::stream);
+</pre>
+<blockquote>
+<p>
+-5- <i>Effects:</i> Constructs an object of class <tt>failure</tt>
+<ins>by constructing the base class with <tt>msg</tt> and <tt>ec</tt></ins>.
+</p>
+<p>
+<del>-6- <i>Postcondition:</i> <tt>code() == ec and strcmp(what(), msg) == 0</tt></del>
+</p>
+</blockquote>
+
+</blockquote>
+
+<p>
+In 27.5.2.1.1 [ios::failure], remove <tt>what</tt> (the base class definition
+need not be repeated here).
+</p>
+
+<blockquote>
+<pre><del>const char* what() const;</del>
+</pre>
+<blockquote>
+<del>-7- <i>Returns:</i> The message <tt>msg</tt> with which the exception was created.</del>
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1104"></a>1104. <tt>basic_ios::move</tt> should accept lvalues</h3>
+<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+With the rvalue reference changes in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
+<tt>basic_ios::move</tt> no longer has the most convenient signature:
+</p>
+
+<blockquote><pre>void move(basic_ios&& rhs);
+</pre></blockquote>
+
+<p>
+This signature should be changed to accept lvalues. It does not need to be
+overloaded to accept rvalues. This is a special case that only derived clients
+will see. The generic <tt>move</tt> still needs to accept rvalues.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Tom prefers, on general principles, to provide both overloads.
+Alisdair agrees.
+</p>
+<p>
+Howard points out that there is no backward compatibility issue
+as this is new to C++0X.
+</p>
+<p>
+We agree that both overloads should be provided,
+and Howard will provide the additional wording.
+Move to Open.
+</p>
+</blockquote>
+
+<p><i>[
+2009-05-23 Howard adds:
+]</i></p>
+
+
+<blockquote>
+Added overload, moved to Review.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a signature to the existing prototype in the synopsis of 27.5.4 [ios]
+and in 27.5.4.2 [basic.ios.members]:
+</p>
+
+<blockquote><pre><ins>void move(basic_ios& rhs);</ins>
+void move(basic_ios&& rhs);
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1105"></a>1105. Shouldn't <tt>Range</tt> be an <tt>auto concept</tt></h3>
+<p><b>Section:</b> 24.2.8 [iterator.concepts.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-04-23 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p><i>[
+2009-04-26 Herb adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Here's a common example: We have many ISV customers who have built lots of
+in-house STL-like containers. Imagine that, for the past ten years, the user
+has been happily using his <tt>XYZCorpContainer<T></tt> that has <tt>begin()</tt> and <tt>end()</tt>
+and an iterator typedef, and indeed satisfies nearly all of <tt>Container</tt>,
+though maybe not quite all just like <tt>valarray</tt>. The user upgrades to a
+range-enabled version of a library, and now <tt>lib_algo( xyz.begin(), xyz.end());</tt>
+no longer works -- compiler error.
+</p>
+<p>
+Even though <tt>XYZCorpContainer</tt> matches the pre-conceptized version of the
+algorithm, and has been working for years, it appears the user has to write
+at least this:
+</p>
+<blockquote><pre>template<class T> concept_map Range<XYZCorpContainer<T>> {};
+
+template<class T> concept_map Range<const XYZCorpContainer<T>> {};
+</pre></blockquote>
+<p>
+Is that correct?
+</p>
+<p>
+But he may actually have to write this as we do for initializer list:
+</p>
+<blockquote><pre>template<class T>
+concept_map Range<XYZCorpContainer<T>> {
+ typedef T* iterator;
+ iterator begin(XYZCorpContainer<T> c) { return c.begin(); }
+ iterator end(XYZCorpContainer<T> c) { return c.end(); }
+};
+
+template<class T>
+concept_map Range<const XYZCorpContainer<T>> {
+ typedef T* iterator;
+ iterator begin(XYZCorpContainer<T> c) { return c.begin(); }
+ iterator end(XYZCorpContainer<T> c) { return c.end(); }
+};
+</pre></blockquote>
+
+</blockquote>
+
+<p><i>[
+2009-04-28 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I recommend NAD, although remain concerned about header organisation.
+</p>
+<p>
+A user container will satisfy the <tt>MemberContainer</tt> concept, which IS auto.
+There is a concept_map for all <tt>MemberContainers</tt> to <tt>Container</tt>, and then a
+further concept_map for all <tt>Container</tt> to <tt>Range</tt>, so the stated problem is not
+actually true. User defined containers will automatically match the <tt>Range</tt>
+concept without explicitly declaring a concept_map.
+</p>
+<p>
+The problem is that they should now provide an additional two headers,
+<tt><iterator_concepts></tt> and <tt><container_concepts></tt>.
+ The only difference from
+making <tt>Range</tt> an auto concept would be this reduces to a single header,
+<tt><iterator_concepts></tt>.
+</p>
+<p>
+I am strongly in favour of any resolution that tackles the issue of
+explicitly requiring concept headers to make these concept maps available.
+</p>
+</blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We observe there is a recent paper by Bjarne that overlaps this issue.
+</p>
+<p>
+Alisdair continues to recommend NAD.
+</p>
+<p>
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1106"></a>1106. Multiple exceptions from connected <tt>shared_future::get()</tt>?</h3>
+<p><b>Section:</b> 30.6.5 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Thomas J. Gritzan <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#future.shared_future">active issues</a> in [future.shared_future].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+It is not clear, if multiple threads are waiting in a
+<tt>shared_future::get()</tt> call, if each will rethrow the stored exception.
+</p>
+<p>
+Paragraph 9 reads:
+</p>
+<blockquote>
+<i>Throws:</i> the stored exception, if an exception was stored and not
+retrieved before.
+</blockquote>
+<p>
+The "not retrieved before" suggests that only one exception is thrown,
+but one exception for each call to <tt>get()</tt> is needed, and multiple calls
+to <tt>get()</tt> even on the same <tt>shared_future</tt> object seem to be allowed.
+</p>
+<p>
+I suggest removing "and not retrieved before" from the Throws paragraph.
+I recommend adding a note that explains that multiple calls on <tt>get()</tt> are
+allowed, and each call would result in an exception if an exception was
+stored.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We note there is a pending paper by Detlef
+on such <tt>future</tt>-related issues;
+we would like to wait for his paper before proceeding.
+</p>
+<p>
+Alisdair suggests we may want language to clarify that this
+<tt>get()</tt> function can be called from several threads
+with no need for explicit locking.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 30.6.5 [future.shared_future]:
+</p>
+
+<blockquote><pre>const R& shared_future::get() const;
+R& shared_future<R&>::get() const;
+void shared_future<void>::get() const;
+</pre>
+<blockquote>
+<p>...</p>
+<p>
+-9- <i>Throws:</i> the stored exception, if an exception was stored<del> and not retrieved before</del>.
+<ins>
+[<i>Note:</i> Multiple calls on <tt>get()</tt> are
+allowed, and each call would result in an exception if an exception was
+stored. — <i>end note</i>]
+</ins>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1107"></a>1107. constructor <tt>shared_future(unique_future)</tt> by value?</h3>
+<p><b>Section:</b> 30.6.5 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
+ <b>Submitter:</b> Thomas J. Gritzan <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#future.shared_future">active issues</a> in [future.shared_future].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In the <tt>shared_future</tt> class definition in 30.6.5 [future.shared_future]
+the move constructor
+that constructs a <tt>shared_future</tt> from an <tt>unique_future</tt> receives the
+parameter by value. In paragraph 3, the same constructor receives it as
+const value.
+</p>
+
+<p>
+I think that is a mistake and the constructor should take a r-value
+reference:
+</p>
+
+<blockquote><pre>shared_future(unique_future<R>&& rhs);
+</pre></blockquote>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the proposed resolution.
+</p>
+<p>
+Move to Tentatively Ready.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 30.6.5 [future.shared_future]:
+</p>
+
+<blockquote><pre>shared_future(unique_future<R><ins>&&</ins> rhs);
+</pre></blockquote>
+
+<p>
+Change the definition of the constructor in 30.6.5 [future.shared_future]:
+</p>
+
+<blockquote><pre>shared_future(<del>const</del> unique_future<R><ins>&&</ins> rhs);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1108"></a>1108. thread.req.exception overly constrains implementations</h3>
+<p><b>Section:</b> 30.2.2 [thread.req.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The current formulation of 30.2.2 [thread.req.exception]/2 reads:
+</p>
+<blockquote>
+The error_category of the <tt>error_code</tt> reported by such an
+exception's <tt>code()</tt> member function is as specified in the error
+condition Clause.
+</blockquote>
+<p>
+This constraint on the code's associated <tt>error_categor</tt> means an
+implementation must perform a mapping from the system-generated
+error to a <tt>generic_category()</tt> error code. The problems with this
+include:
+</p>
+
+<ul>
+<li>
+The mapping is always performed, even if the resultant value is
+ never used.
+</li>
+<li>
+<p>
+The original error produced by the operating system is lost.
+</p>
+</li>
+</ul>
+<p>
+The latter was one of Peter Dimov's main objections (in a private
+email discussion) to the original <tt>error_code</tt>-only design, and led to
+the creation of <tt>error_condition</tt> in the first place. Specifically,
+<tt>error_code</tt> and <tt>error_condition</tt> are intended to perform the following
+roles:
+</p>
+<ul>
+<li>
+<tt>error_code</tt> holds the original error produced by the operating
+ system.
+</li>
+<li>
+<tt>error_condition</tt> and the generic category provide a set of well
+ known error constants that error codes may be tested against.
+</li>
+</ul>
+<p>
+Any mapping determining correspondence of the returned error code to
+the conditions listed in the error condition clause falls under the
+"latitude" granted to implementors in 19.5.1.5 [syserr.errcat.objects].
+(Although obviously their latitude is restricted a little by the
+need to match the right error condition when returning an error code
+from a library function.)
+</p>
+<p>
+It is important that this <tt>error_code/error_condition</tt> usage is done
+correctly for the thread library since it is likely to set the
+pattern for future TR libraries that interact with the operating
+system.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 30.2.2 [thread.req.exception]/2:
+</p>
+
+<blockquote>
+<p>
+-2- <del>The <tt>error_category</tt> (19.5.1.1) of the <tt>error_code</tt> reported by
+such an exception's <tt>code()</tt> member function
+is as specified in the error condition Clause.</del>
+<ins>
+The <tt>error_code</tt> reported by such an exception's <tt>code()</tt> member
+function shall compare equal to one of the conditions specified in
+the function's error condition Clause. [<i>Example:</i> When the thread
+constructor fails:
+</ins>
+</p>
+<blockquote><pre><ins>
+ec.category() == implementation-defined // probably system_category
+ec == errc::resource_unavailable_try_again // holds true
+</ins></pre></blockquote>
+
+<p><ins>
+— <i>end example</i>]
+</ins></p>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1109"></a>1109. <tt>std::includes</tt> should require <tt>CopyConstructible</tt> predicate</h3>
+<p><b>Section:</b> 25.5.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-28 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#includes">active issues</a> in [includes].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#includes">issues</a> in [includes].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+All the set operation algorithms require a <tt>CopyConstructible</tt> predicate, with
+the exception of <tt>std::includes</tt>. This looks like a typo as much as anything,
+given the general library requirement that predicates are copy
+constructible, and wording style of other set-like operations.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+We agree with the proposed resolution.
+Move to NAD Editorial.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 25.2 [algorithms.syn] and 25.5.5.1 [includes]:
+</p>
+
+<blockquote><pre>template<InputIterator Iter1, InputIterator Iter2,
+ <del>typename</del> <ins>CopyConstructible</ins> Compare>
+ requires Predicate<Compare, Iter1::value_type, Iter2::value_type>
+ && Predicate<Compare, Iter2::value_type, Iter1::value_type>
+ bool includes(Iter1 first1, Iter1 last1,
+ Iter2 first2, Iter2 last2,
+ Compare comp);
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1110"></a>1110. Is <tt>for_each</tt> overconstrained?</h3>
+<p><b>Section:</b> 25.3.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-29 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.foreach">active issues</a> in [alg.foreach].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Quoting working paper for reference (25.3.4 [alg.foreach]):
+</p>
+
+<blockquote>
+<pre>template<InputIterator Iter, Callable<auto, Iter::reference> Function>
+ requires CopyConstructible<Function>
+ Function for_each(Iter first, Iter last, Function f);
+</pre>
+<blockquote>
+<p>
+1 Effects: Applies f to the result of dereferencing every iterator in the
+ range [first,last), starting from first and proceeding to last - 1.
+</p>
+<p>
+2 Returns: f.
+</p>
+<p>
+3 Complexity: Applies f exactly last - first times.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+P2 implies the passed object <tt>f</tt> should be invoked at each stage, rather than
+some copy of <tt>f</tt>. This is important if the return value is to usefully
+accumulate changes. So the requirements are an object of type <tt>Function</tt> can
+be passed-by-value, invoked multiple times, and then return by value. In
+this case, <tt>MoveConstructible</tt> is sufficient. This would open support for
+move-only functors, which might become important in concurrent code as you
+can assume there are no other references (copies) of a move-only type and so
+freely use them concurrently without additional locks.
+</p>
+
+<p><i>[
+See further discussion starting with c++std-lib-23686.
+]</i></p>
+
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Pete suggests we may want to look at this in a broader context
+involving other algorithms.
+We should also consider the implications of parallelism.
+</p>
+<p>
+Move to Open, and recommend the issue be deferred until after the next
+Committee Draft is issued.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 25.2 [algorithms.syn] and 25.3.4 [alg.foreach]:
+</p>
+
+<blockquote><pre>template<InputIterator Iter, Callable<auto, Iter::reference> Function>
+ requires <del>CopyConstructible</del> <ins>MoveConstructible</ins><Function>
+ Function for_each(Iter first, Iter last, Function f);
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1111"></a>1111. associative containers underconstrained</h3>
+<p><b>Section:</b> 23.4 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-29 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative">active issues</a> in [associative].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative">issues</a> in [associative].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+According to table 87 (n2857) the expression <tt>X::key_equal</tt> for an unordered
+container shall return a value of type <tt>Pred</tt>, where <tt>Pred</tt> is an equivalence
+relation.
+</p>
+
+<p>
+However, all 4 containers constrain <tt>Pred</tt> to be merely a <tt>Predicate</tt>,
+and not <tt>EquivalenceRelation</tt>.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+We agree with the proposed resolution.
+</p>
+<p>
+Move to Review.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+For ordered containers, replace
+</p>
+<blockquote><pre>Predicate<auto, Key, Key> Compare = less<Key>
+</pre></blockquote>
+<p>
+with
+</p>
+<blockquote><pre>StrictWeakOrder<auto, Key, Key> Compare = less<Key>
+</pre></blockquote>
+
+<p>
+For unordered containers, replace
+</p>
+<blockquote><pre>Predicate<auto, Key, Key> Compare = less<Key>
+</pre></blockquote>
+<p>
+with
+</p>
+<blockquote><pre>EquivalenceRelation<auto, Key, Key> Compare = less<Key>
+</pre></blockquote>
+<p>
+As in the following declarations:
+</p>
+
+<blockquote>
+<p>
+Associative containers 23.4 [associative]
+</p>
+<p>
+ 1 Headers <map> and <set>:
+</p>
+<p>
+ Header <map> synopsis
+</p>
+<blockquote><pre> namespace std {
+ template <ValueType Key, ValueType T,
+ <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
+ Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+ requires NothrowDestructible<Key> && NothrowDestructible<T>
+ && CopyConstructible<Compare>
+ && AllocatableElement<Alloc, Compare, const Compare&>
+ && AllocatableElement<Alloc, Compare, Compare&&>
+ class map;
+
+ ...
+
+ template <ValueType Key, ValueType T,
+ <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
+ Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+ requires NothrowDestructible<Key> && NothrowDestructible<T>
+ && CopyConstructible<Compare>
+ && AllocatableElement<Alloc, Compare, const Compare&>
+ && AllocatableElement<Alloc, Compare, Compare&&>
+ class multimap;
+
+ ...
+
+ }
+</pre></blockquote>
+
+<p>
+ Header <set> synopsis
+</p>
+<blockquote><pre> namespace std {
+ template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
+ Allocator Alloc = allocator<Key> >
+ requires NothrowDestructible<Key> && CopyConstructible<Compare>
+ && AllocatableElement<Alloc, Compare, const Compare&>
+ && AllocatableElement<Alloc, Compare, Compare&&>
+ class set;
+
+ ...
+
+ template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
+ Allocator Alloc = allocator<Key> >
+ requires NothrowDestructible<Key> && CopyConstructible<Compare>
+ && AllocatableElement<Alloc, Compare, const Compare&>
+ && AllocatableElement<Alloc, Compare, Compare&&>
+ class multiset;
+
+ ...
+
+ }
+</pre></blockquote>
+
+<p>
+ 23.4.1p2 Class template map [map]
+</p>
+<blockquote><pre> namespace std {
+ template <ValueType Key, ValueType T,
+ <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
+ Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+ requires NothrowDestructible<Key> && NothrowDestructible<T>
+ && CopyConstructible<Compare>
+ && AllocatableElement<Alloc, Compare, const Compare&>
+ && AllocatableElement<Alloc, Compare, Compare&&>
+ class map {
+ ...
+ };
+ }
+</pre></blockquote>
+
+
+<p>
+ 23.4.2p2 Class template multimap [multimap]
+</p>
+<blockquote><pre> namespace std {
+ template <ValueType Key, ValueType T,
+ <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
+ Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+ requires NothrowDestructible<Key> && NothrowDestructible<T>
+ && CopyConstructible<Compare>
+ && AllocatableElement<Alloc, Compare, const Compare&>
+ && AllocatableElement<Alloc, Compare, Compare&&>
+ class multimap {
+ ...
+ };
+ }
+</pre></blockquote>
+
+
+<p>
+ 23.4.3p2 Class template set [set]
+</p>
+<blockquote><pre> namespace std {
+ template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
+ Allocator Alloc = allocator<Key> >
+ requires NothrowDestructible<Key> && CopyConstructible<Compare>
+ && AllocatableElement<Alloc, Compare, const Compare&>
+ && AllocatableElement<Alloc, Compare, Compare&&>
+ class set {
+ ...
+ };
+ }
+</pre></blockquote>
+
+
+<p>
+ 23.4.4p2 Class template multiset [multiset]
+</p>
+<blockquote><pre> namespace std {
+ template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
+ Allocator Alloc = allocator<Key> >
+ requires NothrowDestructible<Key> && CopyConstructible<Compare>
+ && AllocatableElement<Alloc, Compare, const Compare&>
+ && AllocatableElement<Alloc, Compare, Compare&&>
+ class multiset {
+ ...
+ };
+ }
+</pre></blockquote>
+
+<p>
+ 23.5 Unordered associative containers [unord]
+</p>
+<p>
+ 1 Headers <unordered_map> and <unordered_set>:
+</p>
+<p>
+ Header <unordered_map> synopsis
+</p>
+<blockquote><pre> namespace std {
+ // 23.5.1, class template unordered_map:
+ template <ValueType Key,
+ ValueType T,
+ Callable<auto, const Key&> Hash = hash<Key>,
+ <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>,
+ Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+ requires NothrowDestructible<Key> && NothrowDestructible<T>
+ && SameType<Hash::result_type, size_t>
+ && CopyConstructible<Hash> && CopyConstructible<Pred>
+ && AllocatableElement<Alloc, Pred, const Pred&>
+ && AllocatableElement<Alloc, Pred, Pred&&>
+ && AllocatableElement<Alloc, Hash, const Hash&>
+ && AllocatableElement<Alloc, Hash, Hash&&>
+ class unordered_map;
+
+ // 23.5.2, class template unordered_multimap:
+ template <ValueType Key,
+ ValueType T,
+ Callable<auto, const Key&> Hash = hash<Key>,
+ <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>,
+ Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+ requires NothrowDestructible<Key> && NothrowDestructible<T>
+ && SameType<Hash::result_type, size_t>
+ && CopyConstructible<Hash> && CopyConstructible<Pred>
+ && AllocatableElement<Alloc, Pred, const Pred&>
+ && AllocatableElement<Alloc, Pred, Pred&&>
+ && AllocatableElement<Alloc, Hash, const Hash&>
+ && AllocatableElement<Alloc, Hash, Hash&&>
+ class unordered_multimap;
+
+ ...
+ }
+</pre></blockquote>
+
+<p>
+ Header <unordered_set> synopsis
+</p>
+<blockquote><pre> namespace std {
+ // 23.5.3, class template unordered_set:
+ template <ValueType Value,
+ Callable<auto, const Value&> Hash = hash<Value>,
+ <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>,
+ Allocator Alloc = allocator<Value> >
+ requires NothrowDestructible<Value>
+ && SameType<Hash::result_type, size_t>
+ && CopyConstructible<Hash> && CopyConstructible<Pred>
+ && AllocatableElement<Alloc, Pred, const Pred&>
+ && AllocatableElement<Alloc, Pred, Pred&&>
+ && AllocatableElement<Alloc, Hash, const Hash&>
+ && AllocatableElement<Alloc, Hash, Hash&&>
+ class unordered_set;
+
+ // 23.5.4, class template unordered_multiset:
+ template <ValueType Value,
+ Callable<auto, const Value&> Hash = hash<Value>,
+ <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>,
+ Allocator Alloc = allocator<Value> >
+ requires NothrowDestructible<Value>
+ && SameType<Hash::result_type, size_t>
+ && CopyConstructible<Hash> && CopyConstructible<Pred>
+ && AllocatableElement<Alloc, Pred, const Pred&>
+ && AllocatableElement<Alloc, Pred, Pred&&>
+ && AllocatableElement<Alloc, Hash, const Hash&>
+ && AllocatableElement<Alloc, Hash, Hash&&>
+ class unordered_multiset;
+
+ ...
+ }
+</pre></blockquote>
+
+<p>
+ 23.5.1p3 Class template unordered_map [unord.map]
+</p>
+<blockquote><pre> namespace std {
+ template <ValueType Key,
+ ValueType T,
+ Callable<auto, const Key&> Hash = hash<Key>,
+ <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>,
+ Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+ requires NothrowDestructible<Key> && NothrowDestructible<T>
+ && SameType<Hash::result_type, size_t>
+ && CopyConstructible<Hash> && CopyConstructible<Pred>
+ && AllocatableElement<Alloc, Pred, const Pred&>
+ && AllocatableElement<Alloc, Pred, Pred&&>
+ && AllocatableElement<Alloc, Hash, const Hash&>
+ && AllocatableElement<Alloc, Hash, Hash&&>
+ class unordered_map
+ {
+ ...
+ };
+ }
+</pre></blockquote>
+
+<p>
+ 23.5.2p3 Class template unordered_multimap [unord.multimap]
+</p>
+<blockquote><pre> namespace std {
+ template <ValueType Key,
+ ValueType T,
+ Callable<auto, const Key&> Hash = hash<Key>,
+ <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>,
+ Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
+ requires NothrowDestructible<Key> && NothrowDestructible<T>
+ && SameType<Hash::result_type, size_t>
+ && CopyConstructible<Hash> && CopyConstructible<Pred>
+ && AllocatableElement<Alloc, Pred, const Pred&>
+ && AllocatableElement<Alloc, Pred, Pred&&>
+ && AllocatableElement<Alloc, Hash, const Hash&>
+ && AllocatableElement<Alloc, Hash, Hash&&>
+ class unordered_multimap
+ {
+ ...
+ };
+ }
+</pre></blockquote>
+
+<p>
+ 23.5.3p3 Class template unordered_set [unord.set]
+</p>
+<blockquote><pre> namespace std {
+ template <ValueType Value,
+ Callable<auto, const Value&> Hash = hash<Value>,
+ <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>,
+ Allocator Alloc = allocator<Value> >
+ requires NothrowDestructible<Value>
+ && SameType<Hash::result_type, size_t>
+ && CopyConstructible<Hash> && CopyConstructible<Pred>
+ && AllocatableElement<Alloc, Pred, const Pred&>
+ && AllocatableElement<Alloc, Pred, Pred&&>
+ && AllocatableElement<Alloc, Hash, const Hash&>
+ && AllocatableElement<Alloc, Hash, Hash&&>
+ class unordered_set
+ {
+ ...
+ };
+ }
+</pre></blockquote>
+<p>
+ 23.5.4p3 Class template unordered_multiset [unord.multiset]
+</p>
+<blockquote><pre> namespace std {
+ template <ValueType Value,
+ Callable<auto, const Value&> Hash = hash<Value>,
+ <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>,
+ Allocator Alloc = allocator<Value> >
+ requires NothrowDestructible<Value>
+ && SameType<Hash::result_type, size_t>
+ && CopyConstructible<Hash> && CopyConstructible<Pred>
+ && AllocatableElement<Alloc, Pred, const Pred&>
+ && AllocatableElement<Alloc, Pred, Pred&&>
+ && AllocatableElement<Alloc, Hash, const Hash&>
+ && AllocatableElement<Alloc, Hash, Hash&&>
+ class unordered_multiset
+ {
+ ...
+ };
+ }
+</pre></blockquote>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1112"></a>1112. bitsets and new style for loop</h3>
+<p><b>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-06 <b>Last modified:</b> 2009-05-25</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>Std::bitset</tt> is a homogeneous container-like sequence of bits, yet it does
+not model the Range concept so cannot be used with the new for-loop syntax.
+It is the only such type in the library that does NOT support the new for
+loop.
+</p>
+<p>
+The obvious reason is that bitset does not support iterators.
+</p>
+<p>
+At least two reasonable solutions are available:
+</p>
+<ol type="i">
+<li>
+Add an iterator interface to <tt>bitset</tt>, bringing its interface close to that
+of <tt>std::array</tt>
+</li>
+<li>
+Provide an unspecified concept_map for <tt>Range<bitset></tt>.
+</li>
+</ol>
+<p>
+The latter will still need some kind of iterator-like adapter for <tt>bitset</tt>,
+but gives implementers greater freedom on the details. E.g. begin/end return
+some type that simply invokes <tt>operator[]</tt> on the object it wraps, and
+increments its index on <tt>operator++</tt>. A vendor can settle for <tt>InputIterator</tt>
+support, rather than wrapping up a full <tt>RandomAccessIterator</tt>.
+</p>
+<p>
+I have a mild preference for option (ii) as I think it is less work to
+specify at this stage of the process, although (i) is probably more useful
+in the long run.
+</p>
+<p>
+Hmm, my wording looks a little woolly, as it does not say what the element
+type of the range is. Do I get a range of <tt>bool</tt>, <tt>bitset<N>::reference</tt>, or
+something else entirely?
+</p>
+<p>
+I guess most users will assume the behaviour of reference, but expect to
+work with <tt>bool</tt>. <tt>Bool</tt> is OK for read-only traversal, but you really need to
+take a reference to a <tt>bitset::reference</tt> if you want to write back.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open.
+We further recommend this be deferred until after the next Committee Draft.
+</blockquote>
+
+<p><i>[
+2009-05-25 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I just stumbled over the <tt>Range concept_map</tt> for <tt>valarray</tt> and this should
+probably set the precedent on how to write the wording.
+</p>
+
+<p><i>[
+Howard: I've replaced the proposed wording with Alisdair's suggestion.
+]</i></p>
+
+
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+20.3.6.X bitset concept maps [bitset.concepts] (made up clause name/number)
+</p>
+<pre>template<size_t N>
+concept_map Range<bitset<N>> {
+ typedef unspecified iterator;
+ iterator begin(bitset<N>& a);
+ iterator end(bitset<N>& a);
+}
+
+template<typename T>
+concept_map Range<const bitset<N>> {
+ typedef unspecified iterator;
+ iterator begin(const bitset<N>& a);
+ iterator end(const bitset<N>& a);
+}
+</pre>
+<p>
+-1- <i>Note:</i> these concept_maps adapt <tt>bitset</tt> to the <tt>Range</tt> concept.
+</p>
+
+<pre>typedef <i>unspecified</i> iterator;
+</pre>
+
+<blockquote>
+-2- <i>Requires:</i> <tt>iterator</tt> shall meet the requirements of the
+<tt>RandomAccessIterator</tt> concept and <tt>iterator::reference</tt>
+shall equal <tt>bitset<N>::reference</tt> or <tt>const bitset<N>::reference</tt>.
+</blockquote>
+
+<pre>iterator begin(bitset<N>& a);
+iterator begin(const bitset<N>& a);
+</pre>
+
+<blockquote>
+-3- <i>Returns:</i> an <tt>iterator</tt> referencing the first bit in the <tt>bitset</tt>.
+</blockquote>
+
+<pre>iterator end(bitset<N>& a);
+iterator end(const bitset<N>& a);
+</pre>
+
+<blockquote>
+-4- <i>Returns:</i> an <tt>iterator</tt> referencing one past the last bit in the <tt>bitset</tt>.
+</blockquote>
+
+
+
+
+
+
+
+
+
+
+<hr>
+<h3><a name="1113"></a>1113. <tt>bitset::to_string</tt> could be simplified</h3>
+<p><b>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a> our resolution is changing the signature by adding two
+defaulting arguments to 3 calls. In principle, this means that ABI breakage
+is not an issue, while API is preserved.
+</p>
+<p>
+With that observation, it would be very nice to use the new ability to
+supply default template parameters to function templates to collapse all 3
+signatures into 1. In that spirit, this issue offers an alternative resolution
+than that of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>.
+</p>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+Move to Open,
+and look at the issue again after <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a> has been accepted.
+We further recommend this be deferred until after the next Committee Draft.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<ol type="A">
+<li>
+<p>
+In 20.3.6 [template.bitset]/1 (class bitset) ammend:
+</p>
+<blockquote><pre>template <class charT <ins>= char</ins>,
+ class traits <ins>= char_traits<charT></ins>,
+ class Allocator <ins>= allocator<charT></ins>>
+ basic_string<charT, traits, Allocator>
+ to_string(charT zero = charT('0'), charT one = charT('1')) const;
+<del>template <class charT, class traits>
+ basic_string<charT, traits, allocator<charT> > to_string() const;
+template <class charT>
+ basic_string<charT, char_traits<charT>, allocator<charT> > to_string() const;
+basic_string<char, char_traits<char>, allocator<char> > to_string() const;</del>
+</pre></blockquote>
+</li>
+<li>
+<p>
+In 20.3.6.2 [bitset.members] prior to p35 ammend:
+</p>
+<blockquote><pre>template <class charT <ins>= char</ins>,
+ class traits <ins>= char_traits<charT></ins>,
+ class Allocator <ins>= allocator<charT></ins>>
+ basic_string<charT, traits, Allocator>
+ to_string(charT zero = charT('0'), charT one = charT('1')) const;
+</pre></blockquote>
+</li>
+<li>
+Strike 20.3.6.2 [bitset.members] paragraphs 37 -> 39 (including signature
+above 37)
+</li>
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="1114"></a>1114. Type traits underspecified</h3>
+<p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-05-12 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+
+<p>
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>.
+</p>
+
+<p>
+The current wording in 20.6.1 [meta.rqmts] is still unclear concerning
+it's requirements on the type traits classes regarding ambiguities.
+Specifically it's unclear
+</p>
+
+<ul>
+<li>
+if a predicate trait (20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from both
+<tt>true_type</tt>/<tt>false_type</tt>.
+</li>
+<li>
+if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could ambiguously derive
+from the same specified result type.
+</li>
+<li>
+if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from other
+<tt>integral_constant</tt> types making the contained names ambiguous
+</li>
+<li>
+if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could have other base
+classes that contain members hiding the name of the result type members
+or make the contained member names ambiguous.
+</li>
+</ul>
+
+<p><i>[
+Batavia (2009-05):
+]</i></p>
+
+<blockquote>
+<p>
+Alisdair would prefer to factor some of the repeated text,
+but modulo a corner case or two,
+he believes the proposed wording is otherwise substantially correct.
+</p>
+<p>
+Move to Open.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p><i>[
+The usage of the notion of a <i>BaseCharacteristic</i> below
+might be
+useful in other places - e.g. to define the base class relation in
+20.7.5 [refwrap], 20.7.15 [func.memfn], or 20.7.16.2 [func.wrap.func].
+In this case it's definition should probably
+be moved to Clause 17
+]</i></p>
+
+
+<ol>
+<li>
+<p>
+Change 20.6.1 [meta.rqmts]/1 as indicated:
+</p>
+<blockquote>
+[..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
+<ins>and unambiguously</ins> derived, directly or indirectly, from
+<ins>its <i>BaseCharacteristic</i>, which is</ins> a specialization of the
+template <tt>integral_constant</tt> (20.6.3), with the arguments to the template
+<tt>integral_constant</tt> determined by the requirements for the particular
+property being described. <ins>The member names of the
+<i>BaseCharacteristic</i> shall be unhidden and unambiguously
+available in the <i>UnaryTypeTrait</i>.</ins>
+</blockquote>
+</li>
+<li>
+<p>
+Change 20.6.1 [meta.rqmts]/2 as indicated:
+</p>
+<blockquote>
+[..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
+<ins>and unambiguously</ins> derived, directly or indirectly, from
+<del>an instance</del> <ins>its <i>BaseCharacteristic</i>, which is a
+specialization</ins> of the template <tt>integral_constant</tt> (20.6.3), with
+the arguments to the template <tt>integral_constant</tt> determined by the
+requirements for the particular relationship being described. <ins>The
+member names of the <i>BaseCharacteristic</i> shall be unhidden
+and unambiguously available in the <i>BinaryTypeTrait</i>.</ins>
+</blockquote>
+</li>
+<li>
+<p>
+Change 20.6.4 [meta.unary]/2 as indicated:
+</p>
+<blockquote>
+Each of these templates shall be a <i>UnaryTypeTrait</i> (20.6.1),
+<del>publicly derived directly or indirectly from <tt>true_type</tt> if the
+corresponding condition is true, otherwise from <tt>false_type</tt></del>
+<ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
+corresponding condition is true, otherwise <tt>false_type</tt></ins>.
+</blockquote>
+</li>
+<li>
+<p>
+Change 20.6.5 [meta.rel]/2 as indicated:
+</p>
+
+<blockquote>
+Each of these templates shall be a <i>BinaryTypeTrait</i> (20.6.1),
+<del>publicly derived directly or indirectly from <tt>true_type</tt> if the
+corresponding condition is true, otherwise from <tt>false_type</tt></del>
+<ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
+corresponding condition is true, otherwise <tt>false_type</tt></ins>.
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="1115"></a>1115. <tt>va_copy</tt> missing from Standard macros table</h3>
+<p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Miles Zhao <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.library].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In "Table 122 -- Standard macros" of C.2 [diff.library], which lists the 56 macros
+inherited from C library, <tt>va_copy</tt> seems to be missing. But in
+"Table 21 -- Header <tt><cstdarg></tt> synopsis" (18.10 [support.runtime]), there is.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add <tt>va_copy</tt> to Table 122 -- Standard macros in C.2 [diff.library].
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1116"></a>1116. Literal constructors for tuple</h3>
+<p><b>Section:</b> 20.5.2 [tuple.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-24</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.tuple">active issues</a> in [tuple.tuple].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+It is not currently possible to construct <tt>tuple</tt> literal values,
+even if the elements are all literal types. This is because parameters
+are passed to constructor by reference.
+</p>
+<p>
+An alternative would be to pass all constructor arguments by value, where it
+is known that *all* elements are literal types. This can be determined with
+concepts, although note that the negative constraint really requires
+factoring out a separate concept, as there is no way to provide an 'any of
+these fails' constraint inline.
+</p>
+<p>
+Note that we will have similar issues with <tt>pair</tt> (and
+<tt>tuple</tt> constructors from <tt>pair</tt>) although I am steering
+clear of that class while other constructor-related issues settle.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Ammend the tuple class template declaration in 20.5.2 [tuple.tuple] as
+follows
+</p>
+
+<blockquote>
+<p>
+Add the following concept:
+</p>
+
+<blockquote><pre>auto concept AllLiteral< typename ... Types > {
+ requires LiteralType<Types>...;
+}
+</pre></blockquote>
+
+<p>
+ammend the constructor
+</p>
+
+<blockquote><pre><ins>template <class... UTypes>
+ requires AllLiteral<Types...>
+ && Constructible<Types, UTypes>...
+ explicit tuple(UTypes...);</ins>
+
+template <class... UTypes>
+ requires <ins>!AllLiteral<Types...></ins>
+ <ins>&&</ins> Constructible<Types, UTypes&&>...
+ explicit tuple(UTypes&&...);
+</pre></blockquote>
+
+<p>
+ammend the constructor
+</p>
+
+<blockquote><pre><ins>template <class... UTypes>
+ requires AllLiteral<Types...>
+ && Constructible<Types, UTypes>...
+ tuple(tuple<UTypes...>);</ins>
+
+template <class... UTypes>
+ requires <ins>!AllLiteral<Types...></ins>
+ <ins>&&</ins> Constructible<Types, const UTypes&>...
+ tuple(const tuple<UTypes...>&);
+</pre></blockquote>
+
+</blockquote>
+
+<p>
+Update the same signatures in 20.5.2.1 [tuple.cnstr], paras 3 and 5.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1117"></a>1117. tuple copy constructor</h3>
+<p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The copy constructor for the <tt>tuple</tt> template is constrained. This seems an
+unusual strategy, as the copy constructor will be implicitly deleted if the
+constraints are not met. This is exactly the same effect as requesting an
+<tt>=default;</tt> constructor. The advantage of the latter is that it retains
+triviality, and provides support for <tt>tuple</tt>s as literal types if issue
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a> is also accepted.
+</p>
+<p>
+Actually, it might be worth checking with core if a constrained copy
+constructor is treated as a constructor template, and as such does not
+suppress the implicit generation of the copy constructor which would hide
+the template in this case.
+</p>
+
+<p><i>[
+2009-05-27 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+This would solve one half of the suggested changes in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.5.2 [tuple.tuple] and 20.5.2.1 [tuple.cnstr] p4:
+</p>
+
+<blockquote><pre><del>requires CopyConstructible<Types>...</del> tuple(const tuple&)<ins> = default</ins>;
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1118"></a>1118. tuple query APIs do not support cv-qualification</h3>
+<p><b>Section:</b> 20.5.2.3 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-25</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The APIs <tt>tuple_size</tt> and <tt>tuple_element</tt> do not support
+cv-qualified <tt>tuple</tt>s, <tt>pair</tt>s or <tt>array</tt>s.
+</p>
+<p>
+The most generic solution would be to supply partial specializations once
+for each cv-type in the <tt>tuple</tt> header. However, requiring this header for
+cv-qualified <tt>pair</tt>s/<tt>array</tt>s seems unhelpful. The BSI editorial
+suggestion (UK-198/US-69,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2533.html">N2533</a>)
+to merge <tt>tuple</tt> into <tt><utility></tt> would help with <tt>pair</tt>,
+but not <tt>array</tt>. That might be resolved by making a dependency between the
+<tt><array></tt> header and <tt><utility></tt>, or simply recognising
+the dependency be fulfilled in a Remark.
+</p>
+
+<p><i>[
+2009-05-24 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+All <tt>tuple_size</tt> templates with a base class need to derive publicly, e.g.
+</p>
+
+<blockquote><pre>template <IdentityOf T> class tuple_size< const T > :
+ <ins>public</ins> tuple_size<T> {};
+</pre></blockquote>
+
+<p>
+The same applies to the tuple_element class hierarchies.
+</p>
+<p>
+What is actually meant with the comment
+</p>
+<blockquote>
+this solution relies on 'metafunction forwarding' to inherit the
+nested typename type
+</blockquote>
+<p>
+?
+</p>
+<p>
+I ask, because all base classes are currently unconstrained and their
+instantiation is invalid in the constrained context of the <tt>tuple_element</tt> partial
+template specializations.
+</p>
+</blockquote>
+
+<p><i>[
+2009-05-24 Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I think a better solution might be to ask Pete editorially to change all
+declarations of tupling APIs to use the struct specifier instead of class.
+</p>
+<p>
+"metafunction forwarding" refers to the MPL metafunction protocol, where a
+metafunction result is declared as a nested typedef with the name "type",
+allowing metafunctions to be chained by means of inheritance. It is a
+neater syntax than repeatedly declaring a typedef, and inheritance syntax is
+slightly nicer when it comes to additional typename keywords.
+</p>
+<p>
+The constrained template with an unconstrained base is a good observation
+though.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to 20.5.1 [tuple.general] p2 (Header <tt><tuple></tt> synopsis)
+</p>
+
+<blockquote><pre>// 20.5.2.3, tuple helper classes:
+template <IdentityOf T> class tuple_size; // undefined
+<ins>template <IdentityOf T> class tuple_size< const T > : tuple_size<T> {};</ins>
+<ins>template <IdentityOf T> class tuple_size< volatile T > : tuple_size<T> {};</ins>
+<ins>template <IdentityOf T> class tuple_size< const volatile T > : tuple_size<T> {};</ins>
+
+template <VariableType... Types> class tuple_size<tuple<Types...> >;
+
+template <size_t I, IdentityOf T> class tuple_element; // undefined
+<ins>template <size_t I, IdentityOf T> class tuple_element<I, const T>;</ins>
+<ins>template <size_t I, IdentityOf T> class tuple_element<I, volatile T>;</ins>
+<ins>template <size_t I, IdentityOf T> class tuple_element<I, const volatile T>;</ins>
+
+template <size_t I, VariableType... Types>
+ requires True<(I < sizeof...(Types))> class tuple_element<I, tuple<Types...> >;
+</pre></blockquote>
+
+<p>
+Add to 20.5.2.3 [tuple.helper]
+</p>
+<p><i>[
+(note that this solution relies on 'metafunction forwarding' to inherit the
+nested typename type)
+]</i></p>
+
+
+<blockquote><pre>template <class... Types>
+class tuple_size<tuple<Types...> >
+ : public integral_constant<size_t, sizeof...(Types)> { };
+
+template <size_t I, class... Types>
+requires True<(I < sizeof...(Types))>
+class tuple_element<I, tuple<Types...> > {
+public:
+ typedef TI type;
+};
+
+<ins>template <size_t I, IdentityOf T>
+ class tuple_element<I, const T> : add_const<tuple_element<I,T>> {};</ins>
+
+<ins>template <size_t I, IdentityOf T>
+ class tuple_element<I, volatile T> : add_volatile<tuple_element<I,T>> {};</ins>
+
+<ins>template <size_t I, IdentityOf T>
+ class tuple_element<I, const volatile T> : add_cv<tuple_element<I,T>> {};</ins>
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1119"></a>1119. tuple query APIs do not support references</h3>
+<p><b>Section:</b> 20.5.2.3 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-24</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The <tt>tuple</tt> query APIs <tt>tuple_size</tt> and
+<tt>tuple_element</tt> do not support references-to-tuples. This can be
+annoying when a template deduced a parameter type to be a reference,
+which must be explicitly stripped with <tt>remove_reference</tt> before calling
+these APIs.
+</p>
+<p>
+I am not proposing a resolution at this point, as there is a
+combinatorial explosion with lvalue/rvalue references and
+cv-qualification (see previous issue) that suggests some higher
+refactoring is in order. This might be something to kick back over to
+Core/Evolution.
+</p>
+<p>
+Note that we have the same problem in numeric_limits.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1120"></a>1120. New type trait - remove_all</h3>
+<p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-24</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Sometimes it is necessary to remove all qualifiers from a type before
+passing on to a further API. A good example would be calling the
+<tt>tuple</tt> query APIs <tt>tuple_size</tt> or <tt>tuple_element</tt>
+with a deduced type inside a function template. If the deduced type is
+cv-qualified or a reference then the call will fail. The solution is to
+chain calls to
+<tt>remove_cv<remove_reference<T>::type>::type</tt>, and
+note that the order matters.
+</p>
+<p>
+Suggest it would be helpful to add a new type trait,
+<tt>remove_all</tt>, that removes all top-level qualifiers from a type
+i.e. cv-qualification and any references. Define the term in such a way
+that if additional qualifiers are added to the language, then
+<tt>remove_all</tt> is defined as stripping those as well.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1121"></a>1121. Support for multiple arguments</h3>
+<p><b>Section:</b> 20.4.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25 <b>Last modified:</b> 2009-05-25</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.arithmetic">active issues</a> in [ratio.arithmetic].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.arithmetic">issues</a> in [ratio.arithmetic].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Both add and multiply could sensibly be called with more than two arguments.
+The variadic template facility makes such declarations simple, and is likely
+to be frequently wrapped by end users if we do not supply the variant
+ourselves.
+</p>
+<p>
+We deliberately ignore divide at this point as it is not transitive.
+Likewise, subtract places special meaning on the first argument so I do not
+suggest extending that immediately. Both could be supported with analogous
+wording to that for add/multiply below.
+</p>
+<p>
+Note that the proposed resolution is potentially incompatible with that
+proposed for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, although the addition of the typedef to ratio would be
+equally useful.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p><i>[
+note that this wording relies on 'metafunction forwarding' as described by
+Boost MPL
+]</i></p>
+
+
+<p>
+20.4 [ratio] p3 synopsis: change
+</p>
+
+<blockquote><pre>// ratio arithmetic
+template <class R1, class R2<ins>, class ... RList</ins>> struct ratio_add;
+template <class R1, class R2> struct ratio_subtract;
+template <class R1, class R2<ins>, class ... RList</ins>> struct ratio_multiply;
+template <class R1, class R2> struct ratio_divide;
+</pre></blockquote>
+
+<p>
+20.4.2 [ratio.arithmetic] p1: change
+</p>
+
+<blockquote><pre><ins>template <class R1, class R2, class ... RList> struct ratio_add
+ : ratio_add< R1, ratio_add<R2, RList...>> {
+};</ins>
+
+template <class R1, class R2> struct ratio_add<ins><R1, R2></ins> {
+ typedef <i>see below</i> type;
+};
+</pre></blockquote>
+
+
+<p>
+20.4.2 [ratio.arithmetic] p3: change
+</p>
+
+<blockquote><pre><ins>template <class R1, class R2, class ... RList> struct ratio_multiply
+ : ratio_multiply< R1, ratio_ multiply <R2, RList...>> {
+};</ins>
+
+template <class R1, class R2> struct ratio_ multiply<ins><R1, R2></ins> {
+ typedef <i>see below</i> type;
+};
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1122"></a>1122. Ratio values should be constexpr</h3>
+<p><b>Section:</b> 20.4.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25 <b>Last modified:</b> 2009-05-25</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.ratio">active issues</a> in [ratio.ratio].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The values <tt>num</tt> and <tt>den</tt> in the <tt>ratio</tt> template
+should be declared <tt>constexpr</tt>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+20.4.1 [ratio.ratio]
+</p>
+
+<blockquote><pre>namespace std {
+ template <intmax_t N, intmax_t D = 1>
+ class ratio {
+ public:
+ static const<ins>expr</ins> intmax_t num;
+ static const<ins>expr</ins> intmax_t den;
+ };
+}
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1123"></a>1123. no requirement that standard streams be flushed</h3>
+<p><b>Section:</b> 27.5.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> James Kanze <b>Opened:</b> 2009-05-14 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ios::Init">active issues</a> in [ios::Init].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::Init">issues</a> in [ios::Init].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+As currently formulated, the standard doesn't require that there
+is ever a flush of <tt>cout</tt>, etc. (This implies, for example, that
+the classical hello, world program may have no output.) In the
+current draft
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>),
+there is a requirement that the objects
+be constructed before <tt>main</tt>, and before the dynamic
+initialization of any non-local objects defined after the
+inclusion of <tt><iostream></tt> in the same translation unit. The only
+requirement that I can find concerning flushing, however, is in
+27.5.2.1.6 [ios::Init], where the destructor of the last
+<tt>std::ios_base::Init</tt> object flushes. But there is, as far as I
+can see, no guarantee that such an object ever exists.
+</p>
+<p>
+Also, the wording in [iostreams.objects] says that:
+</p>
+<blockquote>
+The objects
+are constructed and the associations are established at some
+time prior to or during the first time an object of class
+<tt>ios_base::Init</tt> is constructed, and in any case before the body
+of main begins execution.
+</blockquote>
+<p>
+In 27.5.2.1.6 [ios::Init], however, as an
+effect of the constructor, it says that
+</p>
+<blockquote>
+If <tt>init_cnt</tt> is zero,
+the function stores the value one in <tt>init_cnt</tt>, then constructs
+and initializes the objects <tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt>
+<tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>"
+</blockquote>
+
+<p>
+which seems to forbid earlier
+construction.
+</p>
+
+<p>
+(Note that with these changes, the exposition only "<tt>static
+int init_cnt</tt>" in <tt>ios_base::Init</tt> can be dropped.)
+</p>
+<p>
+Of course, a determined programmer can still inhibit the
+flush with things like:
+</p>
+<blockquote><pre>new std::ios_base::Init ; // never deleted
+</pre></blockquote>
+<p>
+or (in a function):
+</p>
+<blockquote><pre>std::ios_base::Init ensureConstruction ;
+// ...
+exit( EXIT_SUCCESS ) ;
+</pre></blockquote>
+<p>
+Perhaps some words somewhere to the effect that all
+<tt>std::ios_base::Init</tt> objects should have static lifetime
+would be in order.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 27.4 [iostream.objects]/2:
+</p>
+
+<blockquote>
+-2- The objects are constructed and the associations are established at
+some time prior to or during the first time an object of class
+<tt>ios_base::Init</tt> is constructed, and in any case before the body
+of main begins execution.<sup>292</sup> The objects are not destroyed
+during program execution.<sup>293</sup>
+<del>If a translation unit includes
+<tt><iostream></tt> or explicitly constructs an
+<tt>ios_base::Init</tt> object, these stream objects shall be
+constructed before dynamic initialization of non-local objects defined
+later in that translation unit.</del>
+<ins>The results of including <tt><iostream></tt> in a translation
+unit shall be as if <tt><iostream></tt> defined an instance of
+<tt>ios_base::Init</tt> with static lifetime. Similarly, the entire
+program shall behave as if there were at least one instance of
+<tt>ios_base::Init</tt> with static lifetime.</ins>
+</blockquote>
+
+<p>
+Change 27.5.2.1.6 [ios::Init]/3:
+</p>
+
+<blockquote>
+<pre>Init();
+</pre>
+<blockquote>
+-3- <i>Effects:</i> Constructs an object of class <tt>Init</tt>.
+<del>If <tt>init_cnt</tt> is zero, the function stores the value one in
+<tt>init_cnt</tt>, then constructs and initializes the objects
+<tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> (27.4.1),
+<tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>
+(27.4.2). In any case, the function then adds one to the value stored in
+<tt>init_cnt</tt>.</del>
+<ins>Constructs and initializes the objects <tt>cin</tt>, <tt>cout</tt>,
+<tt>cerr</tt>, <tt>clog</tt>, <tt>wcin</tt>, <tt>wcout</tt>,
+<tt>wcerr</tt> and <tt>wclog</tt> if they have not already been
+constructed and initialized.</ins>
+</blockquote>
+</blockquote>
+
+<p>
+Change 27.5.2.1.6 [ios::Init]/4:
+</p>
+
+<blockquote>
+<pre>~Init();
+</pre>
+<blockquote>
+-4- <i>Effects:</i> Destroys an object of class <tt>Init</tt>.
+<del>The function subtracts one from the value stored in <tt>init_cnt</tt> and,
+if the resulting stored value is one,</del>
+<ins>If there are no other instances of the class still in
+existance,</ins>
+calls <tt>cout.flush()</tt>,
+<tt>cerr.flush()</tt>, <tt>clog.flush()</tt>, <tt>wcout.flush()</tt>,
+<tt>wcerr.flush()</tt>, <tt>wclog.flush()</tt>.
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1124"></a>1124. Invalid definition of concept RvalueOf</h3>
+<p><b>Section:</b> 20.2.1 [concept.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#concept.transform">active issues</a> in [concept.transform].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.transform">issues</a> in [concept.transform].</p>
+<p><b>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 recent news group
+<a href="http://groups.google.de/group/comp.std.c++/browse_frm/thread/8eb92768a19fb46f">article</a>
+points to several defects in the
+specification of reference-related concepts.
+</p>
+<p>
+One problem of the concept <tt>RvalueOf</tt> as currently defined in
+20.2.1 [concept.transform]:
+</p>
+
+<blockquote><pre>concept RvalueOf<typename T> {
+ typename type = T&&;
+ requires ExplicitlyConvertible<T&,type> && Convertible<T&&,type>;
+}
+
+template<typename T> concept_map RvalueOf<T&> {
+ typedef T&& type;
+}
+</pre></blockquote>
+
+<p>
+is that if <tt>T</tt> is an lvalue-reference, the requirement
+<tt>Convertible<T&&,type></tt> isn't satisfied for
+lvalue-references, because after reference-collapsing in the concept
+definition we have <tt>Convertible<T&,type></tt> in this case,
+which isn't satisfied in the concept map template and also is not the
+right constraint either. I think that the reporter is right that
+<tt>SameType</tt> requirements should do the job and that we also should
+use the new <tt>RvalueReference</tt> concept to specify a best matching
+type requirement.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.2.1 [concept.transform] before p. 4 change as indicated:
+</p>
+
+<blockquote><pre>auto concept RvalueOf<typename T> {
+ <del>typename</del><ins>RvalueReference</ins> type = T&&;
+ requires <del>ExplicitlyConvertible<T&, type> && Convertible<T&&, type></del><ins>SameType<T&, type&></ins>;
+}
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1125"></a>1125. ostream_iterator does not work with movable types</h3>
+<p><b>Section:</b> 24.6.2.2 [ostream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>ostream_iterator</tt> has not been updated to support moveable types, in a
+similar manner to the insert iterators.
+Note that this is not a problem for <tt>ostreambuf_iterator</tt>, as the types it is
+restricted to dealing with do not support extra-efficient moving.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add second <tt>operator=</tt> overload to class <tt>template ostream_iterator</tt>
+in 24.6.2 [ostream.iterator], para 2:
+</p>
+
+<blockquote><pre>ostream_iterator<T,charT,traits>& operator=(const T& value);
+<ins>ostream_iterator<T,charT,traits>& operator=(T&& value);</ins>
+</pre></blockquote>
+
+<p>
+Add a new paragraph: in 24.6.2.2 [ostream.iterator.ops]:
+</p>
+
+<blockquote>
+<pre>ostream_iterator& operator=(T&& value);
+</pre>
+<blockquote>
+<p>
+-2- <i>Effects:</i>
+</p>
+<blockquote><pre>*out_stream << std::move(value);
+if(delim != 0)
+ *out_stream << delim;
+return (*this);
+</pre></blockquote>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1126"></a>1126. <tt>istreambuff_iterator::equal</tt> needs a const & parameter</h3>
+<p><b>Section:</b> 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istreambuf.iterator::equal">active issues</a> in [istreambuf.iterator::equal].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator::equal">issues</a> in [istreambuf.iterator::equal].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The <tt>equal</tt> member function of <tt>istreambuf_iterator</tt> is
+declared <tt>const</tt>, but takes its argument by non-const reference.
+</p>
+<p>
+This is not compatible with the <tt>operator==</tt> free function overload, which is
+defined in terms of calling <tt>equal</tt> yet takes both arguments by reference to
+const.
+</p>
+
+<p><i>[
+The proposed wording is consistent with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a> with status TC1.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Ammend in both:<br>
+24.6.3 [istreambuf.iterator]<br>
+24.6.3.5 [istreambuf.iterator::equal]<br>
+</p>
+
+<blockquote><pre>bool equal(<ins>const </ins>istreambuf_iterator& b) const;
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1127"></a>1127. rvalue references and iterator traits</h3>
+<p><b>Section:</b> D.10.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.traits">issues</a> in [iterator.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>
+The deprecated support for <tt>iterator_traits</tt> and legacy (unconstrained)
+iterators features the (exposition only) concept:
+</p>
+
+<blockquote><pre>concept IsReference<typename T> { } // exposition only
+template<typename T> concept_map IsReference<T&> { }
+</pre></blockquote>
+<p>
+Now this looks exactly like the <tt>LvalueReference</tt> concept recently added to
+clause 20, so I wonder if we should use that instead?
+Then I consider the lack of rvalue-reference support, which means that
+<tt>move_iterator</tt> would always flag as merely supporting the <tt>input_iterator_tag</tt>
+category. This suggests we retain the exposition concept, but add a second
+concept_map to support rvalue references.
+</p>
+<p>
+I would suggest adding the extra concept_map is the right way forward, but
+still wonder if the two exposition-only concepts in this clause might be
+worth promoting to clause 20. That question might better be answered with a
+fuller investigation of type_trait/concept unification though.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In Iterator traits D.10.1 [iterator.traits] para 4 add:
+</p>
+
+<blockquote><pre>concept IsReference<typename T> { } // exposition only
+template<typename T> concept_map IsReference<T&> { }
+<ins>template<typename T> concept_map IsReference<T&&> { }</ins>
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1128"></a>1128. Missing definition of <tt>iterator_traits<T*></tt></h3>
+<p><b>Section:</b> 24.3 [iterator.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The <tt><iterator></tt> header synopsis declares a partial specialization of
+<tt>iterator_traits</tt> to support pointers, 24.3 [iterator.syn]. The implication
+is that specialization will be described in D10, yet it did not follow the
+rest of the deprecated material into this clause.
+</p>
+<p>
+However, this is not as bad as it first seems!
+There are partial specializations of <tt>iterator_traits</tt> for types that satisfy
+the various Iterator concepts, and there are concept_maps for pointers to
+explicitly support the <tt>RandomAccessIterator</tt> concept, so the required
+template will be present - just not in the manner advertised.
+</p>
+<p>
+I can see two obvious solutions:
+</p>
+
+<ol type="i">
+<li>
+Restore the <tt>iterator_traits<T*></tt> partial specialization in D.10
+</li>
+<li>
+Remove the declaration of <tt>iterator_traits<T*></tt> from 24.3 synopsis
+</li>
+</ol>
+<p>
+I recommend option (ii) in the wording below
+</p>
+<p>
+Option (ii) could be extended to strike all the declarations of deprecated
+material from the synopsis, as it is effectively duplicating D.10 anyway.
+This is the approach taken for deprecated library components in the 98/03
+standards. This is probably a matter best left to the Editor though.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 24.3 [iterator.syn] strike:
+</p>
+
+<blockquote><pre><del>template<class T> struct iterator_traits<T*>;</del>
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="1129"></a>1129. <tt>istream(buf)_iterator</tt> should support literal sentinel value</h3>
+<p><b>Section:</b> 24.6.1.1 [istream.iterator.cons], 24.6.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-30 <b>Last modified:</b> 2009-06-09</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>istream_iterator</tt> and <tt>istreambuf_iterator</tt> should support literal sentinel
+values. The default constructor is frequently used to terminate ranges, and
+could easily be a literal value for <tt>istreambuf_iterator</tt>, and
+<tt>istream_iterator</tt> when iterating value types. A little more work using a
+suitably sized/aligned char-array for storage (or an updated component like
+<tt>boost::optional</tt> proposed for TR2) would allow <tt>istream_iterator</tt> to support
+<tt>constexpr</tt> default constructor in all cases, although we might leave this
+tweak as a QoI issue. Note that requiring <tt>constexpr</tt> be supported also
+allows us to place no-throw guarantees on this constructor too.
+</p>
+
+<p><i>[
+2009-06-02 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I agree with the usefulness of the issue suggestion, but we need
+to ensure that <tt>istream_iterator</tt> <em>can</em> satisfy be literal if needed.
+Currently this is not clear, because 24.6.1 [istream.iterator]/3 declares
+a copy constructor and a destructor and explains their semantic in
+24.6.1.1 [istream.iterator.cons]/3+4.
+</p>
+<p>
+The prototype semantic specification is ok (although it seems
+somewhat redundant to me, because the semantic doesn't say
+anything interesting in both cases), but for support of trivial class
+types we also need a trivial copy constructor and destructor as of
+9 [class]/6. The current non-informative specification of these
+two special members suggests to remove their explicit declaration
+in the class and add explicit wording that says that if <tt>T</tt> is
+trivial a default constructed iterator is also literal, alternatively it
+would be possible to mark both as defaulted and add explicit
+(memberwise) wording that guarantees that they are trivial.
+</p>
+<p>
+Btw.: I'm quite sure that the <tt>istreambuf_iterator</tt> additions to
+ensure triviality are not sufficient as suggested, because the
+library does not yet give general guarantees that a defaulted
+special member declaration makes this member also trivial.
+Note that e.g. the atomic types do give a general statement!
+</p>
+<p>
+Finally there is a wording issue: There does not exist something
+like a "literal constructor". The core language uses the term
+"constexpr constructor" for this.
+</p>
+<p>
+Suggestion:
+</p>
+<ol>
+<li>
+<p>
+Change 24.6.1 [istream.iterator]/3 as indicated:
+</p>
+<blockquote><pre><ins>constexpr</ins> istream_iterator();
+istream_iterator(istream_type& s);
+istream_iterator(const istream_iterator<del><T,charT,traits,Distance></del>& x)<ins> = default</ins>;
+~istream_iterator()<ins> = default</ins>;
+</pre></blockquote>
+</li>
+<li>
+<p>
+Change 24.6.1.1 [istream.iterator.cons]/1 as indicated:
+</p>
+<blockquote><pre><ins>constexpr</ins> istream_iterator();
+</pre>
+<blockquote>
+-1- <i>Effects:</i> Constructs the end-of-stream iterator. <ins>If <tt>T</tt> is a literal type,
+then this constructor shall be a constexpr constructor.</ins>
+</blockquote>
+</blockquote>
+</li>
+<li>
+<p>
+Change 24.6.1.1 [istream.iterator.cons]/3 as indicated:
+</p>
+<blockquote><pre>istream_iterator(const istream_iterator<del><T,charT,traits,Distance></del>& x)<ins> = default</ins>;
+</pre>
+<blockquote>
+-3- <i>Effects:</i> Constructs a copy of <tt>x</tt>. <ins>If <tt>T</tt> is a literal type, then
+this constructor shall be a trivial copy constructor.</ins>
+</blockquote>
+</blockquote>
+</li>
+<li>
+<p>
+Change 24.6.1.1 [istream.iterator.cons]/4 as indicated:
+</p>
+
+<blockquote><pre>~istream_iterator()<ins> = default</ins>;
+</pre>
+<blockquote>
+-4- <i>Effects:</i> The iterator is destroyed. <ins>If <tt>T</tt> is a literal type, then
+this destructor shall be a trivial
+destructor.</ins>
+</blockquote>
+</blockquote>
+</li>
+<li>
+<p>
+Change 24.6.3 [istreambuf.iterator] before p. 1 as indicated:
+</p>
+
+<blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
+<ins>istreambuf_iterator(const istreambuf_iterator&) throw() = default;</ins>
+<ins>~istreambuf_iterator() throw() = default;</ins>
+</pre></blockquote>
+</li>
+<li>
+<p>
+Change 24.6.3 [istreambuf.iterator]/1 as indicated:
+</p>
+<blockquote>
+[..] The default constructor <tt>istreambuf_iterator()</tt> and the constructor
+<tt>istreambuf_iterator(0)</tt> both
+construct an end of stream iterator object suitable for use as an
+end-of-range. <ins>All
+specializations of <tt>istreambuf_iterator</tt> shall have a trivial copy
+constructor, a constexpr default
+constructor and a trivial destructor.</ins>
+</blockquote>
+</li>
+</ol>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+24.6.1 [istream.iterator] para 3
+</p>
+
+<blockquote><pre><ins>constexpr</ins> istream_iterator();
+</pre></blockquote>
+
+<p>
+24.6.1.1 [istream.iterator.cons]
+</p>
+
+<blockquote><pre><ins>constexpr</ins> istream_iterator();
+</pre>
+<blockquote>
+-1- <i>Effects:</i> Constructs the end-of-stream iterator.
+<ins>If <tt>T</tt> is a literal type, then this constructor shall
+be a literal constructor.</ins>
+</blockquote>
+</blockquote>
+
+<p>
+24.6.3 [istreambuf.iterator]
+</p>
+
+<blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
+</pre></blockquote>
+
+
<hr>
-<h3><a name="874"></a>874. Missing <tt>initializer_list</tt> constructor for <tt>discrete_distribution</tt></h3>
-<p><b>Section:</b>
26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
+<h3><a name="1130"></a>1130. <tt>copy_exception</tt> name misleading</h3>
+<p><b>Section:</b>
18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-05-13 <b>Last modified:</b> 2009-06-02</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
<p><b>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>
-During the Sophia Antipolis meeting it was decided to separate from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a> a
-subrequest that adds initializer list support to
-<tt>discrete_distribution</tt>, specifically,
-the issue proposed to add a c'tor taking a <tt>initializer_list<double></tt>.
+The naming of <tt>std::copy_exception</tt> misleads almost everyone
+(experts included!) to think that it is the function that copies an
+<tt>exception_ptr</tt>:
</p>
+<blockquote><pre>exception_ptr p1 = current_exception();
+exception_ptr p2 = copy_exception( p1 );
+</pre></blockquote>
+
+<p>
+But this is not at all what it does. The above actually creates an
+<tt>exception_ptr p2</tt> that contains a copy of <tt>p1</tt>, not of
+the exception to which <tt>p1</tt> refers!
+</p>
+<p>
+This is, of course, all my fault; in my defence, I used <tt>copy_exception</tt>
+because I was unable to think of a better name.
+</p>
+<p>
+But I believe that, based on what we've seen so far, <em>any</em> other name would be better.
+</p>
+<p>
+Therefore, I propose <tt>copy_exception</tt> to be renamed to
+<tt>create_exception</tt>:
+</p>
+<blockquote><pre>template<class E> exception_ptr create_exception(E e);
+</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
<p>
-In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>,
-just <em>before</em> the member declaration
+with the following explanatory paragraph after it:
</p>
-<blockquote><pre>explicit discrete_distribution(const param_type& parm);
+<blockquote>
+Creates an <tt>exception_ptr</tt> that refers to a copy of <tt>e</tt>.
+</blockquote>
+
+<p><i>[
+2009-05-13 Daniel adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+What about
+</p>
+<blockquote><pre>make_exception_ptr
</pre></blockquote>
+<p>
+in similarity to <tt>make_pair</tt> and <tt>make_tuple</tt>, <tt>make_error_code</tt> and
+<tt>make_error_condition</tt>, or <tt>make_shared</tt>? Or, if a stronger symmetry to
+<tt>current_exception</tt> is preferred:
+</p>
+<blockquote><pre>make_exception
+</pre></blockquote>
<p>
-insert
+We have not a single <tt>create_*</tt> function in the library, it was always
+<tt>make_*</tt> used.
</p>
+</blockquote>
+
+<p><i>[
+2009-05-13 Peter adds:
+]</i></p>
+
-<blockquote><pre>discrete_distribution(initializer_list<double> wl);
+<blockquote>
+<tt>make_exception_ptr</tt> works for me.
+</blockquote>
+
+<p><i>[
+2009-06-02 Thomas J. Gritzan adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+To avoid surprises and unwanted recursion, how about making a call to
+<tt>std::make_exception_ptr</tt> with an <tt>exception_ptr</tt> illegal?
+</p>
+<p>
+It might work like this:
+</p>
+<blockquote><pre>template<class E>
+exception_ptr make_exception_ptr(E e);
+template<>
+exception_ptr make_exception_ptr<exception_ptr>(exception_ptr e) = delete;
</pre></blockquote>
-</li>
+</blockquote>
-<li>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-Between p.4 and p.5 of the same section insert a new
-paragraph as part of the new member description:
+Change 18.8.5 [propagation]:
</p>
-<blockquote><pre>discrete_distribution(initializer_list<double> wl);
+<blockquote>
+<pre>template<class E> exception_ptr <del>copy_exception</del><ins>make_exception_ptr</ins>(E e);
</pre>
<blockquote>
-<i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>.
+<p>
+-11- <i>Effects:</i> <ins>Creates an <tt>exception_ptr</tt> that refers
+to a copy of <tt>e</tt>,</ins> as if
+</p>
+
+<blockquote><pre>try {
+ throw e;
+} catch(...) {
+ return current_exception();
+}
+</pre></blockquote>
+
+<p>...</p>
</blockquote>
+
</blockquote>
-</li>
-</ol>
+
<hr>
-<h3><a name="875"></a>875. Missing <tt>initializer_list</tt> constructor for <tt>piecewise_constant_distribution</tt></h3>
-<p><b>Section:</b> 2
6.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
+<h3><a name="1131"></a>1131. C++0x does not need <tt>alignment_of</tt></h3>
+<p><b>Section:</b> 2
0.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-06-01 <b>Last modified:</b> 2009-06-02</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-During the Sophia Antipolis meeting it was decided to separate from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a> a subrequest that adds initializer list support to
-<tt>piecewise_constant_distribution</tt>, specifically, the issue proposed
-to add a c'tor taking a <tt>initializer_list<double></tt> and a <tt>Callable</tt> to evaluate
-weight values. For consistency with the remainder of this class and
-the remainder of the <tt>initializer_list</tt>-aware library the author decided to
-change the list argument type to the template parameter <tt>RealType</tt>
-instead. For the reasoning to use <tt>Func</tt> instead of <tt>Func&&</tt> as c'tor
-function argument see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>.
+The <tt>alignment_of</tt> template is no longer necessary, now that the
+core language will provide <tt>alignof</tt>. Scott Meyers raised this
+issue at comp.std.c++,
+<a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/9b020306e803f08a">C++0x: alignof vs. alignment_of</a>,
+May 21, 2009. In a reply, Daniel Krügler pointed out that
+<tt>alignof</tt> was added to the working paper <i>after</i>
+<tt>alignment_of</tt>. So it appears that <tt>alignment_of</tt> is only
+part of the current Working Draft
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
+because it is in TR1.
+</p>
+<p>
+Having both <tt>alignof</tt> and <tt>alignment_of</tt> would cause
+unwanted confusion. In general, I think TR1 functionality should not be
+brought into C++0x if it is entirely redundant with other C++0x language
+or library features.
</p>
<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
<p>
-In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
-just <em>before</em> the member declaration
+Remove from Header <type_traits> synopsis 20.6.2 [meta.type.synop]:
</p>
-
-<blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm);
+<blockquote><pre><del>template <class T> struct alignment_of;</del>
</pre></blockquote>
<p>
-insert
+Remove the first row of Table 34 ("Type property queries"), from
+Type properties 20.6.4.3 [meta.unary.prop]:
</p>
+<blockquote>
+<table border="1">
+<caption>Table 34 -- Type property queries</caption>
+<tbody><tr>
+<td><del><tt>template <class T> struct alignment_of;</tt></del></td>
+<td><del><tt>alignof(T)</tt>.</del><br>
+<del><i>Precondition:</i> <tt>T</tt> shall be a complete type, a reference
+type, or an array of unknown bound, but shall not be a function type or
+(possibly cv-qualified) <tt>void</tt>.</del>
+</td>
+</tr>
+</tbody></table>
+</blockquote>
-<blockquote><pre>template<typename Func>
-piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
-</pre></blockquote>
-</li>
+<p>
+Change text in Table 41 ("Other transformations"), from Other
+transformations 20.6.7 [meta.trans.other], as follows:
+</p>
+<blockquote>
+<table border="1">
+<caption>Table 41 -- Other transformations</caption>
+<tbody><tr><td>...</td>
+<td>
+ Align shall be equal to <tt>
+ <del>alignment_of<T>::value</del>
+ <ins>alignof(T)</ins>
+ </tt> for some type <tt>T</tt> or to <i>default-alignment</i>.
+</td>
+<td>...</td>
+</tr></tbody></table>
+</blockquote>
-<li>
+
+
+
+
+<hr>
+<h3><a name="1132"></a>1132. JP-30: nested exceptions</h3>
+<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Seiji Hayashida <b>Opened:</b> 2009-06-01 <b>Last modified:</b> 2009-06-02</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p><b>Addresses JP 30</b></p>
+
+<p>
+C++0x <tt>nested_exception</tt> cannot handle a structured exception well. The
+following codes show two types of tree structured exception handling.
+</p>
+<p>
+The first one is based on <tt>nested_exception</tt> in C++0x,
+while the second one is based on my library <tt>trickerr.h</tt> (in Japanese).
+<a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>
+</p>
+<p>
+Assume that Function <tt>A()</tt> calls two sub functions <tt>A_a()</tt> and <tt>A_b()</tt>, both might
+throw tree structured exceptions, and <tt>A_b()</tt> must be called even if <tt>A_a()</tt>
+throws an exception.
+</p>
<p>
-Between p.4 and p.5 of the same section insert a series of
-new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
-as part of the new member description:
+List A (code of tree structured exception handling based on nested_exception
+in C++0x)
</p>
-<blockquote><pre>template<typename Func>
-piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
-</pre>
+<blockquote><pre>void A()
+{
+ try
+ {
+ std::vector<exception_ptr> exception_list;
+ try
+ {
+ // A_a() does a similar processing as A().
+ A_a();
+ }
+ catch(...)
+ {
+ exception_list.push_back(current_exception());
+ }
-<blockquote>
+ // ***The processing A() has to do even when A_a() fails. ***
+ try
+ {
+ // A_b() does a similar processing as A().
+ A_b();
+ }
+ catch(...)
+ {
+ exception_list.push_back(current_exception());
+ }
+ if (!exception_list.empty())
+ {
+ throw exception_list;
+ }
+ }
+ catch(...)
+ {
+ throw_with_nested(A_exception("someone error"));
+ }
+}
+void print_tree_exception(exception_ptr e, const std::string & indent ="")
+{
+ const char * indent_unit = " ";
+ const char * mark = "- ";
+ try
+ {
+ rethow_exception(e);
+ }
+ catch(const std::vector<exception_ptr> e)
+ {
+ for(std::vector<exception_ptr>::const_iterator i = e.begin(); i!=e.end(); ++i)
+ {
+ print_tree_exception(i, indent);
+ }
+ }
+ catch(const std::nested_exception e)
+ {
+ print_tree_exception(evil_i(e), indent +indent_unit);
+ }
+ catch(const std::exception e)
+ {
+ std::cout << indent << mark << e.what() << std::endl;
+ }
+ catch(...)
+ {
+ std::cout << indent << mark << "unknown exception" << std::endl;
+ }
+}
+int main(int, char * [])
+{
+ try
+ {
+ A();
+ }
+ catch()
+ {
+ print_tree_exception(current_exception());
+ }
+ return EXIT_SUCCESS;
+}
+</pre></blockquote>
<p>
-[p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
+List B ( code of tree structured exception handling based on <tt>trickerr.h</tt>. )
+"trickerr.h" (in Japanese), refer to:
+<a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>.
</p>
+<blockquote><pre>void A()
+{
+ tricklib::error_listener_type error_listener;
+ // A_a() is like A(). A_a() can throw tree structured exception.
+ A_a();
+
+ // *** It must do process so that A_a() throws exception in A(). ***
+ // A_b() is like A(). A_b() can throw tree structured exception.
+ A_b();
+
+ if (error_listener.has_error()) // You can write this "if block" in destructor
+ // of class derived from error_listener_type.
+ {
+ throw_error(new A_error("someone error",error_listener.listener_off().extract_pending_error()));
+ }
+}
+void print_tree_error(const tricklib::error_type &a_error, const std::string & indent = "")
+{
+ const char * indent_unit = " ";
+ const char * mark = "- ";
+
+ tricklib::error_type error = a_error;
+ while(error)
+ {
+ std::cout << indent << mark << error->message << std::endl;
+ if (error->children)
+ {
+ print_tree_error(error->children, indent +indent_unit);
+ }
+ error = error->next;
+ }
+}
+int main(int, char * [])
+{
+ tricklib::error_thread_power error_thread_power_on; // This object is necessary per thread.
+
+ try
+ {
+ A();
+ }
+ catch(error_type error)
+ {
+ print_tree_error(error);
+ }
+ catch(...)
+ {
+ std::cout << "- unknown exception" << std::endl;
+ }
+ return EXIT_SUCCESS;
+}
+</pre></blockquote>
+
+<p>
+Prospect
+</p>
<p>
-[p5_2] <i>Requires:</i>
+We will focus on the method A() since the other methods, also main(), occur
+only once respectively.
</p>
-<ol type="a">
-<li>
-<tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
- return values of a type convertible to <tt>double</tt>;
-</li>
+<ul>
<li>
-The relation <tt>0 < S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold.
-For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight
- value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
+ In the List A above (of the nested exception handling), it is hard to
+ find out an active reason to use the nested exception handling at this
+ scene. Rather, we can take a simpler description by throwing the entire
+ exception_list directly to the top level.
</li>
<li>
-If <tt>nf > 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
-following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> < b<sub><i>k+1</i></sub></tt>.
+ The code in the same example gives us a kind of redundant impression,
+ which might have come from the fact that the try-throw-catch framework does
+ not assume a tree structured exception handling.
</li>
-</ol>
+</ul>
<p>
-[p5_3] <i>Effects:</i>
+According to the above observation, we cannot help concluding that it is not
+so easy to use the nested_exception handling as a tree structured exception
+handling mechanism in a practical sense.
+</p>
+<p>
+This text is based on the web page below (in Japanese).
+<a href="http://d.hatena.ne.jp/wraith13/20081231/1230715424">http://d.hatena.ne.jp/wraith13/20081231/1230715424</a>
</p>
-<ol type="a">
-<li>
-<p>If <tt>nf == 0</tt>,</p>
-<ol type="a">
-<li>
-lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
- value <tt>w<sub>0</sub> = 1</tt>, and
-</li>
-<li>
-lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>.
-</li>
-</ol>
-</li>
-<li>
-<p>Otherwise,</p>
-<ol type="a">
-<li>
-sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
-length <tt>n+1</tt>, and
-</li>
-<li>
-<p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
- calculates:</p>
-<blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
-w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1133"></a>1133. Does N2844 break current specification of list::splice?</h3>
+<p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09 <b>Last modified:</b> 2009-06-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+IIUC,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
+means that lvalues will no longer bind to rvalue references.
+Therefore, the current specification of <tt>list::splice</tt> (list
+operations 23.3.4.4 [list.ops]) will be a breaking change of behaviour for existing
+programs. That is because we changed the signature to swallow via an rvalue
+reference rather than the lvalue reference used in 03.
+</p>
+<p>
+Retaining this form would be safer, requiring an explicit move when splicing
+from lvalues. However, this will break existing programs.
+We have the same problem with <tt>forward_list</tt>, although without the risk of
+breaking programs so here it might be viewed as a positive feature.
+</p>
+<p>
+The problem signatures:
+</p>
+<blockquote><pre>void splice_after(const_iterator position, forward_list<T,Alloc>&& x);
+void splice_after(const_iterator position, forward_list<T,Alloc>&& x,
+ const_iterator i);
+void splice_after(const_iterator position, forward_list<T,Alloc>&& x,
+ const_iterator first, const_iterator last);
+
+void splice(const_iterator position, list<T,Alloc>&& x);
+void splice(const_iterator position, list<T,Alloc>&& x,
+ const_iterator i);
+void splice(const_iterator position, list<T,Alloc>&& x,
+ const_iterator first, const_iterator last);
</pre></blockquote>
-</li>
-</ol>
-</li>
-<li>
+<b>Possible resolutions:</b>
+
+<p>
+Option A. Add an additional (non-const) lvalue-reference
+overload in each case
+</p>
+<p>
+Option B. Change rvalue reference back to (non-const)
+lvalue-reference overload in each case
+</p>
+<p>
+Option C. Add an additional (non-const) lvalue-reference
+overload in just the <tt>std::list</tt> cases
+</p>
+<p>
+I think (B) would be very unfortunate, I really like the <tt>forward_list</tt>
+behaviour in (C) but feel (A) is needed for consistency.
+</p>
+<p>
+My actual preference would be NAD, ship with this as a breaking change as it
+is a more explicit interface. I don't think that will fly though!
+</p>
+
+<p>
+See the thread starting with c++std-lib-23725 for more discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="1134"></a>1134. Redundant specification of stdint.h, fenv.h, tgmath.h, and maybe complex.h</h3>
+<p><b>Section:</b> 18.4.2 [stdinth], 26.3.2 [fenv], 26.8 [c.math], 26.4.11 [cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2009-05-26 <b>Last modified:</b> 2009-06-14</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+This is probably editorial.
+</p>
+<p>
+The following items should be removed from the draft, because they're
+redundant with Annex D, and they arguably make some *.h headers
+non-deprecated:
+</p>
+<p>
+18.4.2 [stdinth] (regarding <tt><stdint.h></tt>)
+</p>
+<p>
+26.3.2 [fenv] (regarding <tt><fenv.h></tt>
+</p>
+<p>
+Line 3 of 26.8 [c.math] (regarding <tt><tgmath.h></tt>)
+</p>
+<p>
+26.4.11 [cmplxh] (regarding <tt><complex.h></tt>, though the note in this subclause is not redundant)
+</p>
+
+<p><i>[
+2009-06-10 Ganesh adds:
+]</i></p>
+
+
+<blockquote>
+While searching for <tt>stdint</tt> in the CD, I found that <tt><stdint.h></tt> is also
+mentioned in 3.9.1 [basic.fundamental] /5. It guess it should refer to
+<tt><cstdint></tt> instead.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Remove the section 18.4.2 [stdinth].
+</p>
+<p>
+Remove the section 26.3.2 [fenv].
+</p>
+<p>
+Remove 26.8 [c.math], p3:
+</p>
+
+<blockquote>
+<del>-3- The header <tt><tgmath.h></tt> effectively includes the headers <tt><complex.h></tt>
+and <tt><math.h></tt>.</del>
+</blockquote>
+<p>
+Remove the section 26.4.11 [cmplxh].
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="1135"></a>1135. <tt>exception_ptr</tt> should support contextual conversion to <tt>bool</tt></h3>
+<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-06 <b>Last modified:</b> 2009-06-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-Constructs a <tt>piecewise_constant_distribution</tt> object with
-the above computed sequence <tt>b</tt> as the interval boundaries
-and with the probability densities:
+As of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
+18.8.5 [propagation]/5, the implementation-defined type
+<tt>exception_ptr</tt> does provide the following ways to check whether
+it is a null value:
</p>
-<blockquote><pre>ρ<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
+<blockquote><pre>void f(std::exception_ptr p) {
+ p == nullptr;
+ p == 0;
+ p == exception_ptr();
+}
</pre></blockquote>
+<p>
+This is rather cumbersome way of checking for the null value
+and I suggest to require support for evaluation in a boolean
+context like so:
+</p>
-</li>
-</ol>
+<blockquote><pre>void g(std::exception_ptr p) {
+ if (p) {}
+ !p;
+}
+</pre></blockquote>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In section 18.8.5 [propagation] insert a new paragraph between p.5 and p.6:
+</p>
+
+<blockquote>
+<ins>
+An object <tt>e</tt> of type <tt>exception_ptr</tt> can be contextually converted to <tt>bool</tt>.
+The effect shall be as if <tt>e != exception_ptr()</tt> had been evaluated in place
+of <tt>e</tt>. There shall be no implicit conversion to arithmetic type, to
+enumeration type or to pointer type.
+</ins>
</blockquote>
-</blockquote>
-</li>
-</ol>
<hr>
-<h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3>
-<p><b>Section:</b>
21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
+<h3><a name="1136"></a>1136. Incomplete specification of <tt>nested_exception::rethrow_nested()</tt></h3>
+<p><b>Section:</b>
18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-06 <b>Last modified:</b> 2009-06-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-During the Sophia Antipolis meeting it was decided to split-off some
-parts of the
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a>
-("Concurrency modifications for <tt>basic_string</tt>")
-proposal into a separate issue, because these weren't actually
-concurrency-related. The here proposed changes refer to the recent
-update document
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a>
-and attempt to take advantage of the
-stricter structural requirements.
-</p>
-<p>
-Indeed there exists some leeway for more guarantees that would be
-very useful for programmers, especially if interaction with transactionary
-or exception-unaware C API code is important. This would also allow
-compilers to take advantage of more performance optimizations, because
-more functions can have throw() specifications. This proposal uses the
-form of "Throws: Nothing" clauses to reach the same effect, because
-there already exists a different issue in progress to clean-up the current
-existing "schizophrenia" of the standard in this regard.
+It was recently mentioned in a newsgroup article
+<a href="http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d">http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d</a>
+that the specification of the member function <tt>rethrow_nested()</tt> of the
+class <tt>nested_exception</tt> is incomplete, specifically it remains unclear
+what happens, if member <tt>nested_ptr()</tt> returns a null value. In
+18.8.6 [except.nested] we find only the following paragraph related to that:
</p>
+<blockquote><pre>void rethrow_nested() const; // [[noreturn]]
+</pre>
+<blockquote>
+-4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt> object.
+</blockquote>
+</blockquote>
<p>
-Due to earlier support for copy-on-write, we find the following
-unnecessary limitations for C++0x:
+This is a problem, because it is possible to create an object of
+<tt>nested_exception</tt> with exactly such a state, e.g.
</p>
+<blockquote><pre>#include <exception>
+#include <iostream>
-<ol>
-<li>
-Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
-a pointer to their guts, which is a non-failure operation. This should
-be spelled out. It is also noteworthy to mention that the same
-guarantees should also be given by the size query functions,
-because the combination of pointer to content and the length is
-typically needed during interaction with low-level API.
-</li>
-<li>
-Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
-a pointer to their guts, which is guaranteed O(1). This should be
-spelled out.
-</li>
-<li>
-Missing reading access to the terminating character: Only the
-const overload of <tt>operator[]</tt> allows reading access to the terminator
-char. For more intuitive usage of strings, reading access to this
-position should be extended to the non-const case. In contrast
-to C++03 this reading access should now be homogeneously
-an lvalue access.
-</li>
-</ol>
-
+int main() try {
+ std::nested_exception e; // OK, calls current_exception() and stores it's null value
+ e.rethrow_nested(); // ?
+ std::cout << "A" << std::endl;
+}
+catch(...) {
+ std::cout << "B" << std::endl;
+}
+</pre></blockquote>
<p>
-The proposed resolution is split into a main part (A) and a
-secondary part (B) (earlier called "Adjunct Adjunct Proposal").
-(B) extends (A) by also making access to index position
-size() of the at() overloads a no-throw operation. This was
-separated, because this part is theoretically observable in
-specifically designed test programs.
+I suggest to follow the proposal of the reporter, namely to invoke
+<tt>terminate()</tt> if <tt>nested_ptr()</tt> return a null value of <tt>exception_ptr</tt> instead
+of relying on the fallback position of undefined behavior. This would
+be consistent to the behavior of a <tt>throw;</tt> statement when no
+exception is being handled.
</p>
<p><b>Proposed resolution:</b></p>
-<ol type="A">
-<li>
-<ol>
-<li>
-<p>In 21.3.4 [string.capacity], just after p. 1 add a new paragraph:
+<p>
+Change around 18.8.6 [except.nested]/4 as indicated:
</p>
<blockquote>
-<i>Throws:</i> Nothing.
-</blockquote>
-
-</li>
-<li>
<p>
-In 21.3.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs:
+-4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt>
+object<ins>, if <tt>nested_ptr() != nullptr</tt></ins>
</p>
-
-<blockquote>
<p>
-<i>Requires:</i> <tt>pos ≤ size()</tt>.
+<ins>- <i>Remarks:</i> If <tt>nested_ptr() == nullptr</tt>, <tt>terminate()</tt>
+shall be called.</ins>
</p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="1137"></a>1137. Return type of <tt>conj</tt> and <tt>proj</tt></h3>
+<p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Marc Steinbach <b>Opened:</b> 2009-06-11 <b>Last modified:</b> 2009-06-14</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-<i>Returns:</i> If <tt>pos < size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns
-a reference to a <tt>charT()</tt> that shall not be modified.
+In clause 1, the Working Draft
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
+specifies overloads of the
+functions
</p>
+<blockquote><pre>arg, conj, imag, norm, proj, real
+</pre></blockquote>
<p>
-<i>Throws:</i> Nothing.
+for non-complex arithmetic types (<tt>float</tt>, <tt>double</tt>,
+<tt>long double</tt>, and integers).
+The only requirement (clause 2) specifies type promotion of arguments.
</p>
<p>
-<i>Complexity:</i> Constant time.
+I strongly suggest to add the following requirement on the return types:
</p>
+<blockquote>
+All the specified overloads must return real (i.e., non-complex) values,
+specifically, the nested <tt>value_type</tt> of promoted arguments.
</blockquote>
-</li>
-<li>
<p>
-In 21.3.7.1 [string.accessors] replace the now <em>common</em> returns
-clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs:
+(This has no effect on <tt>arg</tt>, <tt>imag</tt>, <tt>norm</tt>, <tt>real</tt>:
+they are real-valued anyway.)
</p>
-<blockquote>
+<p><b>Rationale:</b></p>
<p>
-<i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &operator[](i)</tt> for each <tt>i</tt>
-in <tt>[0, size()]</tt>.
-</p>
+Mathematically, <tt>conj()</tt> and <tt>proj()</tt>, like the transcendental functions, are
+complex-valued in general but map the (extended) real line to itself.
+In fact, both functions act as identity on the reals.
+A typical user will expect <tt>conj()</tt> and <tt>proj()</tt> to preserve this essential
+mathematical property in the same way as <tt>exp()</tt>, <tt>sin()</tt>, etc.
+A typical use of <tt>conj()</tt>, e.g., is the generic scalar product of n-vectors:
+</p>
+
+<blockquote><pre>template<typename T>
+inline T
+scalar_product(size_t n, T const* x, T const* y) {
+ T result = 0;
+ for (size_t i = 0; i < n; ++i)
+ result += std::conj(x[i]) * y[i];
+ return result;
+}
+</pre></blockquote>
<p>
-<i>Throws:</i> Nothing.
+This will work equally well for real and complex floating-point types <tt>T</tt> if
+<tt>conj()</tt> returns <tt>T</tt>. It will not work with real types if <tt>conj()</tt>
+returns complex values.
</p>
<p>
-<i>Complexity:</i> Constant time.
+Instead, the implementation of <tt>scalar_product</tt> becomes either less efficient
+and less useful (if a complex result is always returned), or unnecessarily
+complicated (if overloaded versions with proper return types are defined).
+In the second case, <tt>conj()</tt> is not used with real arguments.
</p>
-</blockquote>
-</li>
-</ol>
-</li>
-<li>
-<ol start="4">
-<li>
<p>
-In 21.3.5 [string.access] <em>replace</em> p.2 and p.3 by:
+Any use of <tt>conj()</tt> I can think of would benefit from the proposed return type
+requirement, in a similar way.
+It will not harm use cases where a complex value is expected, because of
+implicit conversion to complex.
+Without the proposed return type guarantee, I find an overloaded <tt>conj()</tt> not
+only useless but actually troublesome.
</p>
-<blockquote>
<p>
-<i>Requires:</i> <tt>pos ≤ size()</tt>
+I believe that the same applies to <tt>proj()</tt>, althought up to now I had no need
+for it.
</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-<i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > size()</tt>.
+Insert a new paragraph after 26.4.9 [cmplx.over]/2:
</p>
-</blockquote>
-</li>
-</ol>
-</li>
-</ol>
+<blockquote>
+<ins>
+All of the specified overloads shall have a return type which is the nested <tt>value_type</tt> of
+the promoted arguments.
+</ins>
+</blockquote>
<hr>
-<h3><a name="877"></a>877. to <tt>throw()</tt> or to <i>Throw:</i> Nothing.</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-08-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
+<h3><a name="1138"></a>1138. unusal return value for operator+</h3>
+<p><b>Section:</b> 21.4.8.1 [string::op+] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-06-12 <b>Last modified:</b> 2009-06-15</p>
<p><b>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>
+Many of the <tt>basic_string operator+</tt> overloads return an rvalue-reference. Is
+that really intended?
+</p>
+<p>
+I'm considering it might be a mild performance tweak to avoid making
+un-necessary copies of a cheaply movable type, but it opens risk to dangling
+references in code like:
+</p>
-Recent changes to
-the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">working
-draft</a> have introduced a gratuitous inconsistency with the C++ 2003
-version of the specification with respect to exception guarantees
-provided by standard functions. While the C++ 2003 standard
-consistenly uses the empty exception specification, <tt>throw()</tt>,
-to declare functions that are guaranteed not to throw exceptions, the
-current working draft contains a number of "<i>Throws:</i> Nothing."
-clause to specify essentially the same requirement. The difference
-between the two approaches is that the former specifies the behavior
-of programs that violate the requirement (<tt>std::unexpected()</tt>
-is called) while the latter leaves the behavior undefined.
+<blockquote><pre>auto && s = string{"x"} + string{y};
+</pre></blockquote>
- </p>
- <p>
+<p>
+and I'm not sure about:
+</p>
-A survey of the working draft reveals that there are a total of 209
-occurrences of <tt>throw()</tt> in the library portion of the spec,
-the majority in clause 18, a couple (literally) in 19, a handful in
-20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9.
+<blockquote><pre>auto s = string{"x"} + string{y};
+</pre></blockquote>
- </p>
- <p>
-There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered
-throughout the spec.
+<p><b>Proposed resolution:</b></p>
+<p>
+Strike the <tt>&&</tt> from the return type in the following function
+signatures:
+</p>
- </p>
- <p>
+<blockquote>
+<p>
+21.3 [string.classes] p2 Header Synopsis
+</p>
-While sometimes there are good reasons to use the "<i>Throws:</i>
-Nothing." approach rather than making use of <tt>throw()</tt>, these
-reasons do not apply in most of the cases where this new clause has
-been introduced and the empty exception specification would be a
-better approach.
+<blockquote><pre>template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(basic_string<charT,traits,Allocator>&& lhs,
+ const basic_string<charT,traits,Allocator>& rhs);
- </p>
- <p>
+template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(const basic_string<charT,traits,Allocator>& lhs,
+ basic_string<charT,traits,Allocator>&& rhs);
-First, functions declared with the empty exception specification
-permit compilers to generate better code for calls to such
-functions. In some cases, the compiler might even be able to eliminate
-whole chunks of user-written code when instantiating a generic
-template on a type whose operations invoked from the template
-specialization are known not to throw. The prototypical example are
-the <tt>std::uninitialized_copy()</tt>
-and <tt>std::uninitialized_fill()</tt> algorithms where the
-entire <tt>catch(...)</tt> block can be optimized away.
+template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(basic_string<charT,traits,Allocator>&& lhs,
+ basic_string<charT,traits,Allocator>&& rhs);
- </p>
- <p>
-For example, given the following definition of
-the <tt>std::uninitialized_copy</tt> function template and a
-user-defined type <tt>SomeType</tt>:
+template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(const charT* lhs,
+ basic_string<charT,traits,Allocator>&& rhs);
- </p>
- <blockquote>
- <pre>template <class InputIterator, class ForwardIterator>
-ForwardIterator
-uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
-{
- typedef iterator_traits<ForwardIterator>::value_type ValueType;
+template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(charT lhs, basic_string<charT,traits,Allocator>&& rhs);
- ForwardIterator start = res;
+template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(basic_string<charT,traits,Allocator>&& lhs,
+ const charT* rhs);
- try {
- for (; first != last; ++first, ++res)
- ::new (&*res) ValueType (*first);
- }
- catch (...) {
- for (; start != res; --start)
- (&*start)->~ValueType ();
- throw;
- }
- return res;
-}
+template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(basic_string<charT,traits,Allocator>&& lhs, charT rhs);
+</pre></blockquote>
-struct SomeType {
- SomeType (const SomeType&) <ins>throw ()</ins>;
-}</pre>
- </blockquote>
- <p>
+<p>
+21.4.8.1 [string::op+]
+</p>
-compilers are able to emit the following efficient specialization
-of <tt>std::uninitialized_copy<const SomeType*, SomeType*></tt>
-(note that the <tt>catch</tt> block has been optimized away):
+<blockquote><pre>template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(basic_string<charT,traits,Allocator>&& lhs,
+ const basic_string<charT,traits,Allocator>& rhs);
- </p>
- <blockquote>
- <pre>template <> SomeType*
-uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
-{
- for (; first != last; ++first, ++res)
- ::new (res) SomeType (*first);
+template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(const basic_string<charT,traits,Allocator>& lhs,
+ basic_string<charT,traits,Allocator>&& rhs);
- return res;
-}</pre>
- </blockquote>
- <p>
+template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(basic_string<charT,traits,Allocator>&& lhs,
+ basic_string<charT,traits,Allocator>&& rhs);
-Another general example is default constructors which, when decorated
-with <tt>throw()</tt>, allow the compiler to eliminate the
-implicit <tt>try</tt> and <tt>catch</tt> blocks that it otherwise must
-emit around each the invocation of the constructor
-in <i>new-expressions</i>.
- </p>
- <p>
+template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(const charT* lhs,
+ basic_string<charT,traits,Allocator>&& rhs);
-For example, given the following definitions of
-class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two
-statements below:
+template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(charT lhs, basic_string<charT,traits,Allocator>&& rhs);
- </p>
- <blockquote>
- <pre>struct MayThrow {
- MayThrow ();
-};
+template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(basic_string<charT,traits,Allocator>&& lhs,
+ const charT* rhs);
-struct WontThrow {
- WontThrow () <ins>throw ()</ins>;
-};
+template<class charT, class traits, class Allocator>
+ basic_string<charT,traits,Allocator><del>&&</del>
+ operator+(basic_string<charT,traits,Allocator>&& lhs, charT rhs);
+</pre></blockquote>
-MayThrow *a = new MayThrow [N];
-WontThrow *b = new WontThrow [N];</pre>
+</blockquote>
- </blockquote>
- <p>
-the compiler generates the following code for the first statement:
- </p>
- <blockquote>
- <pre>MayThrow *a;
-{
- MayThrow *first = operator new[] (N * sizeof (*a));
- MayThrow *last = first + N;
- MayThrow *next = first;
- try {
- for ( ; next != last; ++next)
- new (next) MayThrow;
- }
- catch (...) {
- for ( ; first != first; --next)
- next->~MayThrow ();
- operator delete[] (first);
- throw;
- }
- a = first;
-}</pre>
- </blockquote>
- <p>
-but it is can generate much more compact code for the second statement:
- </p>
- <blockquote>
- <pre>WontThrow *b = operator new[] (N * sizeof (*b));
-WontThrow *last = b + N;
-for (WontThrow *next = b; next != last; ++next)
- new (next) WontThrow;
-</pre>
- </blockquote>
- <p>
-Second, in order for users to get the maximum benefit out of the new
-<tt>std::has_nothrow_xxx</tt> traits when using standard library types
-it will be important for implementations to decorate all non throwing
-copy constructors and assignment operators with <tt>throw()</tt>. Note
-that while an optimizer may be able to tell whether a function without
-an explicit exception specification can throw or not based on its
-definition, it can only do so when it can see the source code of the
-definition. When it can't it must assume that the function may
-throw. To prevent violating the One Definition Rule,
-the <tt>std::has_nothrow_xxx</tt> trait must return the most
-pessimistic guess across all translation units in the program, meaning
-that <tt>std::has_nothrow_xxx<T>::value</tt> must evaluate to
-<tt>false</tt> for any <tt>T</tt> whose <tt>xxx</tt>
-(where <tt>xxx</tt> is default or copy ctor, or assignment operator)
-is defined out-of-line.
+<hr>
+<h3><a name="1139"></a>1139. Response to US 93</h3>
+<p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread">active issues</a> in [thread].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
- </p>
- <p>
+<p><b>Addresses US 93, JP 79, UK 333, JP 81</b></p>
-<b>Counterarguments:</b>
+<p>
+The thread chapter is not concept enabled.
+</p>
- </p>
- <p>
-During the discussion of this issue
-on <a href="mailto:c++std-lib@accu.org">c++std-lib@accu.org</a>
-(starting with post <tt>c++std-lib-21950</tt>) the following arguments
-in favor of the "<i>Throws:</i> Nothing." style have been made.
- </p>
- <p>
- </p><ol>
- <li>
+<p><b>Proposed resolution:</b></p>
-Decorating functions that cannot throw with the empty exception
-specification can cause the compiler to generate suboptimal code for
-the implementation of the function when it calls other functions that
-aren't known to the compiler not to throw (i.e., that aren't decorated
-with <tt>throw()</tt> even if they don't actually throw). This is a
-common situation when the called function is a C or POSIX function.
- </li>
- <li>
-Alternate, proprietary mechanisms exist (such as
-GCC <a href="http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#index-g_t_0040code_007bnothrow_007d-function-attribute-2160"><tt>__attribute__((nothrow))</tt></a>
-or Visual
-C++ <a href="http://msdn.microsoft.com/en-us/library/49147z04%28VS.80%29.aspx"><tt>__declspec(nothrow)</tt></a>)
-that let implementers mark up non-throwing functions, often without
-the penalty mentioned in (1) above. The C++ standard shouldn't
-preclude the use of these potentially more efficient mechanisms.
- </li>
- <li>
-There are functions, especially function templates, that invoke
-user-defined functions that may or may not be
-declared <tt>throw()</tt>. Declaring such functions with the empty
-exception specification will cause compilers to generate suboptimal
-code when the user-defined function isn't also declared not to throw.
+<hr>
+<h3><a name="1140"></a>1140. Response to US 84</h3>
+<p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#numerics">active issues</a> in [numerics].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numerics">issues</a> in [numerics].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
- </li>
- </ol>
-
- <p>
+<p><b>Addresses US 84</b></p>
-The answer to point (1) above is that implementers can (and some have)
-declare functions with <tt>throw()</tt> to indicate to the compiler
-that calls to the function can safely be assumed not to throw in order
-to allow it to generate efficient code at the call site without also
-having to define the functions the same way and causing the compiler
-to generate suboptimal code for the function definition. That is, the
-function is declared with <tt>throw()</tt> in a header but it's
-defined without it in the source file. The <tt>throw()</tt>
-declaration is suppressed when compiling the definition to avoid
-compiler errors. This technique, while strictly speaking no permitted
-by the language, is safe and has been employed in practice. For
-example, the GNU C library takes this approach. Microsoft Visual C++
-takes a similar approach by simply assuming that no function with C
-language linkage can throw an exception unless it's explicitly
-declared to do so using the language extension <tt>throw(...)</tt>.
+<p>
+The numerics chapter is not concept enabled.
+</p>
- </p>
- <p>
+<p>
+The portion of this comment dealing with random numbers was resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a>,
+which was accepted in Summit.
+</p>
-Our answer to point (2) above is that there is no existing practice
-where C++ Standard Library implementers have opted to make use of the
-proprietary mechanisms to declare functions that don't throw. The
-language provides a mechanism specifically designed for this
-purpose. Avoiding its use in the specification itself in favor of
-proprietary mechanisms defeats the purpose of the feature. In
-addition, making use of the empty exception specification
-inconsistently, in some areas of the standard, while conspicuously
-avoiding it and making use of the "<i>Throws:</i> Nothing." form in
-others is confusing to users.
- </p>
- <p>
-The answer to point (3) is simply to exercise caution when declaring
-functions and especially function templates with the empty exception
-specification. Functions that required not to throw but that may call
-back into user code are poor candidates for the empty exception
-specification and should instead be specified using "<i>Throws:</i>
-Nothing." clause.
+<p><b>Proposed resolution:</b></p>
- </p>
-
- <p><b>Proposed resolution:</b></p>
- <p>
-We propose two possible solutions. Our recommendation is to adopt
-Option 1 below.
- </p>
- <p>
-<b>Option 1:</b>
- </p>
- <p>
+<hr>
+<h3><a name="1141"></a>1141. Response to US 85</h3>
+<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
+<p><b>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>
-Except for functions or function templates that make calls back to
-user-defined functions that may not be declared <tt>throw()</tt>
-replace all occurrences of the "<i>Throws:</i> Nothing." clause with
-the empty exception specification. Functions that are required not to
-throw but that make calls back to user code should be specified to
-"<i>Throw:</i> Nothing."
+<p><b>Addresses US 85, JP 67, JP 68, JP 69, JP 72</b></p>
- </p>
- <p>
+<p>
+The input/output chapter is not concept enabled.
+</p>
-<b>Option 2:</b>
- </p>
- <p>
-For consistency, replace all occurrences of the empty exception
-specification with a "<i>Throws:</i> Nothing." clause.
+<p><b>Proposed resolution:</b></p>
+
- </p>
-
<hr>
-<h3><a name="878"></a>878. <tt>forward_list</tt> preconditions</h3>
-<p><b>Section:</b> 23.2.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-08-23</p>
+<h3><a name="1142"></a>1142. Response to US 86</h3>
+<p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re">active issues</a> in [re].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
<p><b>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>forward_list</tt> member functions that take
-a <tt>forward_list::iterator</tt> (denoted <tt>position</tt> in the
-function signatures) argument have the following precondition:
+<p><b>Addresses US 86, UK 309, UK 310</b></p>
- </p>
- <blockquote>
+<p>
+The regular expressions chapter is not concept enabled.
+</p>
-<i>Requires:</i> <tt>position</tt> is dereferenceable or equal
-to <tt>before_begin()</tt>.
- </blockquote>
- <p>
-I believe what's actually intended is this:
+<p><b>Proposed resolution:</b></p>
- </p>
- <blockquote>
-<i>Requires:</i> <tt>position</tt> is in the range
-[<tt>before_begin()</tt>, <tt>end()</tt>).
- </blockquote>
- <p>
-That is, when it's dereferenceable, <tt>position</tt> must point
-into <tt>*this</tt>, not just any <tt>forward_list</tt> object.
- </p>
-
- <p><b>Proposed resolution:</b></p>
- <p>
+<hr>
+<h3><a name="1143"></a>1143. Response to US 87</h3>
+<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
-Change the <i>Requires</i> clause as follows:
+<p><b>Addresses US 87, UK 311</b></p>
- </p>
- <blockquote>
+<p>
+The atomics chapter is not concept enabled.
+</p>
+
+<p>
+Needs to also consider issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
-<i>Requires:</i> <tt>position</tt> is <ins>in the range
-[<tt>before_begin()</tt>, <tt>end()</tt>)</ins> <del>dereferenceable
-or equal to <tt>before_begin()</tt></del>.
- </blockquote>
-
<table>
<tbody><tr>
<td align="left">Doc. no.</td>
-<td align="left">N2729=08-0239</td>
+<td align="left">N2896=09-0086</td>
</tr>
<tr>
<td align="left">Date:</td>
-<td align="left">2008-08-24</td>
+<td align="left">2009-06-21</td>
</tr>
<tr>
<td align="left">Project:</td>
<td align="left">Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>></td>
</tr>
</tbody></table>
-<h1>C++ Standard Library Closed Issues List (Revision R59)</h1>
+<h1>C++ Standard Library Closed Issues List (Revision R65)</h1>
- <p>Reference ISO/IEC IS 14882:1998(E)</p>
+ <p>Reference ISO/IEC IS 14882:2003(E)</p>
<p>Also see:</p>
<ul>
<li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
<h2>Revision History</h2>
<ul>
+<li>R65:
+2009-06-19 pre-Frankfurt mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>378 open issues, up by 32.</li>
+<li>765 closed issues, up by 0.</li>
+<li>1143 issues total, up by 32.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1143">1143</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1112">1112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>.</li>
+<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</a>.</li>
+<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>.</li>
+<li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#568">568</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#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</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>.</li>
+<li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>.</li>
+<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#988">988</a>.</li>
+<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#884">884</a>.</li>
+<li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.</li>
+<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>.</li>
+<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>.</li>
+<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R64:
+2009-05-01 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>346 open issues, up by 19.</li>
+<li>765 closed issues, up by 0.</li>
+<li>1111 issues total, up by 19.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</a>.</li>
+<li>Changed the following issues from DR to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#406">406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#434">434</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438">438</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#444">444</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#455">455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#469">469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>.</li>
+<li>Changed the following issues from Review to New: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R63:
+2009-03-20 post-Summit mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>327 open issues, up by 96.</li>
+<li>765 closed issues, up by 14.</li>
+<li>1092 issues total, up by 110.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1022">1022</a>.</li>
+<li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1089">1089</a>.</li>
+<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li>
+<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#988">988</a>.</li>
+<li>Changed the following issues from New to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>.</li>
+<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>.</li>
+<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>.</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#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</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#683">683</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
+<li>Changed the following issues from Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
+<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#466">466</a>.</li>
+<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#219">219</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>.</li>
+<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>.</li>
+<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>.</li>
+<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>.</li>
+<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>.</li>
+<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>.</li>
+<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</a>.</li>
+<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R62:
+2009-02-06 pre-Summit mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>231 open issues, up by 44.</li>
+<li>751 closed issues, up by 0.</li>
+<li>982 issues total, up by 44.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R61:
+2008-12-05 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>187 open issues, up by 20.</li>
+<li>751 closed issues, up by 0.</li>
+<li>938 issues total, up by 20.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R60:
+2008-10-03 post-San Francisco mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>167 open issues, down by 25.</li>
+<li>751 closed issues, up by 65.</li>
+<li>918 issues total, up by 40.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#896">896</a>.</li>
+<li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
+<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
+<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</a>.</li>
+<li>Changed the following issues from New to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>.</li>
+<li>Changed the following issues from Ready to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
+<li>Changed the following issues from Review to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>.</li>
+<li>Changed the following issues from WP to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#44">44</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#167">167</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#231">231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#239">239</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#240">240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#282">282</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#291">291</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#300">300</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#305">305</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#310">310</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#315">315</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#316">316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#318">318</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#319">319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#320">320</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#321">321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#324">324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#325">325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#328">328</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#331">331</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#333">333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#337">337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#338">338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#340">340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#341">341</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#345">345</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#346">346</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#349">349</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#352">352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#354">354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#355">355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#358">358</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#359">359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#360">360</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#363">363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#364">364</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#365">365</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#370">370</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#373">373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#375">375</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#379">379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#380">380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#381">381</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#391">391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#395">395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#400">400</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#403">403</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#405">405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#410">410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#411">411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#414">414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#415">415</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#420">420</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#425">425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#426">426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#428">428</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#435">435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#436">436</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#442">442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#443">443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#448">448</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#449">449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
+<li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>.</li>
+<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</a>.</li>
+<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
+<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#872">872</a>.</li>
+<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#742">742</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</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#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
+<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>.</li>
+<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
+<li>Changed the following issues from TC to TC1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1">1</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#7">7</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#11">11</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#13">13</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#14">14</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#15">15</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#16">16</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#18">18</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#20">20</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#21">21</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#27">27</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#30">30</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#32">32</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#34">34</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#35">35</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#36">36</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#37">37</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#39">39</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#40">40</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#42">42</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#46">46</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#47">47</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#48">48</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50">50</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#51">51</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#52">52</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#53">53</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#54">54</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#56">56</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#57">57</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#59">59</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#62">62</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#66">66</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#68">68</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#71">71</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#74">74</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#78">78</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#79">79</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#80">80</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#90">90</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#106">106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#124">124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#125">125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#141">141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#148">148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#150">150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#151">151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#152">152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#154">154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#155">155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#156">156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#158">158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#161">161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#168">168</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#169">169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#174">174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#175">175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#176">176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.</li>
+</ul></li>
+</ul>
+</li>
<li>R59:
2008-08-22 pre-San Francisco mailing.
<ul>
<li>878 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
</ul></li>
</ul>
</li>
<li>869 issues total, up by 8.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
-<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li>
+<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>.</li>
</ul></li>
</ul>
</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li>
+<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li>
-<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
-<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>.</li>
+<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
+<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
+<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>.</li>
+<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
</ul></li>
</ul>
</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-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li>
+<li>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-
defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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><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 New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li>
<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 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-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
-<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
-<li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
+<li>Changed the following issues from 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-
defects.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-
defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
+<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-
defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
+<li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
<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-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>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-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li>
<li>Changed the following issues from 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>
<li>754 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.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-defects.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-closed.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-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
<li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
<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-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
</ul></li>
</ul>
</li>
<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-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>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-
defects.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-closed.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-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 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-
closed.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-active.html#644">644</a>.</li>
<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
<li>696 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
<li>Added the following 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>
<li>676 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
+<li>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-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>.</li>
<li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li>
-<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.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-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 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-
active.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-active.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
<li>656 issues total, up by 37.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
+<li>Changed the following issues from 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-
active.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>
<li>619 issues total, up by 10.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
</ul></li>
</ul>
</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#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-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#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-
closed.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>
+<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-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</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#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li>
</ul></li>
</ul>
</li>
<li>592 issues total, up by 5.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
</ul></li>
</ul>
</li>
<li>587 issues total, up by 13.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li>
<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.</li>
</ul></li>
<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-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-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>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-active.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-
defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
<li>566 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a> ,<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
<li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
</ul></li>
<li>535 issues total.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
</ul></li>
</ul>
</li>
</li>
<li>R38:
2005-07-03 pre-Mont Tremblant mailing.
-Merged open TR1 issues in <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-active.html#522">522</a>.
+Merged open TR1 issues in <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-defects.html#522">522</a>.
Added new issues <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-active.html#523">523</a>
</li>
<li>R37:
</li>
<li>R36:
2005-04 post-Lillehammer mailing. All issues in "ready" status except
-for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues
+for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> were moved to "DR" status, and all issues
previously in "DR" status were moved to "WP".
</li>
<li>R35:
<li>R24:
Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
meeting. All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
-moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
+moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
at the meeting.) Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
</li>
to Ready.
Closed issues
-<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#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
as NAD.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>. Reopened
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>. Reopened
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.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-active.html#128">128</a>,
</li>
<li>R4:
post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
issues corrected. (22 Oct 98)
</li>
<li>R3:
<hr>
<h3><a name="2"></a>2. Auto_ptr conversions effects incorrect</h3>
<p><b>Section:</b> D.9.1.3 [auto.ptr.conv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1997-12-04</p>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1997-12-04 <b>Last modified:</b> 2006-12-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 1 in "Effects", says "Calls
<p><b>Proposed resolution:</b></p>
-<p>Change 20.5.4.3 [meta.unary.prop] paragraph 1 Effects from
+<p>Change 20.6.4.3 [meta.unary.prop] paragraph 1 Effects from
"Calls p->release()" to "Calls p.release()".</p>
<hr>
<h3><a name="4"></a>4. Basic_string size_type and difference_type should be implementation defined</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#NAD">NAD</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</p>
+<p><b>Section:</b> 21.
4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1997-11-16 <b>Last modified:</b> 2006-12-27</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>In Morristown we changed the size_type and difference_type typedefs
for all the other containers to implementation defined with a
-reference to 23.1 [container.requirements]. This should probably also have been
+reference to 23.2 [container.requirements]. This should probably also have been
done for strings. </p>
<hr>
<h3><a name="6"></a>6. File position not an offset unimplementable</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#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-15</p>
+<p><b>Section:</b> 27.
5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-15 <b>Last modified:</b> 2006-12-27</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="10"></a>10. Codecvt<>::do unclear</h3>
-<p><b>Section:</b> 22.
2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-14</p>
+<p><b>Section:</b> 22.
4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-14 <b>Last modified:</b> 2006-12-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</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#19">19</a></p>
<hr>
<h3><a name="12"></a>12. Way objects hold allocators unclear</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#NAD">NAD</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1998-02-23</p>
+<p><b>Section:</b>
X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1998-02-23 <b>Last modified:</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#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#NAD">NAD</a> status.</p>
<p><b>Rationale:</b></p>
<p>Not a defect. The LWG believes that the Standard is already
-clear. See 23.1 [container.requirements], paragraph 8.</p>
+clear. See 23.2 [container.requirements], paragraph 8.</p>
<hr>
<h3><a name="43"></a>43. Locale table correction</h3>
-<p><b>Section:</b> 22.
2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1998-06-01</p>
+<p><b>Section:</b> 22.
4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Brendan Kehoe <b>Opened:</b> 1998-06-01 <b>Last modified:</b> 2006-12-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</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#33">33</a></p>
<hr>
<h3><a name="45"></a>45. Stringstreams read/write pointers initial position unclear</h3>
-<p><b>Section:</b> 27.
7.3 [ostringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matthias Mueller <b>Date:</b> 1998-05-27</p>
+<p><b>Section:</b> 27.
8.3 [ostringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Matthias Mueller <b>Opened:</b> 1998-05-27 <b>Last modified:</b> 2006-12-27</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 a comp.lang.c++.moderated Matthias Mueller wrote:</p>
-<p>"We are not sure how to interpret the CD2 (see 27.2
-[iostream.forward], 27.7.3.1 [ostringstream.cons], 27.7.1.1
+<p>"We are not sure how to interpret the CD2 (see 27.3
+[iostream.forward], 27.8.3.1 [ostringstream.cons], 27.8.1.1
[stringbuf.cons])
with respect to the question as to what the correct initial positions
of the write and read pointers of a stringstream should
<hr>
<h3><a name="58"></a>58. Extracting a char from a wide-oriented stream</h3>
-<p><b>Section:</b> 27.
6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-01</p>
+<p><b>Section:</b> 27.
7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-01 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</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="65"></a>65. Underspecification of strstreambuf::seekoff</h3>
<p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-18</p>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-18 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</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="67"></a>67. Setw useless for strings</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#Dup">Dup</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-07-09</p>
+<p><b>Section:</b> 21.
4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-07-09 <b>Last modified:</b> 2006-12-30</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#Dup">Dup</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a></p>
<hr>
<h3><a name="72"></a>72. Do_convert phantom member function</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <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> 1998-08-24</p>
+<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <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>Opened:</b> 1998-08-24 <b>Last modified:</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#locale.codecvt">active issues</a> in [locale.codecvt].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</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#24">24</a></p>
<p><b>Discussion:</b></p>
-<p>In 22.2.1.4 [locale.codecvt] par 3, and in 22.2.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function
+<p>In 22.4.1.4 [locale.codecvt] par 3, and in 22.4.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function
"do_convert" is mentioned. This member was replaced with
"do_in" and "do_out", the proper referents in the
contexts above.</p>
<hr>
<h3><a name="73"></a>73. <tt>is_open</tt> should be const</h3>
-<p><b>Section:</b> 27.
8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-27</p>
+<p><b>Section:</b> 27.
9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-27 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="77"></a>77. Valarray operator[] const returning value</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#Dup">Dup</a>
- <b>Submitter:</b> Levente Farkas <b>Date:</b> 1998-09-09</p>
+<p><b>Section:</b> 26.
6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Levente Farkas <b>Opened:</b> 1998-09-09 <b>Last modified:</b> 2007-10-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#Dup">Dup</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a></p>
way. That is what valarray was designed to do; that's where the
"value array" name comes from. LWG members further comment
that "we don't want valarray to be a full STL container."
-26.5.2.3 [valarray.access] specifies properties that indicate "an
+26.6.2.3 [valarray.access] specifies properties that indicate "an
absence of aliasing" for non-constant arrays; this allows
optimizations, including special hardware optimizations, that are not
otherwise possible. </p>
<hr>
<h3><a name="81"></a>81. Wrong declaration of slice operations</h3>
-<p><b>Section:</b> 26.
5.5 [template.slice.array], 26.5.7 [template.gslice.array], 26.5.8 [template.mask.array], 26.5.9 [template.indirect.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+<p><b>Section:</b> 26.
6.5 [template.slice.array], 26.6.7 [template.gslice.array], 26.6.8 [template.mask.array], 26.6.9 [template.indirect.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.slice.array">issues</a> in [template.slice.array].</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="82"></a>82. Missing constant for set elements</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2007-01-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="84"></a>84. Ambiguity with string::insert()</h3>
-<p><b>Section:</b> 21.
3.5 [string.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+<p><b>Section:</b> 21.
4.5 [string.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-27</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 I try</p>
<hr>
<h3><a name="85"></a>85. String char types</h3>
<p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</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><b>Rationale:</b></p>
-<p>There is already wording in 21.1 [char.traits] paragraph 3 that
+<p>There is already wording in 21.2 [char.traits] paragraph 3 that
requires them to be the same.</p>
<hr>
<h3><a name="87"></a>87. Error in description of string::compare()</h3>
-<p><b>Section:</b> 21.
3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+<p><b>Section:</b> 21.
4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</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#5">5</a></p>
<hr>
<h3><a name="88"></a>88. Inconsistency between string::insert() and string::append()</h3>
-<p><b>Section:</b> 21.
3.6.4 [string::insert], 21.3.6.2 [string::append] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+<p><b>Section:</b> 21.
4.6.4 [string::insert], 21.4.6.2 [string::append] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</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="89"></a>89. Missing throw specification for string::insert() and string::replace()</h3>
-<p><b>Section:</b> 21.
3.6.4 [string::insert], 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+<p><b>Section:</b> 21.
4.6.4 [string::insert], 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</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#83">83</a></p>
<hr>
<h3><a name="93"></a>93. Incomplete Valarray Subset Definitions</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#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+<p><b>Section:</b> 26.
6 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-29</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="94"></a>94. May library implementors add template parameters to Standard Library classes?</h3>
-<p><b>Section:</b> 17.
4.4 [conforming] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</p>
+<p><b>Section:</b> 17.
6.4 [conforming] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-22 <b>Last modified:</b> 2006-12-27</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>Is it a permitted extension for library implementors to add template parameters to
<p><b>Proposed resolution:</b></p>
-<p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.9 [res.on.exception.handling]:</p>
+<p>Add a new subclause [presumably 17.4.4.9] following 17.6.4.10 [res.on.exception.handling]:</p>
<blockquote>
<p>17.4.4.9 Template Parameters</p> <p>A specialization of a
</blockquote>
<p>Add "template parameters" to the list of subclauses at
-the end of 17.4.4 [conforming] paragraph 1.</p>
+the end of 17.6.4 [conforming] paragraph 1.</p>
<p><i>[Kona: The LWG agreed the standard needs clarification. After
discussion with John Spicer, it seems added template parameters can be
<hr>
<h3><a name="95"></a>95. Members added by the implementation</h3>
-<p><b>Section:</b> 17.
4.4.4 [member.functions] <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>Section:</b> 17.
6.4.5 [member.functions] <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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2006-12-27</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 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual
<p><b>Rationale:</b></p>
<p>This is not a defect in the Standard. The example is already
-illegal. See 17.4.4.4 [member.functions] paragraph 2.</p>
+illegal. See 17.6.4.5 [member.functions] paragraph 2.</p>
<hr>
<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>
+ <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2006-12-27</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>
<hr>
<h3><a name="99"></a>99. Reverse_iterator comparisons completely wrong</h3>
-<p><b>Section:</b> 24.
4.1.3.13 [reverse.iter.op==] <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>Section:</b> 24.
5.1.2.13 [reverse.iter.op==] <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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2006-12-27</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 <, >, <=, >= comparison operator are wrong: they
<hr>
<h3><a name="100"></a>100. Insert iterators/ostream_iterators overconstrained</h3>
-<p><b>Section:</b> 24.4.2 [insert.iterators], 24.5.4 [ostreambuf.iterator] <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>Section:</b> 24.7 [insert.iterators], 24.6.4 [ostreambuf.iterator] <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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2006-12-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#insert.iterators">active issues</a> in [insert.iterators].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.iterators].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>Overspecified For an insert iterator it, the expression *it is
<hr>
<h3><a name="101"></a>101. No way to free storage for vector and deque</h3>
-<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>Section:</b> 23.
3.6 [vector], 23.3.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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2007-02-19</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>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="102"></a>102. Bug in insert range in associative containers</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</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#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a></p>
<hr>
<h3><a name="104"></a>104. Description of basic_string::operator[] is unclear</h3>
-<p><b>Section:</b> 21.
3.4 [string.capacity] <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>Section:</b> 21.
4.4 [string.capacity] <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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.capacity">issues</a> in [string.capacity].</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="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#Dup">Dup</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
+<p><b>Section:</b> 27.
9 [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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2008-01-05</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>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a></p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="107"></a>107. Valarray constructor is strange</h3>
-<p><b>Section:</b> 26.
5.2 [template.valarray] <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>Section:</b> 26.
6.2 [template.valarray] <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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2006-12-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.valarray">issues</a> in [template.valarray].</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="111"></a>111. istreambuf_iterator::equal overspecified, inefficient</h3>
-<p><b>Section:</b> 24.5.3.5 [istreambuf.iterator::equal] <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> Nathan Myers <b>Date:</b> 1998-10-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>Discussion:</b></p>
-<p>The member istreambuf_iterator<>::equal is specified to be
-unnecessarily inefficient. While this does not affect the efficiency
-of conforming implementations of iostreams, because they can
-"reach into" the iterators and bypass this function, it does
-affect users who use istreambuf_iterators. </p>
-
-<p>The inefficiency results from a too-scrupulous definition, which
-requires a "true" result if neither iterator is at eof. In
-practice these iterators can only usefully be compared with the
-"eof" value, so the extra test implied provides no benefit,
-but slows down users' code. </p>
-
-<p>The solution is to weaken the requirement on the function to return
-true only if both iterators are at eof. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace 24.5.3.5 [istreambuf.iterator::equal],
-paragraph 1, </p>
-
-<blockquote>
- <p>-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at
- end-of-stream, regardless of what streambuf object they use. </p>
-</blockquote>
-
-<p>with</p>
-
-<blockquote>
- <p>-1- Returns: true if and only if both iterators are at
- end-of-stream, regardless of what streambuf object they use. </p>
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>It is not clear that this is a genuine defect. Additionally, the
-LWG was reluctant to make a change that would result in
-operator== not being a equivalence relation. One consequence of
-this change is that an algorithm that's passed the range [i, i)
-would no longer treat it as an empty range.</p>
-
-
-
-
-
-<hr>
<h3><a name="113"></a>113. Missing/extra iostream sync semantics</h3>
-<p><b>Section:</b> 27.
6.1.1 [istream], 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-10-13</p>
+<p><b>Section:</b> 27.
7.1.1 [istream], 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-10-13 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream">issues</a> in [istream].</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="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#Dup">Dup</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-11-06</p>
+<p><b>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-11-06 <b>Last modified:</b> 2008-03-14</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#Dup">Dup</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a></p>
<p><b>Proposed resolution:</b></p>
-<p>Add to 23.3.5 [template.bitset] a bitset constructor declaration</p>
+<p>Add to 20.3.6 [template.bitset] a bitset constructor declaration</p>
<blockquote>
<pre>explicit bitset(const char*);</pre>
</blockquote>
-<p>and in Section 23.3.5.1 [bitset.cons] add:</p>
+<p>and in Section 20.3.6.1 [bitset.cons] add:</p>
<blockquote>
<pre>explicit bitset(const char* str);</pre>
<hr>
<h3><a name="121"></a>121. Detailed definition for ctype<wchar_t> specialization</h3>
-<p><b>Section:</b> 22.
1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
+<p><b>Section:</b> 22.
3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</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>Section 22.1.1.1.1 has the following listed in Table 51: ctype<char> ,
ctype<wchar_t>. </p>
-<p>Also Section 22.2.1.1 [locale.ctype] says: </p>
+<p>Also Section 22.4.1.1 [locale.ctype] says: </p>
<blockquote>
<p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype<char> and
native character set. </p>
</blockquote>
-<p>However, Section 22.2.1.3 [facet.ctype.special]
+<p>However, Section 22.4.1.3 [facet.ctype.special]
only has a detailed description of the ctype<char> specialization, not the
ctype<wchar_t> specialization. </p>
<p><b>Proposed resolution:</b></p>
<p>Add the ctype<wchar_t> detailed class description to Section
-22.2.1.3 [facet.ctype.special]. </p>
+22.4.1.3 [facet.ctype.special]. </p>
<p><b>Rationale:</b></p>
<hr>
<h3><a name="131"></a>131. list::splice throws nothing</h3>
-<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>Section:</b> 23.
3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2007-02-19</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>
<hr>
<h3><a name="135"></a>135. basic_iostream doubly initialized</h3>
-<p><b>Section:</b> 27.
6.1.5.1 [iostream.cons] <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>Section:</b> 27.
7.1.5.1 [iostream.cons] <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>Opened:</b> 1999-03-06 <b>Last modified:</b> 2006-12-27</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>-1- Effects Constructs an object of class basic_iostream, assigning
<hr>
-<h3><a name="138"></a>138. Class ctype_byname<char> redundant and misleading</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <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-03-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</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>Section 22.2.1.4 [locale.codecvt] specifies that
-ctype_byname<char> must be a specialization of the ctype_byname
-template.</p>
-
-<p>It is common practice in the standard that specializations of class templates are only
-mentioned where the interface of the specialization deviates from the interface of the
-template that it is a specialization of. Otherwise, the fact whether or not a required
-instantiation is an actual instantiation or a specialization is left open as an
-implementation detail. </p>
-
-<p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The
-fact, that ctype_byname<char> is specified as a specialization suggests that there
-must be something "special" about it, but it has the exact same interface as the
-ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best
-redundant, at worst misleading - unless I am missing anything. </p>
-
-<p>Naturally, an implementation will most likely implement ctype_byname<char> as a
-specialization, because the base class ctype<char> is a specialization with an
-interface different from the ctype template, but that's an implementation detail and need
-not be mentioned in the standard. </p>
-
-
-<p><b>Rationale:</b></p>
-<p> The standard as written is mildly misleading, but the correct fix
-is to deal with the underlying problem in the ctype_byname base class,
-not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
-
-
-
-
-<hr>
<h3><a name="140"></a>140. map<Key, T>::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%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Mark Mitchell <b>Date:</b> 1999-04-14</p>
+<p><b>Section:</b> 23.
4.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>Opened:</b> 1999-04-14 <b>Last modified:</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#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%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<blockquote>
- <p>23.1 [container.requirements]<br>
+ <p>23.2 [container.requirements]<br>
<br>
expression return type
pre/post-condition<br>
T is assignable<br>
<br>
- 23.3.1 [map]<br>
+ 23.4.1 [map]<br>
<br>
A map satisfies all the requirements of a container.<br>
<br>
<hr>
<h3><a name="143"></a>143. C .h header wording unclear</h3>
<p><b>Section:</b> D.5 [depr.c.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Christophe de Dinechin <b>Date:</b> 1999-05-04</p>
+ <b>Submitter:</b> Christophe de Dinechin <b>Opened:</b> 1999-05-04 <b>Last modified:</b> 2006-12-27</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>[depr.c.headers] paragraph 2 reads:</p>
<hr>
<h3><a name="145"></a>145. adjustfield lacks default value</h3>
-<p><b>Section:</b> 27.
4.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-05-12</p>
+<p><b>Section:</b> 27.
5.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-05-12 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Rationale:</b></p>
<p>This is not a defect. It is deliberate that the default is no bits
-set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.</p>
-
-
-
-
-<hr>
-<h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-06-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Suppose that c and c1 are sequential containers and i is an
-iterator that refers to an element of c. Then I can insert a copy of
-c1's elements into c ahead of element i by executing </p>
-
-<blockquote>
-
-<pre>c.insert(i, c1.begin(), c1.end());</pre>
-
-</blockquote>
-
-<p>If c is a vector, it is fairly easy for me to find out where the
-newly inserted elements are, even though i is now invalid: </p>
-
-<blockquote>
-
-<pre>size_t i_loc = i - c.begin();
-c.insert(i, c1.begin(), c1.end());</pre>
-
-</blockquote>
-
-<p>and now the first inserted element is at c.begin()+i_loc and one
-past the last is at c.begin()+i_loc+c1.size().<br>
-<br>
-But what if c is a list? I can still find the location of one past the
-last inserted element, because i is still valid. To find the location
-of the first inserted element, though, I must execute something like </p>
-
-<blockquote>
-
-<pre>for (size_t n = c1.size(); n; --n)
- --i;</pre>
-
-</blockquote>
-
-<p>because i is now no longer a random-access iterator.<br>
-<br>
-Alternatively, I might write something like </p>
-
-<blockquote>
-
-<pre>bool first = i == c.begin();
-list<T>::iterator j = i;
-if (!first) --j;
-c.insert(i, c1.begin(), c1.end());
-if (first)
- j = c.begin();
-else
- ++j;</pre>
-
-</blockquote>
-
-<p>which, although wretched, requires less overhead.<br>
-<br>
-But I think the right solution is to change the definition of insert
-so that instead of returning void, it returns an iterator that refers
-to the first element inserted, if any, and otherwise is a copy of its
-first argument. </p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes this was an intentional design decision and so is
-not a defect. It may be worth revisiting for the next standard.</p>
+set. Consider Arabic or Hebrew, for example. See 22.4.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.</p>
<hr>
<h3><a name="157"></a>157. Meaningless error handling for <tt>pword()</tt> and <tt>iword()</tt></h3>
-<p><b>Section:</b> 27.
4.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
+<p><b>Section:</b> 27.
5.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2007-01-15</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</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#41">41</a></p>
<p><b>Discussion:</b></p>
-<p>According to paragraphs 2 and 4 of 27.4.2.5 [ios.base.storage], the
+<p>According to paragraphs 2 and 4 of 27.5.2.5 [ios.base.storage], the
functions <tt>iword()</tt> and <tt>pword()</tt> "set the
<tt>badbit</tt> (which might throw an exception)" on
failure. ... but what does it mean for <tt>ios_base</tt> to set the
<hr>
<h3><a name="162"></a>162. Really "formatted input functions"?</h3>
-<p><b>Section:</b> 27.
6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
+<p><b>Section:</b> 27.
7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2007-01-15</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</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#60">60</a></p>
function" but since these functions are defined in a section
labeled "Formatted input functions" it is unclear to me
whether these operators are considered formatted input functions which
-have to conform to the "common requirements" from 27.6.1.2.1
+have to conform to the "common requirements" from 27.7.1.2.1
[istream.formatted.reqmts]: If this is the case, all manipulators, not
just
<tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is set
<hr>
<h3><a name="163"></a>163. Return of <tt>gcount()</tt> after a call to <tt>gcount</tt></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#Dup">Dup</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
+<p><b>Section:</b> 27.
7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2007-01-15</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#Dup">Dup</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
<p><b>Discussion:</b></p>
<p>It is not clear which functions are to be considered unformatted
-input functions. As written, it seems that all functions in 27.6.1.3
+input functions. As written, it seems that all functions in 27.7.1.3
[istream.unformatted] are unformatted input functions. However, it does
not
really make much sense to construct a sentry object for
<hr>
<h3><a name="166"></a>166. Really "formatted output functions"?</h3>
-<p><b>Section:</b> 27.
6.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
+<p><b>Section:</b> 27.
7.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2007-01-15</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#60">60</a></p>
<p><b>Discussion:</b></p>
-<p>From 27.6.2.6.1 [ostream.formatted.reqmts] it appears that all the functions
-defined in 27.6.2.6.3 [ostream.inserters] have to construct a
+<p>From 27.7.2.6.1 [ostream.formatted.reqmts] it appears that all the functions
+defined in 27.7.2.6.3 [ostream.inserters] have to construct a
<tt>sentry</tt> object. Is this really intended?</p>
<p>This is basically the same problem as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a> but
<hr>
<h3><a name="177"></a>177. Complex operators cannot be explicitly instantiated</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#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1999-07-02</p>
+<p><b>Section:</b> 26.
4.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 1999-07-02 <b>Last modified:</b> 2006-12-27</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="178"></a>178. Should clog and cerr initially be tied to cout?</h3>
-<p><b>Section:</b> 27.
3.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1999-07-02</p>
+<p><b>Section:</b> 27.
4.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 1999-07-02 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#narrow.stream.objects">issues</a> in [narrow.stream.objects].</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="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">NAD</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 1999-08-15</p>
+<p><b>Section:</b> 26.
6.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>Opened:</b> 1999-08-15 <b>Last modified:</b> 2008-03-11</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
<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>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1999-10-10</p>
+<p><b>Section:</b> 25.
5.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1999-10-10 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.binary.search">issues</a> in [alg.binary.search].</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="192"></a>192. a.insert(p,t) is inefficient and overconstrained</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-06</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Ed Brey <b>Opened:</b> 1999-06-06 <b>Last modified:</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#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
<p><b>Proposed resolution:</b></p>
-<p>In 23.1.4 [associative.reqmts] paragraph 7, replace the row in table 69
+<p>In 23.2.4 [associative.reqmts] paragraph 7, replace the row in table 69
for a.insert(p,t) with the following two rows:</p>
<table border="1" cellpadding="5">
<tbody><tr>
<hr>
<h3><a name="194"></a>194. rdbuf() functions poorly specified</h3>
-<p><b>Section:</b> 27.
4.4 [ios] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1999-09-07</p>
+<p><b>Section:</b> 27.
5.4 [ios] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1999-09-07 <b>Last modified:</b> 2006-12-27</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 classic iostreams, base class ios had an rdbuf function that returned a
<tt> rdbuf()</tt> will return the "current streambuf" if that has been changed by the variant you mention.</p>
<p>Permission is not required to add such an extension. See
-17.4.4.4 [member.functions].</p>
+17.6.4.5 [member.functions].</p>
<hr>
<h3><a name="196"></a>196. Placement new example has alignment problems</h3>
-<p><b>Section:</b> 18.
5.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Herb Sutter <b>Date:</b> 1998-12-15</p>
+<p><b>Section:</b> 18.
6.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Herb Sutter <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2006-12-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</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#114">114</a></p>
<p><b>Discussion:</b></p>
-<p>The example in 18.5.1.3 [new.delete.placement] paragraph 4 reads: </p>
+<p>The example in 18.6.1.3 [new.delete.placement] paragraph 4 reads: </p>
<blockquote>
<hr>
<h3><a name="197"></a>197. max_size() underspecified</h3>
-<p><b>Section:</b>
20.1.2 [allocator.requirements], 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1999-10-21</p>
+<p><b>Section:</b>
X [allocator.requirements], 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 1999-10-21 <b>Last modified:</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#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#NAD">NAD</a> status.</p>
<hr>
<h3><a name="203"></a>203. basic_istream::sentry::sentry() is uninstantiable with ctype<user-defined type></h3>
-<p><b>Section:</b> 27.
6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt McClure and Dietmar Kühl <b>Date:</b> 2000-01-01</p>
+<p><b>Section:</b> 27.
7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Matt McClure and Dietmar Kühl <b>Opened:</b> 2000-01-01 <b>Last modified:</b> 2007-01-15</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="204"></a>204. distance(first, last) when "last" is before "first"</h3>
-<p><b>Section:</b> 24.3.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Rintala Matti <b>Date:</b> 2000-01-28</p>
+<p><b>Section:</b> 24.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Rintala Matti <b>Opened:</b> 2000-01-28 <b>Last modified:</b> 2008-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>Section 24.3.4 describes the function distance(first, last) (where first and
<p><b>Rationale:</b></p>
-<p>"Reachable" is defined in the standard in 24.1 [iterator.requirements] paragraph 6.
+<p>"Reachable" is defined in the standard in 24.2 [iterator.concepts] paragraph 6.
The definition is only in terms of operator++(). The LWG sees no defect in
the standard.</p>
<hr>
<h3><a name="205"></a>205. numeric_limits unclear on how to determine floating point types</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#NAD">NAD</a>
- <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-01-28</p>
+<p><b>Section:</b> 18.
3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-01-28 <b>Last modified:</b> 2006-12-27</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In several places in 18.2.1.2 [numeric.limits.members], a member is
+<p>In several places in 18.3.1.2 [numeric.limits.members], a member is
described as "Meaningful for all floating point types."
However, no clear method of determining a floating point type is
provided.</p>
-<p>In 18.2.1.5 [numeric.special], paragraph 1 states ". . . (for
+<p>In 18.3.1.5 [numeric.special], paragraph 1 states ". . . (for
example, epsilon() is only meaningful if is_integer is
false). . ." which suggests that a type is a floating point type
if is_specialized is true and is_integer is false; however, this is
<hr>
<h3><a name="207"></a>207. ctype<char> members return clause incomplete</h3>
-<p><b>Section:</b> 22.
2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Robert Klarer <b>Date:</b> 1999-11-02</p>
+<p><b>Section:</b> 22.
4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Robert Klarer <b>Opened:</b> 1999-11-02 <b>Last modified:</b> 2006-12-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.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>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a></p>
<p><b>Proposed resolution:</b></p>
-<p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members]
+<p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members]
paragraph 10 from:</p>
<p> Returns: do_widen(low, high, to).</p>
<p> Returns: do_widen(c) or do_widen(low, high, to),
respectively.</p>
-<p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] paragraph 11
+<p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members] paragraph 11
from:</p>
<p> Returns: do_narrow(low, high, to).</p>
<hr>
<h3><a name="213"></a>213. Math function overloads ambiguous</h3>
-<p><b>Section:</b> 26.
7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p>
+<p><b>Section:</b> 26.
8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 2000-02-26 <b>Last modified:</b> 2006-12-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="215"></a>215. Can a map's key_type be const?</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-29</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-02-29 <b>Last modified:</b> 2006-12-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Rationale:</b></p>
<p>The "key is assignable" requirement from table 69 in
-23.1.4 [associative.reqmts] already implies the key cannot be const.</p>
+23.2.4 [associative.reqmts] already implies the key cannot be const.</p>
<hr>
<h3><a name="216"></a>216. setbase manipulator description flawed</h3>
-<p><b>Section:</b> 27.
6.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Hyman Rosen <b>Date:</b> 2000-02-29</p>
+<p><b>Section:</b> 27.
7.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Hyman Rosen <b>Opened:</b> 2000-02-29 <b>Last modified:</b> 2006-12-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#std.manip">issues</a> in [std.manip].</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#193">193</a></p>
<p><b>Discussion:</b></p>
-<p>27.6.3 [std.manip] paragraph 5 says:</p>
+<p>27.7.3 [std.manip] paragraph 5 says:</p>
<blockquote>
<pre>smanip setbase(int base);</pre>
<p> Returns: An object s of unspecified type such that if out is an
<hr>
<h3><a name="218"></a>218. Algorithms do not use binary predicate objects for default comparisons</h3>
-<p><b>Section:</b> 25.
3 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p>
+<p><b>Section:</b> 25.
5 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2000-03-06 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
-<h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3>
-<p><b>Section:</b> 25.1.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
- <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The find function always searches for a value using operator== to compare the
-value argument to each element in the input iterator range. This is inconsistent
-with other find-related functions such as find_end and find_first_of, which
-allow the caller to specify a binary predicate object to be used for determining
-equality. The fact that this can be accomplished using a combination of find_if
-and bind_1st or bind_2nd does not negate the desirability of a consistent,
-simple, alternative interface to find.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<blockquote>
-<p>In section 25.1.5 [alg.find], add a second prototype for find
-(between the existing prototype and the prototype for find_if), as
-follows:</p>
-<pre> template<class InputIterator, class T, class BinaryPredicate>
- InputIterator find(InputIterator first, InputIterator last,
- const T& value, BinaryPredicate bin_pred);</pre>
-<p>Change the description of the return from:</p>
-<blockquote>
- <p>Returns: The first iterator i in the range [first, last) for which the following corresponding
- conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p>
-</blockquote>
-<p> to:</p>
-<blockquote>
- <p>Returns: The first iterator i in the range [first, last) for which the following
- corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
- != false. Return last if no such iterator is found.</p>
-</blockquote>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>This is request for a pure extension, so it is not a defect in the
-current standard. As the submitter pointed out, "this can
-be accomplished using a combination of find_if and bind_1st or
-bind_2nd".</p>
-
-
-
-
-<hr>
<h3><a name="236"></a>236. ctype<char>::is() member modifies facet</h3>
-<p><b>Section:</b> 22.
2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
+<p><b>Section:</b> 22.
4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2007-01-15</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.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>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a></p>
<p><b>Discussion:</b></p>
-<p>The description of the <tt>is()</tt> member in paragraph 4 of 22.2.1.3.2 [facet.ctype.char.members] is broken: According to this description, the
+<p>The description of the <tt>is()</tt> member in paragraph 4 of 22.4.1.3.2 [facet.ctype.char.members] is broken: According to this description, the
second form of the <tt>is()</tt> method modifies the masks in the
<tt>ctype</tt> object. The correct semantics if, of course, to obtain
an array of masks. The corresponding method in the general case,
-ie. the <tt>do_is()</tt> method as described in 22.2.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.</p>
+ie. the <tt>do_is()</tt> method as described in 22.4.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.</p>
<p><b>Proposed resolution:</b></p>
<hr>
<h3><a name="244"></a>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3>
-<p><b>Section:</b> 25.
1.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</p>
+<p><b>Section:</b> 25.
3.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-05-02 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<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>Section:</b> 24.
6.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>Opened:</b> 2000-05-02 <b>Last modified:</b> 2006-12-27</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>
<hr>
<h3><a name="246"></a>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Mark Rodgers <b>Date:</b> 2000-05-19</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Mark Rodgers <b>Opened:</b> 2000-05-19 <b>Last modified:</b> 2007-01-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
<hr>
<h3><a name="249"></a>249. Return Type of <tt>auto_ptr::operator=</tt></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> Joseph Gottman <b>Date:</b> 2000-06-30</p>
+ <b>Submitter:</b> Joseph Gottman <b>Opened:</b> 2000-06-30 <b>Last modified:</b> 2006-12-29</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#auto.ptr">active issues</a> in [auto.ptr].</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="257"></a>257. STL functional object and iterator inheritance.</h3>
-<p><b>Section:</b> 20.
6.3 [base], 24.3.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Robert Dick <b>Date:</b> 2000-08-17</p>
+<p><b>Section:</b> 20.
7.3 [base], D.10.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Robert Dick <b>Opened:</b> 2000-08-17 <b>Last modified:</b> 2006-12-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="267"></a>267. interaction of strstreambuf::overflow() and seekoff()</h3>
<p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <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> 2000-10-05</p>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-10-05 <b>Last modified:</b> 2007-01-15</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</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="269"></a>269. cstdarg and unnamed parameters</h3>
-<p><b>Section:</b> 18.
7 [support.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> J. Stephen Adamczyk <b>Date:</b> 2000-10-10</p>
+<p><b>Section:</b> 18.
8 [support.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> J. Stephen Adamczyk <b>Opened:</b> 2000-10-10 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.exception">issues</a> in [support.exception].</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="277"></a>277. Normative encouragement in allocator requirements unclear</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#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-11-07</p>
+<p><b>Section:</b>
X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-11-07 <b>Last modified:</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#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#NAD">NAD</a> status.</p>
<hr>
<h3><a name="279"></a>279. const and non-const iterators should have equivalent typedefs</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#NAD">NAD</a>
- <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-11-27</p>
+<p><b>Section:</b> 23.
2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-11-27 <b>Last modified:</b> 2006-12-27</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#NAD">NAD</a> status.</p>
<p><b>Proposed resolution:</b></p>
<p>
-In <b>Section:</b> 23.1 [container.requirements],
+In <b>Section:</b> 23.2 [container.requirements],
table 65, in the assertion/note pre/post condition for X::const_iterator,
add the following:
</p>
<hr>
<h3><a name="287"></a>287. conflicting ios_base fmtflags</h3>
-<p><b>Section:</b> 27.
4.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
+<p><b>Section:</b> 27.
5.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fmtflags.state">issues</a> in [fmtflags.state].</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>
<tt>oct</tt>). These fields are used by locale facets. The LWG
reviewed the way in which each of those three fields is used, and
believes that in each case the behavior is well defined for any
-possible combination of bits. See for example Table 58, in 22.2.2.2.2
+possible combination of bits. See for example Table 58, in 22.4.2.2.2
[facet.num.put.virtuals], noting the requirement in paragraph 6 of that
section.
</p>
<hr>
<h3><a name="289"></a>289. <cmath> requirements missing C float and long double versions</h3>
-<p><b>Section:</b> 26.
7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
+<p><b>Section:</b> 26.
8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30 <b>Last modified:</b> 2007-01-15</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="293"></a>293. Order of execution in transform algorithm</h3>
-<p><b>Section:</b> 25.
2.4 [alg.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-04</p>
+<p><b>Section:</b> 25.
4.4 [alg.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2001-01-04 <b>Last modified:</b> 2007-01-15</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.transform">issues</a> in [alg.transform].</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="296"></a>296. Missing descriptions and requirements of pair operators</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-14</p>
+<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-14 <b>Last modified:</b> 2006-12-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
-<p>The synopsis of the header <tt><utility></tt> in 20.2 [utility]
+<p>The synopsis of the header <tt><utility></tt> in 20.3 [utility]
lists the complete set of equality and relational operators for <tt>pair</tt>
but the section describing the template and the operators only describes
<tt>operator==()</tt> and <tt>operator<()</tt>, and it fails to mention
<p><b>Rationale:</b></p>
-<p>20.2.1 [operators] paragraph 10 already specifies the semantics.
+<p>20.3.1 [operators] paragraph 10 already specifies the semantics.
That paragraph says that, if declarations of operator!=, operator>,
operator<=, and operator>= appear without definitions, they are
-defined as specified in 20.2.1 [operators]. There should be no user
+defined as specified in 20.3.1 [operators]. There should be no user
confusion, since that paragraph happens to immediately precede the
specification of <tt>pair</tt>.</p>
<hr>
+<h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
+<p><b>Section:</b> 24.2.5 [bidirectional.iterators], 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> John Potter <b>Opened:</b> 2001-01-22 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In section 24.2.5 [bidirectional.iterators],
+Table 75 gives the return type of *r-- as convertible to T. This is
+not consistent with Table 74 which gives the return type of *r++ as
+T&. *r++ = t is valid while *r-- = t is invalid.
+</p>
+
+<p>
+In section 24.2.6 [random.access.iterators],
+Table 76 gives the return type of a[n] as convertible to T. This is
+not consistent with the semantics of *(a + n) which returns T& by
+Table 74. *(a + n) = t is valid while a[n] = t is invalid.
+</p>
+
+<p>
+Discussion from the Copenhagen meeting: the first part is
+uncontroversial. The second part, operator[] for Random Access
+Iterators, requires more thought. There are reasonable arguments on
+both sides. Return by value from operator[] enables some potentially
+useful iterators, e.g. a random access "iota iterator" (a.k.a
+"counting iterator" or "int iterator"). There isn't any obvious way
+to do this with return-by-reference, since the reference would be to a
+temporary. On the other hand, <tt>reverse_iterator</tt> takes an
+arbitrary Random Access Iterator as template argument, and its
+operator[] returns by reference. If we decided that the return type
+in Table 76 was correct, we would have to change
+<tt>reverse_iterator</tt>. This change would probably affect user
+code.
+</p>
+
+<p>
+History: the contradiction between <tt>reverse_iterator</tt> and the
+Random Access Iterator requirements has been present from an early
+stage. In both the STL proposal adopted by the committee
+(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
+Stepanov and Lee), the Random Access Iterator requirements say that
+operator[]'s return value is "convertible to T". In N0527
+reverse_iterator's operator[] returns by value, but in HPL-95-11
+(R.1), and in the STL implementation that HP released to the public,
+reverse_iterator's operator[] returns by reference. In 1995, the
+standard was amended to reflect the contents of HPL-95-11 (R.1). The
+original intent for operator[] is unclear.
+</p>
+
+<p>
+In the long term it may be desirable to add more fine-grained
+iterator requirements, so that access method and traversal strategy
+can be decoupled. (See "Improved Iterator Categories and
+Requirements", N1297 = 01-0011, by Jeremy Siek.) Any decisions
+about issue 299 should keep this possibility in mind.
+</p>
+
+<p>Further discussion: I propose a compromise between John Potter's
+resolution, which requires <tt>T&</tt> as the return type of
+<tt>a[n]</tt>, and the current wording, which requires convertible to
+<tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
+for the return type of the expression <tt>a[n]</tt>, but to also add
+<tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
+common case uses of random access iterators, while at the same time
+allowing iterators such as counting iterator and caching file
+iterators to remain random access iterators (iterators where the
+lifetime of the object returned by <tt>operator*()</tt> is tied to the
+lifetime of the iterator).
+</p>
+
+<p>
+Note that the compromise resolution necessitates a change to
+<tt>reverse_iterator</tt>. It would need to use a proxy to support
+<tt>a[n] = t</tt>.
+</p>
+
+<p>
+Note also there is one kind of mutable random access iterator that
+will no longer meet the new requirements. Currently, iterators that
+return an r-value from <tt>operator[]</tt> meet the requirements for a
+mutable random access iterartor, even though the expression <tt>a[n] =
+t</tt> will only modify a temporary that goes away. With this proposed
+resolution, <tt>a[n] = t</tt> will be required to have the same
+operational semantics as <tt>*(a + n) = t</tt>.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+In section 24.1.4 [lib.bidirectdional.iterators], change the return
+type in table 75 from "convertible to <tt>T</tt>" to
+<tt>T&</tt>.
+</p>
+
+<p>
+In section 24.1.5 [lib.random.access.iterators], change the
+operational semantics for <tt>a[n]</tt> to " the r-value of
+<tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
+n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
+with a return type of convertible to <tt>T</tt> and operational semantics of
+<tt>*(a + n) = t</tt>.
+</p>
+
+<p><i>[Lillehammer: Real problem, but should be addressed as part of
+ iterator redesign]</i></p>
+
+
+
+
+<p><b>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2758.pdf">N2758</a>.
+</blockquote>
+
+
+
+
+
+
+
+<hr>
<h3><a name="302"></a>302. Need error indication from codecvt<>::do_length</h3>
-<p><b>Section:</b> 22.
2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Gregory Bumgardner <b>Date:</b> 2001-01-25</p>
+<p><b>Section:</b> 22.
4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Gregory Bumgardner <b>Opened:</b> 2001-01-25 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</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="304"></a>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</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#NAD">NAD</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-02-05</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>Section:</b> 24.
2 [iterator.concepts] <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>Opened:</b> 2001-02-05 <b>Last modified:</b> 2008-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="313"></a>313. set_terminate and set_unexpected question</h3>
-<p><b>Section:</b> 18.
7.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2001-04-03</p>
+<p><b>Section:</b> 18.
8.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 2001-04-03 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</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="314"></a>314. Is the stack unwound when terminate() is called?</h3>
-<p><b>Section:</b> 18.
7.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-04-11</p>
+<p><b>Section:</b> 18.
8.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-04-11 <b>Last modified:</b> 2007-01-15</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</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="323"></a>323. abs() overloads in different headers</h3>
-<p><b>Section:</b> 26.
7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-04</p>
+<p><b>Section:</b> 26.
8 [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>Opened:</b> 2001-06-04 <b>Last modified:</b> 2008-03-12</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="326"></a>326. Missing typedef in moneypunct_byname</h3>
-<p><b>Section:</b> 22.
2.6.4 [locale.moneypunct.byname] <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> 2001-07-05</p>
+<p><b>Section:</b> 22.
4.6.4 [locale.moneypunct.byname] <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>Opened:</b> 2001-07-05 <b>Last modified:</b> 2006-12-27</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 definition of the moneypunct facet contains the typedefs char_type
<p><b>Proposed resolution:</b></p>
<p>For consistency with the numpunct facet, add a typedef for
char_type to the definition of the moneypunct_byname facet in
-22.2.6.4 [locale.moneypunct.byname].</p>
+22.4.6.4 [locale.moneypunct.byname].</p>
<p><b>Rationale:</b></p>
<hr>
<h3><a name="330"></a>330. Misleading "exposition only" value in class locale definition</h3>
-<p><b>Section:</b> 22.
1.1 [locale] <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> 2001-07-15</p>
+<p><b>Section:</b> 22.
3.1 [locale] <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>Opened:</b> 2001-07-15 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</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 LWG agrees that it may be difficult to implement locale member
functions in such a way that they can take either <tt>category</tt>
arguments or the LC_ constants defined in <cctype>. In light of
-this requirement (22.1.1.1.1 [locale.category], paragraph 2), and in light
+this requirement (22.3.1.1.1 [locale.category], paragraph 2), and in light
of the requirement in the preceding paragraph that it is possible to
combine <tt>category</tt> bitmask elements with bitwise operations,
defining the <tt>category</tt> elements is delicate,
<hr>
<h3><a name="332"></a>332. Consider adding increment and decrement operators to std::fpos< T > </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#NAD">NAD</a>
- <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-27</p>
+<p><b>Section:</b> 27.
5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-27 <b>Last modified:</b> 2006-12-27</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Increment and decrement operators are missing from
-Table 88 -- Position type requirements in 27.4.3 [fpos].
+Table 88 -- Position type requirements in 27.5.3 [fpos].
</p>
<hr>
<h3><a name="344"></a>344. grouping + showbase</h3>
-<p><b>Section:</b> 22.
2.2 [category.numeric] <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> 2001-10-13</p>
+<p><b>Section:</b> 22.
4.2 [category.numeric] <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>Opened:</b> 2001-10-13 <b>Last modified:</b> 2007-01-15</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><b>Proposed resolution:</b></p>
<p>
-Insert into 22.2.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last
+Insert into 22.4.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last
sentence:
</p>
<blockquote><p>
<hr>
<h3><a name="348"></a>348. Minor issue with std::pair operator<</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#Dup">Dup</a>
- <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-10-23</p>
+<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-10-23 <b>Last modified:</b> 2008-01-05</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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>Proposed resolution:</b></p>
-<p>In 20.2.3 [pairs] paragraph 6, replace:</p>
+<p>In 20.3.3 [pairs] paragraph 6, replace:</p>
<pre> Returns: x.first < y.first || (!(y.first < x.first) && x.second <
y.second).
</pre>
<hr>
<h3><a name="350"></a>350. allocator<>::address</h3>
-<p><b>Section:</b> 20.
7.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 2001-10-25</p>
+<p><b>Section:</b> 20.
8.6.1 [allocator.members], X [allocator.requirements], 17.6.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>Opened:</b> 2001-10-25 <b>Last modified:</b> 2007-10-11</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>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a></p>
<p><b>Rationale:</b></p>
<p>The LWG believes both examples are ill-formed. The contained type
-is required to be CopyConstructible (20.1.1 [utility.arg.requirements]), and that
+is required to be CopyConstructible (X [utility.arg.requirements]), and that
includes the requirement that &t return the usual types and
values. Since allocators are intended to be used in conjunction with
containers, and since the CopyConstructible requirements appear to
<hr>
<h3><a name="351"></a>351. unary_negate and binary_negate: struct or class?</h3>
-<p><b>Section:</b> 20.
6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Dale Riley <b>Date:</b> 2001-11-12</p>
+<p><b>Section:</b> 20.
7 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Dale Riley <b>Opened:</b> 2001-11-12 <b>Last modified:</b> 2007-04-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In 20.6 [function.objects] the header <functional> synopsis declares
+In 20.7 [function.objects] the header <functional> synopsis declares
the unary_negate and binary_negate function objects as struct.
-However in 20.6.10 [negators] the unary_negate and binary_negate
+However in 20.7.11 [negators] the unary_negate and binary_negate
function objects are defined as class. Given the context, they are
not "basic function objects" like negate, so this is either a typo or
an editorial oversight.
<p><b>Proposed resolution:</b></p>
-<p>Change the synopsis to reflect the useage in 20.6.10 [negators]</p>
+<p>Change the synopsis to reflect the useage in 20.7.11 [negators]</p>
<p><i>[Curaçao: Since the language permits "struct", the LWG
views this as NAD. They suggest, however, that the Project Editor
<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%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-12-02</p>
+<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-12-02 <b>Last modified:</b> 2008-01-05</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="356"></a>356. Meaning of ctype_base::mask enumerators</h3>
-<p><b>Section:</b> 22.
2.1 [category.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-01-23</p>
+<p><b>Section:</b> 22.
4.1 [category.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-01-23 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#category.ctype">issues</a> in [category.ctype].</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>
<tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
say that a character is both a space and a printing character is to or
those two enumerators together. This is suggested by the "exposition
-only" values in 22.2.1 [category.ctype], but it is nowhere specified in
+only" values in 22.4.1 [category.ctype], but it is nowhere specified in
normative text. An alternative interpretation is that the more
specific categories subsume the less specific. The above program
gives the results it does on the Microsoft compiler because, on that
<hr>
<h3><a name="357"></a>357. <cmath> float functions cannot return HUGE_VAL</h3>
-<p><b>Section:</b> 26.
7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-02-26</p>
+<p><b>Section:</b> 26.
8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-02-26 <b>Last modified:</b> 2007-04-24</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>
<hr>
<h3><a name="361"></a>361. num_get<>::do_get (..., void*&) checks grouping</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#NAD">NAD</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
+<p><b>Section:</b> 22.
4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2007-01-15</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="366"></a>366. Excessive const-qualification</h3>
<p><b>Section:</b> 27 [input.output] <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, Marc Paterno <b>Date:</b> 2002-05-10</p>
+ <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10 <b>Last modified:</b> 2006-12-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</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="367"></a>367. remove_copy/remove_copy_if and Input Iterators</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#NAD">NAD</a>
- <b>Submitter:</b> Anthony Williams <b>Date:</b> 2002-05-13</p>
+<p><b>Section:</b> 25.
4.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2002-05-13 <b>Last modified:</b> 2006-12-27</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-remove_copy and remove_copy_if (25.2.8 [alg.remove]) permit their
+remove_copy and remove_copy_if (25.4.8 [alg.remove]) permit their
input range to be marked with Input Iterators. However, since two
operations are required against the elements to copy (comparison and
assigment), when the input range uses Input Iterators, a temporary
Add "If InputIterator does not meet the requirements of forward
iterator, then the value type of InputIterator must be copy
constructible. Otherwise copy constructible is not required." to
-25.2.8 [alg.remove] paragraph 6.
+25.4.8 [alg.remove] paragraph 6.
</p>
<hr>
<h3><a name="368"></a>368. basic_string::replace has two "Throws" paragraphs</h3>
-<p><b>Section:</b> 21.
3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2002-06-03</p>
+<p><b>Section:</b> 21.
4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2002-06-03 <b>Last modified:</b> 2007-04-24</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>
-21.3.6.6 [string::replace] basic_string::replace, second
+21.4.6.6 [string::replace] basic_string::replace, second
signature, given in paragraph 1, has two "Throws" paragraphs (3 and
5).
</p>
<hr>
<h3><a name="372"></a>372. Inconsistent description of stdlib exceptions</h3>
-<p><b>Section:</b> 17.
4.4.9 [res.on.exception.handling], 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Randy Maddox <b>Date:</b> 2002-07-22</p>
+<p><b>Section:</b> 17.
6.4.10 [res.on.exception.handling], 18.7.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Randy Maddox <b>Opened:</b> 2002-07-22 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
-<p>Paragraph 3 under clause 17.4.4.9 [res.on.exception.handling], Restrictions on
+<p>Paragraph 3 under clause 17.6.4.10 [res.on.exception.handling], Restrictions on
Exception Handling, states that "Any other functions defined in the
C++ Standard Library that do not have an exception-specification may
throw implementation-defined exceptions unless otherwise specified."
from) the standard exceptions."</p>
<p>These statements appear to be in direct contradiction to clause
-18.6.1 [type.info], which states "The class exception defines the
+18.7.1 [type.info], which states "The class exception defines the
base class for the types of objects thrown as exceptions by the C++
Standard library components ...".</p>
<hr>
<h3><a name="374"></a>374. moneypunct::frac_digits returns int not unsigned</h3>
-<p><b>Section:</b> 22.
2.6.3.1 [locale.moneypunct.members], 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#NAD">NAD</a>
- <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-08</p>
+<p><b>Section:</b> 22.
4.6.3.1 [locale.moneypunct.members], 22.4.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-08 <b>Last modified:</b> 2006-12-27</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 22.2.6.3.1 [locale.moneypunct.members], frac_digits() returns type
+In section 22.4.6.3.1 [locale.moneypunct.members], frac_digits() returns type
"int". This implies that frac_digits() might return a negative value,
but a negative value is nonsensical. It should return "unsigned".
</p>
<p>
-Similarly, in section 22.2.6.3.2 [locale.moneypunct.virtuals], do_frac_digits()
+Similarly, in section 22.4.6.3.2 [locale.moneypunct.virtuals], do_frac_digits()
should return "unsigned".
</p>
<hr>
<h3><a name="377"></a>377. basic_string::insert and length_error</h3>
-<p><b>Section:</b> 21.
3.6.4 [string::insert] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-16</p>
+<p><b>Section:</b> 21.
4.6.4 [string::insert] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-16 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</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>
-Section 21.3.6.4 [string::insert], paragraph 4, contains the following,
+Section 21.4.6.4 [string::insert], paragraph 4, contains the following,
"Then throws length_error if size() >= npos - rlen."
</p>
<hr>
<h3><a name="378"></a>378. locale immutability and locale::operator=()</h3>
-<p><b>Section:</b> 22.
1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
+<p><b>Section:</b> 22.
3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2006-12-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</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#31">31</a></p>
<hr>
<h3><a name="385"></a>385. Does call by value imply the CopyConstructible requirement?</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">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-10-23</p>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-10-23 <b>Last modified:</b> 2007-04-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Many function templates have parameters that are passed by value;
a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in
-25.1.5 [alg.find]. Are the corresponding template parameters
+25.3.5 [alg.find]. Are the corresponding template parameters
(<tt>Predicate</tt> in this case) implicitly required to be
CopyConstructible, or does that need to be spelled out explicitly?
</p>
<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">NAD</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
+<p><b>Section:</b> 26.
4 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08 <b>Last modified:</b> 2008-02-27</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">NAD</a> status.</p>
<p><b>Discussion:</b></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%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>Section:</b> X [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>Opened:</b> 2002-10-24 <b>Last modified:</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#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%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="392"></a>392. 'equivalence' for input iterators</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">NAD</a>
- <b>Submitter:</b> Corwin Joy <b>Date:</b> 2002-12-11</p>
+<p><b>Section:</b> 24.
2.2 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Corwin Joy <b>Opened:</b> 2002-12-11 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In section 24.1.1 [input.iterators] table 72 -
+In section 24.2.2 [input.iterators] table 72 -
'Input Iterator Requirements' we have as a postcondition of *a:
"If a==b and (a, b) is in the domain of == then *a is equivalent to *b".
</p>
<p>
-In section 24.5.3.5 [istreambuf.iterator::equal] it states that
+In section 24.6.3.5 [istreambuf.iterator::equal] it states that
"istreambuf_iterator::equal returns true if and only if both iterators
are at end-of-stream, or neither is at end-of-stream, <i>regardless of
what streambuf object they use</i>." (My emphasis).
<p>
The defect is that either 'equivalent' needs to be more precisely
-defined or the conditions for equality in 24.5.3.5 [istreambuf.iterator::equal]
+defined or the conditions for equality in 24.6.3.5 [istreambuf.iterator::equal]
are incorrect. (Or both).
</p>
</pre>
<p>Now assuming that neither f1 or f2 are at the end-of-stream then
-f1 == f2 by 24.5.3.5 [istreambuf.iterator::equal].</p>
+f1 == f2 by 24.6.3.5 [istreambuf.iterator::equal].</p>
<p>However, it is unlikely that *f1 will give the same value as *f2 except
by accident.</p>
<hr>
<h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3>
-<p><b>Section:</b> 22.
2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Alberto Barbati <b>Date:</b> 2002-12-24</p>
+<p><b>Section:</b> 22.
4.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Alberto Barbati <b>Opened:</b> 2002-12-24 <b>Last modified:</b> 2008-07-02</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#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Proposed resolution:</b></p>
<p>
-Add a note at the end of 22.2.1.4.2 [locale.codecvt.virtuals],
+Add a note at the end of 22.4.1.4.2 [locale.codecvt.virtuals],
paragraph 3:
</p>
<hr>
<h3><a name="399"></a>399. volations of unformatted input function requirements</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#NAD">NAD</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
+<p><b>Section:</b> 27.
7.1.3 [istream.unformatted] <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>Opened:</b> 2003-01-05 <b>Last modified:</b> 2006-12-27</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<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.7.5.1 [allocator.members], p3,<br>
-20.7.5.1 [allocator.members], p10,<br>
-21.3.2 [string.cons], p11,<br>
-22.1.1.2 [locale.cons], p11,<br>
-23.2.2.3 [deque.modifiers], p2,<br>
-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.4 [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>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<p><b>Section:</b> 27.
5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2006-12-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a></p>
<hr>
<h3><a name="433"></a>433. Contradiction in specification of unexpected()</h3>
-<p><b>Section:</b> 18.
7.2.4 [unexpected] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Vyatcheslav Sysoltsev <b>Date:</b> 2003-09-29</p>
+<p><b>Section:</b> 18.
8.2.4 [unexpected] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Vyatcheslav Sysoltsev <b>Opened:</b> 2003-09-29 <b>Last modified:</b> 2006-12-27</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>
<hr>
<h3><a name="437"></a>437. Formatted output of function pointers is confusing</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#NAD">NAD</a>
- <b>Submitter:</b> Ivan Godard <b>Date:</b> 2003-10-24</p>
+<p><b>Section:</b> 27.
7.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Ivan Godard <b>Opened:</b> 2003-10-24 <b>Last modified:</b> 2006-12-27</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="439"></a>439. Should facets be copyable?</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#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-11-02</p>
+<p><b>Section:</b> 22.
4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-11-02 <b>Last modified:</b> 2006-12-27</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#NAD">NAD</a> status.</p>
<hr>
<h3><a name="440"></a>440. Should std::complex use unqualified transcendentals?</h3>
-<p><b>Section:</b> 26.
3.8 [complex.transcendentals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-11-05</p>
+<p><b>Section:</b> 26.
4.8 [complex.transcendentals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-11-05 <b>Last modified:</b> 2009-03-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>
<p>This issue differs from valarray transcendentals in two important
ways. First, "the effect of instantiating the template
<tt>complex</tt> for types other than float, double or long double is
-unspecified." (26.3.1 [complex.synopsis]) Second, the standard does not
+unspecified." (26.4.1 [complex.syn]) Second, the standard does not
dictate implementation, so there is no guarantee that a particular
real math function is used in the implementation of a particular
complex function.</p>
<hr>
<h3><a name="447"></a>447. Wrong template argument for time facets</h3>
-<p><b>Section:</b> 22.
1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2003-12-26</p>
+<p><b>Section:</b> 22.
3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2003-12-26 <b>Last modified:</b> 2007-01-15</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</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#327">327</a></p>
<hr>
<h3><a name="450"></a>450. set::find is inconsistent with associative container requirements</h3>
-<p><b>Section:</b> 23.
3.3 [set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
+<p><b>Section:</b> 23.
4.3 [set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2009-05-01</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#set">issues</a> in [set].</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#214">214</a></p>
<p><b>Discussion:</b></p>
<p>map/multimap have:</p>
-<pre> iterator find(const key_type& x) const;
- const_iterator find(const key_type& x) const;
+<pre> iterator find(const key_type& x) const;
+ const_iterator find(const key_type& x) const;
</pre>
<p>
which is consistent with the table of associative container requirements.
But set/multiset have:
</p>
-<pre> iterator find(const key_type&) const;
+<pre> iterator find(const key_type&) const;
</pre>
<p>
<hr>
<h3><a name="451"></a>451. Associative erase should return an iterator</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts], 23.3 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts], 23.4 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2009-05-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a></p>
<p><b>Discussion:</b></p>
<p>map/multimap/set/multiset have:</p>
-<pre> void erase(iterator);
- void erase(iterator, iterator);
+<pre> void erase(iterator);
+ void erase(iterator, iterator);
</pre>
<p>But there's no good reason why these can't return an iterator, as for
vector/deque/list:</p>
-<pre> iterator erase(iterator);
- iterator erase(iterator, iterator);
+<pre> iterator erase(iterator);
+ iterator erase(iterator, iterator);
</pre>
<hr>
<h3><a name="452"></a>452. locale::combine should be permitted to generate a named locale</h3>
-<p><b>Section:</b> 22.
1.1.3 [locale.members] <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-01-30</p>
+<p><b>Section:</b> 22.
3.1.3 [locale.members] <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>Opened:</b> 2004-01-30 <b>Last modified:</b> 2009-05-01</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</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>
<pre>template<class Facet>
- locale::combine(const locale&) const;
+ locale::combine(const locale&) const;
</pre>
<p>
is obliged to create a locale that has no name. This is overspecification
<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#NAD">NAD</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-03-23</p>
+<h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3>
+<p><b>Section:</b> 27.9.1.4 [filebuf.members] <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>Opened:</b> 2004-01-30 <b>Last modified:</b> 2009-05-01</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#NAD">NAD</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>
-<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.
-</p>
+<pre> basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
+</pre>
+
+<p>should be supplemented with the overload:</p>
+
+<pre> basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
+</pre>
<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.
+Depending on the operating system, one of these forms is fundamental and
+the other requires an implementation-defined mapping to determine the
+actual filename.
</p>
-<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
+<p><i>[Sydney: Yes, we want to allow wchar_t filenames. Bill will
+ provide wording.]</i></p>
+
+
+<p><i>[
+In Toronto we noted that this is issue 5 from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm">N1569</a>.
+]</i></p>
+
+<p>
+How does this interact with the newly-defined character types, and how
+do we avoid interface explosion considering <tt>std::string</tt> overloads that
+were added? Propose another solution that is different than the
+suggestion proposed by PJP.
+</p>
+<p>
+Suggestion is to make a member template function for <tt>basic_string</tt> (for
+<tt>char</tt>, <tt>wchar_t</tt>, <tt>u16char</tt>, <tt>u32char</tt> instantiations), and then just keep a
+<tt>const char*</tt> member.
+</p>
+<p>
+Goal is to do implicit conversion between character string literals to
+appropriate <tt>basic_string</tt> type. Not quite sure if this is possible.
+</p>
+<p>
+Implementors are free to add specific overloads for non-char character
+types.
+</p>
+
+<p><i>[
+Martin adds pre-Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Please see <a href="http://wiki.dinkumware.com/twiki/pub/Wg21sophiaAntipolis/LibraryWorkingGroup/issue-454.html">issue 454: problems and solutions</a>.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Beman is concerned that making these changes to <tt>basic_filebuf</tt> is not
+usefully changed unless <tt>fstream</tt> is also changed; this also only handles
+<tt>wchar_t</tt> and not other character types.
+</p>
+<p>
+The TR2 filesystem library is a more complete solution, but is not available soon.
+</p>
+</blockquote>
+
+<p><i>[
+Martin adds: please reference
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2683.html">N2683</a> for
+problems and solutions.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>Change from:</p>
+<blockquote>
+<pre>basic_filebuf<charT,traits>* open(
+ const char* s,
+ ios_base::openmode mode );
+</pre>
+
+<p>
+Effects: If is_open() != false, returns a null pointer.
+Otherwise, initializes the filebuf as required. It then
+opens a file, if possible, whose name is the NTBS s ("as if"
+by calling std::fopen(s,modstr)).</p>
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+<pre>basic_filebuf<charT,traits>* open(
+ const char* s,
+ ios_base::openmode mode );
+
+basic_filebuf<charT,traits>* open(
+ const wchar_t* ws,
+ ios_base::openmode mode );
+</pre>
+
+<p>
+Effects: If is_open() != false, returns a null pointer.
+Otherwise, initializes the filebuf as required. It then
+opens a file, if possible, whose name is the NTBS s ("as if"
+by calling std::fopen(s,modstr)).
+For the second signature, the NTBS s is determined from the
+WCBS ws in an implementation-defined manner.
+</p>
+
+<p>
+(NOTE: For a system that "naturally" represents a filename
+as a WCBS, the NTBS s in the first signature may instead
+be mapped to a WCBS; if so, it follows the same mapping
+rules as the first argument to open.)
+</p>
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
+this to Ready. The controversy was because the mapping between wide
+names and files in a filesystem is implementation defined. The
+counterargument, which most but not all LWG members accepted, is that
+the mapping between narrow files names and files is also
+implemenation defined.</p>
+
+<p><i>[Lillehammer: Moved back to "open" status, at Beman's urging.
+(1) Why just basic_filebuf, instead of also basic_fstream (and
+possibly other things too). (2) Why not also constructors that take
+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>
+
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+Some existing implementations provide overload already. Expected
+filesystem "path" object overloads neatly, without surprises; implying
+NAD.
+</blockquote>
+
+
+
+
+
+
+
+<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.4 [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>Opened:</b> 2004-03-23 <b>Last modified:</b> 2008-02-25</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>
+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>
+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>
+
+<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>
<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:
-</p>
-
-<pre> #include <string>
- int main() { std::string( 0 ); }
-</pre>
-
-<p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
-Comeau online) compile the above without errors or warnings! The
-programs (at least for the GCC) resulted in a SEGV.</p>
-
-<p>I know that the standard explicitly states that the ctor of string
-requires a char* which is not zero. STLs could easily detect the above
-case with a private ctor for basic_string which takes a single 'int'
-argument. This would catch the above code at compile time and would not
-ambiguate any other legal ctors.</p>
-
-<p><i>[Redmond: No great enthusiasm for doing this. If we do,
- however, we want to do it for all places that take <tt>charT*</tt>
- pointers, not just the single-argument constructor. The other
- question is whether we want to catch this at compile time (in which
- case we catch the error of a literal 0, but not an expression whose
- value is a null pointer), at run time, or both.]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD. Relegate this functionality to debugging implementations.
-</p>
-
-
-
-
-
-<hr>
<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>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2007-04-18</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>
<hr>
<h3><a name="472"></a>472. Missing "Returns" clause in std::equal_range</h3>
-<p><b>Section:</b> 25.
3.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Prateek R Karandikar <b>Date:</b> 2004-06-30</p>
+<p><b>Section:</b> 25.
5.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Prateek R Karandikar <b>Opened:</b> 2004-06-30 <b>Last modified:</b> 2006-12-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#equal.range">issues</a> in [equal.range].</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#270">270</a></p>
<hr>
<h3><a name="476"></a>476. Forward Iterator implied mutability</h3>
-<p><b>Section:</b> 24.
1.3 [forward.iterators] <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> 2004-07-09</p>
+<p><b>Section:</b> 24.
2.4 [forward.iterators] <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>Opened:</b> 2004-07-09 <b>Last modified:</b> 2007-01-15</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</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="477"></a>477. Operator-> for const forward iterators</h3>
-<p><b>Section:</b> 24.
1.3 [forward.iterators] <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-07-11</p>
+<p><b>Section:</b> 24.
2.4 [forward.iterators] <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>Opened:</b> 2004-07-11 <b>Last modified:</b> 2007-01-15</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</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#478">478</a></p>
<hr>
<h3><a name="479"></a>479. Container requirements and placement new</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#Dup">Dup</a>
- <b>Submitter:</b> Herb Sutter <b>Date:</b> 2004-08-01</p>
+<p><b>Section:</b> 23.
2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2004-08-01 <b>Last modified:</b> 2007-04-18</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#Dup">Dup</a> status.</p>
<hr>
<h3><a name="480"></a>480. unary_function and binary_function should have protected nonvirtual destructors</h3>
-<p><b>Section:</b> 20.
6.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2004-08-19</p>
+<p><b>Section:</b> 20.
7.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2004-08-19 <b>Last modified:</b> 2006-12-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="481"></a>481. unique's effects on the range [result, last)</h3>
-<p><b>Section:</b> 25.2.9 [alg.unique] <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> 2004-08-30</p>
+<p><b>Section:</b> 25.4.9 [alg.unique] <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>Opened:</b> 2004-08-30 <b>Last modified:</b> 2006-12-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="482"></a>482. Swapping pairs</h3>
-<p><b>Section:</b> 20.2.3 [pairs], 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2004-09-14</p>
+<p><b>Section:</b> 20.3.3 [pairs], 20.5 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2004-09-14 <b>Last modified:</b> 2007-05-06</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p><i>[
Post Oxford: We got <tt>swap</tt> for <tt>pair</tt> but accidently
-missed <tt>tuple</tt>. <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
+missed <tt>tuple</tt>. <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>.
]</i></p>
<hr>
<h3><a name="483"></a>483. Heterogeneous equality and EqualityComparable</h3>
-<p><b>Section:</b> 25.
1 [alg.nonmodifying], 25.2 [alg.modifying.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2004-09-20</p>
+<p><b>Section:</b> 25.
3 [alg.nonmodifying], 25.4 [alg.modifying.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2004-09-20 <b>Last modified:</b> 2007-01-15</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#283">283</a></p>
<p><b>Discussion:</b></p>
<hr>
+<h3><a name="484"></a>484. Convertible to T</h3>
+<p><b>Section:</b> 24.2.2 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-09-16 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>From comp.std.c++:</p>
+
+<p>
+I note that given an input iterator a for type T,
+then *a only has to be "convertable to T", not actually of type T.
+</p>
+
+<p>Firstly, I can't seem to find an exact definition of "convertable to T".
+While I assume it is the obvious definition (an implicit conversion), I
+can't find an exact definition. Is there one?</p>
+
+<p>Slightly more worryingly, there doesn't seem to be any restriction on
+the this type, other than it is "convertable to T". Consider two input
+iterators a and b. I would personally assume that most people would
+expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
+the standard requires that, and that whatever type *a is (call it U)
+could have == defined on it with totally different symantics and still
+be a valid inputer iterator.</p>
+
+<p>Is this a correct reading? When using input iterators should I write
+T(*a) all over the place to be sure that the object i'm using is the
+class I expect?</p>
+
+<p>This is especially a nuisance for operations that are defined to be
+ "convertible to bool". (This is probably allowed so that
+ implementations could return say an int and avoid an unnessary
+ conversion. However all implementations I have seen simply return a
+ bool anyway. Typical implemtations of STL algorithms just write
+ things like <tt>while(a!=b && *a!=0)</tt>. But strictly
+ speaking, there are lots of types that are convertible to T but
+ that also overload the appropriate operators so this doesn't behave
+ as expected.</p>
+
+<p>If we want to make code like this legal (which most people seem to
+ expect), then we'll need to tighten up what we mean by "convertible
+ to T".</p>
+
+<p><i>[Lillehammer: The first part is NAD, since "convertible" is
+ well-defined in core. The second part is basically about pathological
+ overloads. It's a minor problem but a real one. So leave open for
+ now, hope we solve it as part of iterator redesign.]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+<p><b>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2758.pdf">N2758</a>.
+</blockquote>
+
+
+
+
+
+
+
+<hr>
<h3><a name="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>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-10-13 <b>Last modified:</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#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>
<hr>
<h3><a name="487"></a>487. Allocator::construct is too limiting</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#NAD">NAD</a>
- <b>Submitter:</b> Dhruv Matani <b>Date:</b> 2004-10-17</p>
+<p><b>Section:</b>
X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Dhruv Matani <b>Opened:</b> 2004-10-17 <b>Last modified:</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#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#NAD">NAD</a> status.</p>
<hr>
<h3><a name="489"></a>489. std::remove / std::remove_if wrongly specified</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#NAD">NAD</a>
- <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
+<p><b>Section:</b> 25.
4.8 [alg.remove] <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>Opened:</b> 2004-12-12 <b>Last modified:</b> 2006-12-27</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="490"></a>490. std::unique wrongly specified</h3>
-<p><b>Section:</b> 25.2.9 [alg.unique] <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>Section:</b> 25.4.9 [alg.unique] <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>Opened:</b> 2004-12-12 <b>Last modified:</b> 2006-12-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="491"></a>491. std::list<>::unique incorrectly specified</h3>
-<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>Section:</b> 23.
3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12 <b>Last modified:</b> 2007-02-19</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.4.4 [list.ops], paragraphs 19 to 21 describe the
+<p>In Section 23.3.4.4 [list.ops], paragraphs 19 to 21 describe the
behavior of the std::list<T, Allocator>::unique operation. However, the
current wording is defective for various reasons.</p>
1) Analysis of current wording:
</p>
-<p>23.2.4.4 [list.ops], paragraph 19:</p>
+<p>23.3.4.4 [list.ops], paragraph 19:</p>
<p>
Current wording says:
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.4.4 [list.ops], paragraph 15 does, would be clearer.</p>
+wording of 23.3.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,
of arguments for pred()) apply to this paragraph.</p>
<p>
-23.2.4.4 [list.ops], paragraph 20:
+23.3.4.4 [list.ops], paragraph 20:
</p>
<p>
</p>
<p>
-23.2.4.4 [list.ops], paragraph 21:</p>
+23.3.4.4 [list.ops], paragraph 21:</p>
<p>
Current wording says:
3) Proposed fixes:</p>
<p>
-Change 23.2.4.4 [list.ops], paragraph 19 to:</p>
+Change 23.3.4.4 [list.ops], paragraph 19 to:</p>
<p>
"Effect: Erases all but the first element from every consecutive group
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.4.4 [list.ops], paragraph
+This would also imply a change of 23.3.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
considered the first element."</p>
<p>
-Change 23.2.4.4 [list.ops], paragraph 20 to:</p>
+Change 23.3.4.4 [list.ops], paragraph 20 to:</p>
<p>
"Throws: Nothing unless an exception is thrown by *(i-1) == *i or
<p>
a) The wording regarding the conditions is identical to proposed
-23.2.4.4 [list.ops], paragraph 19. If 23.2.4.4 [list.ops],
+23.3.4.4 [list.ops], paragraph 19. If 23.3.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
c) Typos fixed.</p>
<p>
-Change 23.2.4.4 [list.ops], paragraph 21 to:</p>
+Change 23.3.4.4 [list.ops], paragraph 21 to:</p>
<p>
"Complexity: If empty() == false, exactly size() - 1 applications of the
<hr>
<h3><a name="493"></a>493. Undefined Expression in Input Iterator Note Title</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">NAD</a>
- <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-12-13</p>
+<p><b>Section:</b> 24.
2.2 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-12-13 <b>Last modified:</b> 2006-12-27</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="494"></a>494. Wrong runtime complexity for associative container's insert and delete</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Hans B os <b>Date:</b> 2004-12-19</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Hans B os <b>Opened:</b> 2004-12-19 <b>Last modified:</b> 2006-12-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="499"></a>499. Std. doesn't seem to require stable_sort() to be stable!</h3>
-<p><b>Section:</b> 25.
3.1.2 [stable.sort] <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> Prateek Karandikar <b>Date:</b> 2005-04-12</p>
+<p><b>Section:</b> 25.
5.1.2 [stable.sort] <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> Prateek Karandikar <b>Opened:</b> 2005-04-12 <b>Last modified:</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#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<blockquote><p>
<hr>
<h3><a name="500"></a>500. do_length cannot be implemented correctly</h3>
-<p><b>Section:</b> 22.
2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Krzysztof Żelechowski <b>Date:</b> 2005-05-24</p>
+<p><b>Section:</b> 22.
4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Krzysztof Żelechowski <b>Opened:</b> 2005-05-24 <b>Last modified:</b> 2008-03-13</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</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="501"></a>501. Proposal: strengthen guarantees of lib.comparisons</h3>
-<p><b>Section:</b> 20.
6.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Me <anti_spam_email2003@yahoo.com> <b>Date:</b> 2005-06-07</p>
+<p><b>Section:</b> 20.
7.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Me <anti_spam_email2003@yahoo.com> <b>Opened:</b> 2005-06-07 <b>Last modified:</b> 2008-03-13</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="504"></a>504. Integer types in pseudo-random number engine requirements</h3>
-<p><b>Section:</b>
26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
+<p><b>Section:</b>
X [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</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>
<hr>
<h3><a name="506"></a>506. Requirements of Distribution parameter for variate_generator</h3>
-<p><b>Section:</b> 26.4 [rand], TR1 5.1.3 [tr.rand.var] <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>Section:</b> 26.5 [rand], TR1 5.1.3 [tr.rand.var] <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>Opened:</b> 2005-07-03 <b>Last modified:</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#rand">active issues</a> in [rand].</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<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>Section:</b> 26.
5.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>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</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>
<hr>
<h3><a name="510"></a>510. Input_type for bernoulli_distribution</h3>
-<p><b>Section:</b> 26.
4.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] <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>Section:</b> 26.
5.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] <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>Opened:</b> 2005-07-03 <b>Last modified:</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="511"></a>511. Input_type for binomial_distribution</h3>
-<p><b>Section:</b> 26.
4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <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>Section:</b> 26.
5.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <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>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</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="512"></a>512. Seeding subtract_with_carry_01 from a single unsigned long</h3>
-<p><b>Section:</b> 26.
4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <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> Walter Brown <b>Date:</b> 2005-07-03</p>
+<p><b>Section:</b> 26.
5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <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> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</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>
<hr>
<h3><a name="513"></a>513. Size of state for subtract_with_carry_01</h3>
-<p><b>Section:</b> 26.
4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <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> Walter Brown <b>Date:</b> 2005-07-03</p>
+<p><b>Section:</b> 26.
5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <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> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</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>
<hr>
<h3><a name="514"></a>514. Size of state for subtract_with_carry</h3>
-<p><b>Section:</b> 26.
4.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] <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> Walter Brown <b>Date:</b> 2005-07-03</p>
+<p><b>Section:</b> 26.
5.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] <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> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</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#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="515"></a>515. Random number engine traits</h3>
-<p><b>Section:</b> 26.
4.2 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] <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>Section:</b> 26.
5.1 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] <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>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</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="516"></a>516. Seeding subtract_with_carry_01 using a generator</h3>
-<p><b>Section:</b> 26.
4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <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> Walter Brown <b>Date:</b> 2005-07-03</p>
+<p><b>Section:</b> 26.
5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <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> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</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>
<hr>
<h3><a name="517"></a>517. Should include name in external representation</h3>
-<p><b>Section:</b>
26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <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>Section:</b>
X [rand.req], TR1 5.1.1 [tr.rand.req] <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>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.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>
<hr>
<h3><a name="525"></a>525. type traits definitions not clear</h3>
-<p><b>Section:</b> 20.
5.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Robert Klarer <b>Date:</b> 2005-07-11</p>
+<p><b>Section:</b> 20.
6.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2005-07-11 <b>Last modified:</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#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="526"></a>526. Is it undefined if a function in the standard changes in parameters?</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2005-09-14</p>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2005-09-14 <b>Last modified:</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#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<li><tt>list::remove(value)</tt> is required to work because the standard
doesn't give permission for it not to work.</li>
<li><tt>vector::insert(iter, iter, iter)</tt> is not required to work because
-23.1.3 [sequence.reqmts], p4 says so.</li>
-<li><tt>copy</tt> has to work, except where 25.2.1 [alg.copy] says
+23.2.3 [sequence.reqmts], p4 says so.</li>
+<li><tt>copy</tt> has to work, except where 25.4.1 [alg.copy] says
it doesn't have to work. While a language lawyer can tear this wording apart,
it is felt that the wording is not prone to accidental interpretation.</li>
<li>The current working draft provide exceptions for the unordered associative
<hr>
<h3><a name="528"></a>528. <tt>const_iterator</tt> <tt>iterator</tt> issue when they are the same type</h3>
-<p><b>Section:</b> 23.4 [unord], TR1 6.3.4 [tr.unord.unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-10-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p>
+<p><b>Section:</b> 23.5 [unord], TR1 6.3.4 [tr.unord.unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2005-10-12 <b>Last modified:</b> 2008-03-13</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3>
-<p><b>Section:</b> 17.
4.3.10 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-10-25</p>
+<p><b>Section:</b> 17.
6.3.11 [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>Opened:</b> 2005-10-25 <b>Last modified:</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#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="532"></a>532. Tuple comparison</h3>
-<p><b>Section:</b> 20.4.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-11-29</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>Section:</b> 20.5.2.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2005-11-29 <b>Last modified:</b> 2008-09-23</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">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>
Recommend NAD. This will be fixed with the next revision of concepts.
</p>
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
+</blockquote>
+
<hr>
<h3><a name="536"></a>536. Container iterator constructor and explicit convertibility</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#Dup">Dup</a>
- <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2005-12-17</p>
+<p><b>Section:</b> 23.
2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Joaquín M López Muñoz <b>Opened:</b> 2005-12-17 <b>Last modified:</b> 2007-04-18</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#Dup">Dup</a> status.</p>
<hr>
<h3><a name="544"></a>544. minor NULL problems in C.2</h3>
<p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-11-25</p>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-11-25 <b>Last modified:</b> 2007-04-24</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="547"></a>547. division should be floating-point, not integer</h3>
-<p><b>Section:</b> 26.4 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
+<p><b>Section:</b> 26.5 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2007-04-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="548"></a>548. May random_device block?</h3>
-<p><b>Section:</b> 26.4.6 [rand.device], TR1 5.1.6 [tr.rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
+<p><b>Section:</b> 26.5.6 [rand.device], TR1 5.1.6 [tr.rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2007-10-18</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.device">issues</a> in [rand.device].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="549"></a>549. Undefined variable in binomial_distribution</h3>
-<p><b>Section:</b> 26.
4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <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> Matt Austern <b>Date:</b> 2006-01-10</p>
+<p><b>Section:</b> 26.
5.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <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> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2007-04-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</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>
<hr>
<h3><a name="553"></a>553. very minor editorial change intptr_t / uintptr_t</h3>
-<p><b>Section:</b> 18.
3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-01-30</p>
+<p><b>Section:</b> 18.
4.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-01-30 <b>Last modified:</b> 2007-07-02</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Proposed resolution:</b></p>
<p>
-Change 18.3.1 [cstdint.syn]:
+Change 18.4.1 [cstdint.syn]:
</p>
<blockquote><pre>...
<hr>
<h3><a name="554"></a>554. Problem with lwg DR 184 numeric_limits<bool></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#NAD">NAD</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-29</p>
+<p><b>Section:</b> 18.
3.1.5 [numeric.special] <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>Opened:</b> 2006-01-29 <b>Last modified:</b> 2007-01-15</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="555"></a>555. TR1, 8.21/1: typo</h3>
<p><b>Section:</b> TR1 8.21 [tr.c99.boolh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-02</p>
+ <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-02 <b>Last modified:</b> 2007-04-24</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>
<hr>
+<h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
+<p><b>Section:</b> 25.5 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-05 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In 25, p8 we allow BinaryPredicates to return a type that's convertible
+to bool but need not actually be bool. That allows predicates to return
+things like proxies and requires that implementations be careful about
+what kinds of expressions they use the result of the predicate in (e.g.,
+the expression in if (!pred(a, b)) need not be well-formed since the
+negation operator may be inaccessible or return a type that's not
+convertible to bool).
+</p>
+<p>
+Here's the text for reference:
+</p>
+<blockquote><p>
+ ...if an algorithm takes BinaryPredicate binary_pred as its argument
+ and first1 and first2 as its iterator arguments, it should work
+ correctly in the construct if (binary_pred(*first1, first2)){...}.
+</p></blockquote>
+
+<p>
+In 25.3, p2 we require that the Compare function object return true
+of false, which would seem to preclude such proxies. The relevant text
+is here:
+</p>
+<blockquote><p>
+ Compare is used as a function object which returns true if the first
+ argument is less than the second, and false otherwise...
+</p></blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+I think we could fix this by rewording 25.3, p2 to read somthing like:
+</p>
+<blockquote><p>
+-2- <tt>Compare</tt> is <del>used as a function object which returns
+<tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
+return value of the function call operator applied to an object of type
+<tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
+if the first argument of the call</ins> is less than the second, and
+<tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
+algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
+will not apply any non-constant function through the dereferenced iterator.
+</p></blockquote>
+
+
+<p><i>[
+Portland: Jack to define "convertible to bool" such that short circuiting isn't
+destroyed.
+]</i></p>
+
+
+<p><b>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+Solved by
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>).
+</blockquote>
+
+
+
+
+
+
+<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">NAD Editorial</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-06</p>
+<p><b>Section:</b> 18.
4 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-06 <b>Last modified:</b> 2008-07-02</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#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<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>
- <b>Submitter:</b> David Abrahams <b>Date:</b> 2006-02-09</p>
+<p><b>Section:</b> 24.
2.2 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2006-02-09 <b>Last modified:</b> 2007-04-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="560"></a>560. User-defined allocators without default constructor</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#NAD">NAD</a>
- <b>Submitter:</b> Sergey P. Derevyago <b>Date:</b> 2006-02-17</p>
+<p><b>Section:</b>
X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Sergey P. Derevyago <b>Opened:</b> 2006-02-17 <b>Last modified:</b> 2007-04-18</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#NAD">NAD</a> status.</p>
<hr>
<h3><a name="569"></a>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</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>
- <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-03-10</p>
+<p><b>Section:</b> 27.
5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2006-03-10 <b>Last modified:</b> 2006-12-30</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a></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#NAD">NAD</a>
- <b>Submitter:</b> Jack Reeves <b>Date:</b> 2006-04-06</p>
+<p><b>Section:</b> 21.
2 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Jack Reeves <b>Opened:</b> 2006-04-06 <b>Last modified:</b> 2008-06-18</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="571"></a>571. Update C90 references to C99?</h3>
<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-08</p>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-04-08 <b>Last modified:</b> 2007-07-02</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%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="572"></a>572. Oops, we gave 507 WP status</h3>
-<p><b>Section:</b> 26.4 [rand], TR1 5.1 [tr.rand] <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> 2006-04-11</p>
+<p><b>Section:</b> 26.5 [rand], TR1 5.1 [tr.rand] <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>Opened:</b> 2006-04-11 <b>Last modified:</b> 2007-04-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></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.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2006-06-13</p>
+<p><b>Section:</b> 23.
2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Joaquín M López Muñoz <b>Opened:</b> 2006-06-13 <b>Last modified:</b> 2008-03-12</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<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>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p>
+<p><b>Section:</b> 26.
8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-06-15 <b>Last modified:</b> 2007-07-25</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="584"></a>584. missing int pow(int,int) functionality</h3>
-<p><b>Section:</b> 26.
7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p>
+<p><b>Section:</b> 26.
8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-06-15 <b>Last modified:</b> 2007-07-25</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Rationale:</b></p>
-Toronto: We already have double pow(integral, integral) from 26.7 [c.math] p11.
+Toronto: We already have double pow(integral, integral) from 26.8 [c.math] p11.
<hr>
<h3><a name="587"></a>587. iststream ctor missing description</h3>
<p><b>Section:</b> D.7.2.1 [depr.istrstream.cons] <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> 2006-06-22</p>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-22 <b>Last modified:</b> 2007-05-11</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="590"></a>590. Type traits implementation latitude should be removed for C++0x</h3>
-<p><b>Section:</b> 20.5 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-08-10</p>
+<p><b>Section:</b> 20.6 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-08-10 <b>Last modified:</b> 2007-05-11</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="591"></a>591. Misleading "built-in</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#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> whyglinux <b>Date:</b> 2006-08-08</p>
+<p><b>Section:</b> 18.
3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> whyglinux <b>Opened:</b> 2006-08-08 <b>Last modified:</b> 2007-07-02</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#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<hr>
<h3><a name="592"></a>592. Incorrect treatment of rdbuf()->close() return type</h3>
-<p><b>Section:</b> 27.
8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Christopher Kohlhoff <b>Date:</b> 2006-08-17</p>
+<p><b>Section:</b> 27.
9.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2006-08-17 <b>Last modified:</b> 2008-07-02</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Proposed resolution:</b></p>
<p>
-Change 27.8.1.9 [ifstream.members], p5:
+Change 27.9.1.9 [ifstream.members], p5:
</p>
<blockquote><p>
</p></blockquote>
<p>
-Change 27.8.1.17 [fstream.members], p5:
+Change 27.9.1.17 [fstream.members], p5:
</p>
<blockquote><p>
<hr>
<h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</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%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> Niels Dekker <b>Date:</b> 2006-11-02</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>Section:</b> X [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> Niels Dekker <b>Opened:</b> 2006-11-02 <b>Last modified:</b> 2008-09-23</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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It seems undesirable to define the Swappable requirement in terms of
will essentially rewrite this section and provide the desired semantics.
</p>
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>.
+</blockquote>
+
<hr>
<h3><a name="615"></a>615. Inconsistencies in Section 21.4</h3>
-<p><b>Section:</b> 21.
5 [c.strings] <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> 2006-12-11</p>
+<p><b>Section:</b> 21.
6 [c.strings] <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>Opened:</b> 2006-12-11 <b>Last modified:</b> 2007-04-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</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>
<hr>
-<h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%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>
+<h3><a name="626"></a>626. new <i>Remark</i> clauses not documented</h3>
+<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2008-02-25</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</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>
-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
+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>)
-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.
+are not mentioned in 17.5.1.4 [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.5.1.2 [structure.summary], p2, and which they replace in many cases).
- </p><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.
+Propose add a bullet for <i>Remarks</i> along with a brief description.
- <p>
</p>
+<p><i>[
+Batavia: Alan and Pete to work.
+]</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>
-
-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>.
-
- <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 >
-size()</code>.
+<p><i>[
+Bellevue: Already resolved in current working paper.
+]</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 > size()</code> are strictly speaking
-unspecified.
-
- <p>
+<p><b>Proposed resolution:</b></p>
+<p>
+</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>
+<hr>
+<h3><a name="627"></a>627. Low memory and exceptions</h3>
+<p><b>Section:</b> 18.6.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>Opened:</b> 2007-01-23 <b>Last modified:</b> 2008-02-25</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.6.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>[
-Post-Sophia Antipolis: Martin indicates there is still work to be done on this issue.
-Reopened.
+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="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>
+<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#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> James Kanze <b>Opened:</b> 2007-01-31 <b>Last modified:</b> 2008-09-26</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#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
- <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>
-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).
+<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>
- <p>
+<p>
+In the description of <tt>upper_bound</tt> (25.5.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>
-Propose add a bullet for <i>Remarks</i> along with a brief description.
+<p>
+In the description of <tt>lexicographical_compare</tt>, we have both
+"<tt>*<i>first1</i> < *<i>first2</i></tt>" and "<tt>*<i>first2</i>
+< *<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>
<p><i>[
-Batavia: Alan and Pete to work.
+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><i>[
-Bellevue: Already resolved in current working paper.
-]</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>
-
-
-
-<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>.
+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>
+
+<p><b>Rationale:</b></p>
<p><i>[
-Bellevue: NAD. 1.4p2 specifies a program must behave correctly "within
-its resource limits", so no further escape hatch is necessary.
+post San Francisco:
]</i></p>
+<blockquote>
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2759.pdf">N2759</a>.
+</blockquote>
-<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.
6.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-03</p>
+<p><b>Section:</b> 20.
7.16.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>Opened:</b> 2007-02-03 <b>Last modified:</b> 2007-07-02</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.6.15.2.5 [func.wrap.func.targ], p4 says:
+20.7.16.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
<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.6.15.2.5 [func.wrap.func.targ], p1.
+void</tt> due to returns clause 20.7.16.2.5 [func.wrap.func.targ], p1.
</li>
</ol>
<p><b>Proposed resolution:</b></p>
<p>
-Change 20.6.15.2.5 [func.wrap.func.targ], p4:
+Change 20.7.16.2.5 [func.wrap.func.targ], p4:
</p>
<blockquote><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>Section:</b> 26.
6.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>Opened:</b> 2007-02-11 <b>Last modified:</b> 2007-07-02</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>
<hr>
<h3><a name="637"></a>637. [c.math]/10 inconsistent return values</h3>
-<p><b>Section:</b> 26.
7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-13</p>
+<p><b>Section:</b> 26.
8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-02-13 <b>Last modified:</b> 2007-07-26</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>
-26.7 [c.math], paragraph 10 has long lists of added signatures for float and long double
+26.8 [c.math], paragraph 10 has long lists of added signatures for float and long double
functions. All the signatures have float/long double return values, which is
inconsistent with some of the double functions they are supposed to
overload.
<p><b>Proposed resolution:</b></p>
<p>
-Change 26.7 [c.math], paragraph 10,
+Change 26.8 [c.math], paragraph 10,
</p>
<blockquote><pre><del>float</del> <ins>int</ins> ilogb(float);
<hr>
<h3><a name="639"></a>639. Still problems with exceptions during streambuf IO</h3>
-<p><b>Section:</b> 27.
6.1.2.3 [istream::extractors], 27.6.2.6.3 [ostream.inserters] <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-02-17</p>
+<p><b>Section:</b> 27.
7.1.2.3 [istream::extractors], 27.7.2.6.3 [ostream.inserters] <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>Opened:</b> 2007-02-17 <b>Last modified:</b> 2007-10-10</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</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>
-There already exist two active DR's for the wording of 27.6.1.2.3 [istream::extractors]/13
+There already exist two active DR's for the wording of 27.7.1.2.3 [istream::extractors]/13
from 14882:2003(E), namely <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>.
</p>
</p>
<p>
-I would like to add that its output counterpart in 27.6.2.6.3 [ostream.inserters]/7-9
+I would like to add that its output counterpart in 27.7.2.6.3 [ostream.inserters]/7-9
(also
N2134) does not demonstrate such an exception-loss-behaviour.
On the other side, I wonder concerning several subtle differences
<p>
Note that there is nothing mentioned which would imply that such
-an exception will be caught compared to 27.6.1.2.3 [istream::extractors]/14.
+an exception will be caught compared to 27.7.1.2.3 [istream::extractors]/14.
</p>
<p>
<p><b>Proposed resolution:</b></p>
<p>
-(a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence
+(a) In 27.7.1.2.3 [istream::extractors]/15 (N2134) change the sentence
</p>
<blockquote><p>
</p></blockquote>
<p>
-(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
+(b) In 27.7.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
</p>
<blockquote>
<hr>
<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>Section:</b> 27.7.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>Opened:</b> 2007-02-18 <b>Last modified:</b> 2007-07-02</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>
<p>
-The function <tt>f</tt> in para 4 (27.6.4 [ext.manip]) references an unknown <tt>strm</tt>
+The function <tt>f</tt> in para 4 (27.7.4 [ext.manip]) references an unknown <tt>strm</tt>
in the following line:
</p>
<p><b>Proposed resolution:</b></p>
<p>
-Change 27.6.4 [ext.manip], p4:
+Change 27.7.4 [ext.manip], p4:
</p>
<blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, str<del>m</del>, err, mon);
<hr>
<h3><a name="642"></a>642. Invalidated fstream footnotes in N2134</h3>
-<p><b>Section:</b> 27.
8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</p>
+<p><b>Section:</b> 27.
9.1.9 [ifstream.members], 27.9.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-20 <b>Last modified:</b> 2007-07-02</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Proposed resolution:</b></p>
<p>
-In 27.8.1.9 [ifstream.members], remove footnote:
+In 27.9.1.9 [ifstream.members], remove footnote:
</p>
<blockquote><p>
</p></blockquote>
<p>
-In 27.8.1.13 [ofstream.members], remove footnote:
+In 27.9.1.13 [ofstream.members], remove footnote:
</p>
<blockquote><p>
<hr>
<h3><a name="645"></a>645. Missing members in match_results</h3>
-<p><b>Section:</b> 28.1
0 [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>Section:</b> 28.1
1 [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>Opened:</b> 2007-02-26 <b>Last modified:</b> 2008-03-12</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
+According to the description given in 28.11 [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
+Comparing the provided operations from 28.11 [re.results]/3 with the
sequence/container tables 80 and 81 one recognizes the following
missing operations:
</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]
+Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.11 [re.results]
para 3:
</p>
</pre></blockquote>
<p>
-In section 28.10.3 [re.results.acc] change:
+In section 28.11.3 [re.results.acc] change:
</p>
<blockquote>
<hr>
<h3><a name="647"></a>647. Inconsistent regex_search params</h3>
-<p><b>Section:</b> 28.1
1.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>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
+<p><b>Section:</b> 28.1
2.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>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-26 <b>Last modified:</b> 2007-07-26</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>
-28.11.3 [re.alg.search]/5 declares
+28.12.3 [re.alg.search]/5 declares
</p>
<blockquote><pre>template <class iterator, class charT, class traits>
where it's not explained, which iterator category
the parameter iterator belongs to. This is inconsistent
to the preceding declaration in the synopsis section
-28.4 [re.syn], which says:
+28.5 [re.syn], which says:
</p>
<blockquote><pre>template <class BidirectionalIterator, class charT, class traits>
<p><b>Proposed resolution:</b></p>
<p>
-In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
+In 28.12.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
"BidirectionalIterator"
</p>
<hr>
<h3><a name="648"></a>648. regex_iterator c'tor needs clarification/editorial fix</h3>
-<p><b>Section:</b> 28.1
2.1.1 [re.regiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-03</p>
+<p><b>Section:</b> 28.1
3.1.1 [re.regiter.cnstr] <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>Opened:</b> 2007-03-03 <b>Last modified:</b> 2007-07-02</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
+In 28.13.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
</p>
<blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by
+In 28.13.1.1 [re.regiter.cnstr]/2 change the above quoted part by
</p>
<blockquote><p>
<hr>
<h3><a name="649"></a>649. Several typos in regex_token_iterator constructors</h3>
-<p><b>Section:</b> 28.1
2.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-03</p>
+<p><b>Section:</b> 28.1
3.2.1 [re.tokiter.cnstr] <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>Opened:</b> 2007-03-03 <b>Last modified:</b> 2007-07-02</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#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration
+In 28.13.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration
and the following text shows some obvious typos:
</p>
<p>
<p><b>Proposed resolution:</b></p>
<p>
-Change 28.12.2.1 [re.tokiter.cnstr]/1:
+Change 28.13.2.1 [re.tokiter.cnstr]/1:
</p>
<blockquote><pre>template <std::size_t N>
regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
</pre></blockquote>
<p>
-Change 28.12.2.1 [re.tokiter.cnstr]/2:
+Change 28.13.2.1 [re.tokiter.cnstr]/2:
</p>
<blockquote><p>
</p></blockquote>
<p>
-Change 28.12.2.1 [re.tokiter.cnstr]/3:
+Change 28.13.2.1 [re.tokiter.cnstr]/3:
</p>
<blockquote><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#NAD">NAD</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-03-08</p>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-03-08 <b>Last modified:</b> 2008-02-25</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>
<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>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
+<p><b>Section:</b> 26.
5.1 [rand.synopsis] <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>Opened:</b> 2007-03-08 <b>Last modified:</b> 2007-07-02</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</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>
-26.4.2 [rand.synopsis] the header <tt><random></tt> synopsis
+26.5.1 [rand.synopsis] the header <tt><random></tt> synopsis
contains an unreasonable closing curly brace inside the
<tt>subtract_with_carry_engine</tt> declaration.
</p>
<p><b>Proposed resolution:</b></p>
<p>
-Change the current declaration in 26.4.2 [rand.synopsis]
+Change the current declaration in 26.5.1 [rand.synopsis]
</p>
<blockquote><pre>template <class UIntType, size_t w<del>}</del>, size_t s, size_t r>
<hr>
<h3><a name="657"></a>657. unclear requirement about header inclusion</h3>
-<p><b>Section:</b> 17.
4.2.1 [using.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2007-03-14</p>
+<p><b>Section:</b> 17.
6.2.2 [using.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Gennaro Prota <b>Opened:</b> 2007-03-14 <b>Last modified:</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-17.4.2.1 [using.headers] states:
+17.6.2.2 [using.headers] states:
</p>
<blockquote><p>
<hr>
<h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3>
-<p><b>Section:</b> 20.
6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-19</p>
+<p><b>Section:</b> 20.
7 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-19 <b>Last modified:</b> 2007-08-05</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The header <tt><functional></tt> synopsis in 20.6 [function.objects]
+The header <tt><functional></tt> synopsis in 20.7 [function.objects]
contains the following two free comparison operator templates
for the <tt>function</tt> class template
</p>
<p>
which are nowhere described. I assume that they are relicts before the
corresponding two private and undefined member templates in the function
-template (see 20.6.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free
+template (see 20.7.16.2 [func.wrap.func] and [func.wrap.func.undef]) have been introduced. The original free
function templates should be removed, because using an undefined entity
would lead to an ODR violation of the user.
</p>
<p><b>Proposed resolution:</b></p>
<p>
Remove the above mentioned two function templates from
-the header <tt><functional></tt> synopsis (20.6 [function.objects])
+the header <tt><functional></tt> synopsis (20.7 [function.objects])
</p>
<blockquote><pre><del>template<class Function1, class Function2>
<hr>
<h3><a name="662"></a>662. Inconsistent handling of incorrectly-placed thousands separators</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#NAD">NAD</a>
- <b>Submitter:</b> Cosmin Truta <b>Date:</b> 2007-04-05</p>
+<p><b>Section:</b> 22.
4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2007-04-05 <b>Last modified:</b> 2007-07-25</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-From Section 22.2.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied
+From Section 22.4.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied
that the value read from a stream must be stored
even if the placement of thousands separators does not conform to the
<code>grouping()</code> specification from the <code>numpunct</code> facet.
<p><b>Proposed resolution:</b></p>
<p>
-Change 22.2.2.1.2 [facet.num.get.virtuals]:
+Change 22.4.2.1.2 [facet.num.get.virtuals]:
</p>
<blockquote>
<hr>
<h3><a name="663"></a>663. Complexity Requirements</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">NAD</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2009-05-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</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">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-17.3.1.3 [structure.specifications] para 5 says
+17.5.1.4 [structure.specifications] para 5 says
</p>
<blockquote><p>
--5- Complexity requirements specified in the library
+-5- Complexity requirements specified in the library
clauses are upper bounds, and implementations that provide better
complexity guarantees satisfy the requirements.
</p></blockquote>
<blockquote><p>
The library clauses suggest general
guidelines regarding complexity, but we have been unable to discover
-any absolute hard-and-fast formulae for these requirements. Unless
+any absolute hard-and-fast formulae for these requirements. Unless
or until the Library group standardizes specific hard-and-fast
-formulae, we regard all the complexity requirements as subject to a
+formulae, we regard all the complexity requirements as subject to a
"fudge factor" without any intrinsic upper bound.
</p></blockquote>
<p>
-[Plum ref
+[Plum ref
_23213Y31 etc]
</p>
<hr>
-<h3><a name="683"></a>683. regex_token_iterator summary error</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#NAD%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-02</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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
+<p><b>Section:</b> 22.4.6.3 [locale.moneypunct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2008-09-22</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#836">836</a></p>
<p><b>Discussion:</b></p>
<p>
-28.12.2 [re.tokiter], p3 says:
-</p>
-<blockquote>
-<p>
-After it is constructed, the iterator finds and stores a value
-<tt>match_results<BidirectionalIterator></tt> position and sets the
-internal count <tt>N</tt> to zero.
+22.4.6.3 [locale.moneypunct], para 2 says:
</p>
-</blockquote>
+
+<blockquote><p>
+The value <tt>space</tt> indicates that at least one space is required at
+that position.
+</p></blockquote>
<p>
-Should read:
+The following objection has been raised:
</p>
-<blockquote>
+<blockquote><p>
+Whitespace is optional when matching space. (See 22.4.6.1.2 [locale.money.get.virtuals], para 2.)
+</p></blockquote>
+
<p>
-After it is constructed, the iterator finds and stores a value
-<tt><del>match_results</del><ins>regex_iterator</ins><BidirectionalIterator<ins>, charT, traits</ins>></tt>
-position and sets the internal count <tt>N</tt> to zero.
+[Plum ref _22263Y22]
</p>
-</blockquote>
<p><i>[
-John adds:
+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><p>
-Yep, looks like a typo/administrative fix to me.
-</p></blockquote>
-
<p><b>Proposed resolution:</b></p>
-<p>
-</p>
<hr>
-<h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3>
-<p><b>Section:</b> 2
8.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>
+<h3><a name="676"></a>676. Moving the unordered containers</h3>
+<p><b>Section:</b> 2
3.5 [unord] <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> Howard Hinnant <b>Opened:</b> 2007-05-05 <b>Last modified:</b> 2008-09-26</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#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In 28.4 [re.syn] of N2284, two template functions
-are declared here:
+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>
-<blockquote><pre>// 28.10, class template match_results:
- <<i>snip</i>>
-// match_results comparisons
- template <class BidirectionalIterator, class Allocator>
- bool operator== (const match_results<BidirectionalIterator, Allocator>& m1,
- const match_results<BidirectionalIterator, Allocator>& m2);
- template <class BidirectionalIterator, class Allocator>
- bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1,
- const match_results<BidirectionalIterator, Allocator>& m2);
-// 28.10.6, match_results swap:
-</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".
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
<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.
+Add to 23.5 [unord]:
</p>
-<p><i>[
-John adds:
-]</i></p>
+<blockquote><pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<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>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
-<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>
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+
+...
+
+template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Value, Hash, Pred, Alloc>& x,
+ unordered_set<Value, Hash, Pred, Alloc>& y);
+
+<ins>template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Value, Hash, Pred, Alloc>& x,
+ unordered_set<Value, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Value, Hash, Pred, Alloc>&& x,
+ unordered_set<Value, Hash, Pred, Alloc>& y);</ins>
+
+template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x,
+ unordered_multiset<Value, Hash, Pred, Alloc>& y);
+
+<ins>template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x,
+ unordered_multiset<Value, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x,
+ unordered_multiset<Value, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
+<p><b><tt>unordered_map</tt></b></p>
-<p><b>Proposed resolution:</b></p>
<p>
-Add a new section after 28.10.6 [re.results.swap], which reads:
+Change 23.5.1 [unord.map]:
</p>
+
+<blockquote><pre>class unordered_map
+{
+ ...
+ unordered_map(const unordered_map&);
+ <ins>unordered_map(unordered_map&&);</ins>
+ ~unordered_map();
+ unordered_map& operator=(const unordered_map&);
+ <ins>unordered_map& operator=(unordered_map&&);</ins>
+ ...
+ // modifiers
+ <del>std::</del>pair<iterator, bool> insert(const value_type& obj);
+ <ins>template <class P> pair<iterator, bool> insert(P&& obj);</ins>
+ iterator insert(iterator hint, const value_type& obj);
+ <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins>
+ const_iterator insert(const_iterator hint, const value_type& obj);
+ <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins>
+ ...
+ void swap(unordered_map&<ins>&</ins>);
+ ...
+ mapped_type& operator[](const key_type& k);
+ <ins>mapped_type& operator[](key_type&& k);</ins>
+ ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
<p>
-28.10.7 match_results non-member functions.
+Add to 23.5.1.1 [unord.map.cnstr]:
</p>
<blockquote>
-<pre>template<class BidirectionalIterator, class Allocator>
- bool operator==(const match_results<BidirectionalIterator, Allocator>& m1,
- const match_results<BidirectionalIterator, Allocator>& m2);
+<pre>template <class InputIterator>
+ unordered_map(InputIterator f, InputIterator l,
+ size_type n = <i>implementation-defined</i>,
+ const hasher& hf = hasher(),
+ const key_equal& eql = key_equal(),
+ const allocator_type& a = allocator_type());
</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match.
-</p>
-</blockquote>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>pair<key_type, mapped_type></tt>,
+then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
+<tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
</blockquote>
-<blockquote>
-<pre>template<class BidirectionalIterator, class Allocator>
- bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1,
- const match_results<BidirectionalIterator, Allocator>& m2);
-</pre>
-<blockquote>
<p>
-<i>Returns:</i> <tt>!(m1 == m2)</tt>.
+Add to 23.5.1.2 [unord.map.elem]:
</p>
-</blockquote>
-</blockquote>
<blockquote>
-<pre>template<class BidirectionalIterator, class Allocator>
- void swap(match_results<BidirectionalIterator, Allocator>& m1,
- match_results<BidirectionalIterator, Allocator>& m2);
-</pre>
+
+<pre>mapped_type& operator[](const key_type& k);</pre>
+
<blockquote>
-<p>
-<i>Returns:</i> <tt>m1.swap(m2)</tt>.
-</p>
-</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& operator[](key_type&& k);</ins></pre>
-<p><i>[
-Bellevue: Proposed wording now in WP.
-]</i></p>
+<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<const key_type, mapped_type>(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="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.7.11.2.4 [unique.ptr.single.observers], 20.7.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-06-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in
-five places. In three of those places (20.6.15.2.3 [func.wrap.func.cap], function capacity
-for example) the returned value is constrained to disallow
-unintended conversions to int. The standardese is
-</p>
-<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.
+Add new section [unord.map.modifiers]:
</p>
-<p><i>[
-Bellevue:
-]</i></p>
-
+<blockquote>
+<pre><ins>pair<iterator, bool> insert(const value_type& x);</ins>
+<ins>template <class P> pair<iterator, bool> insert(P&& x);</ins>
+<ins>iterator insert(iterator hint, const value_type& x);</ins>
+<ins>template <class P> iterator insert(iterator hint, P&& x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
+<ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins>
+<ins>template <class InputIterator>
+ void insert(InputIterator first, InputIterator last);</ins>
+</pre>
<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.
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const value_type&</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<const key_type,
+mapped_type></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><b>Proposed resolution:</b></p>
<p>
-To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>()
-const</tt>
-of 20.7.11.2.4 [unique.ptr.single.observers] paragraph 11 and
-20.7.12.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence:
+Add to 23.5.1.3 [unord.map.swap]:
</p>
-<blockquote><p>
-The return type shall not be convertible to <tt>int</tt>.
-</p></blockquote>
+<blockquote>
+<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre>
+</blockquote>
-<p><i>[
-Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue.
-]</i></p>
+<p><b><tt>unordered_multimap</tt></b></p>
+
+<p>
+Change 23.5.2 [unord.multimap]:
+</p>
+<blockquote><pre>class unordered_multimap
+{
+ ...
+ unordered_multimap(const unordered_multimap&);
+ <ins>unordered_multimap(unordered_multimap&&);</ins>
+ ~unordered_multimap();
+ unordered_multimap& operator=(const unordered_multimap&);
+ <ins>unordered_multimap& operator=(unordered_multimap&&);</ins>
+ ...
+ // modifiers
+ iterator insert(const value_type& obj);
+ <ins>template <class P> iterator insert(P&& obj);</ins>
+ iterator insert(iterator hint, const value_type& obj);
+ <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins>
+ const_iterator insert(const_iterator hint, const value_type& obj);
+ <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins>
+ ...
+ void swap(unordered_multimap&<ins>&</ins>);
+ ...
+};
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
-<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 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]:
+Add to 23.5.2.1 [unord.multimap.cnstr]:
</p>
<blockquote>
+<pre>template <class InputIterator>
+ unordered_multimap(InputIterator f, InputIterator l,
+ size_type n = <i>implementation-defined</i>,
+ const hasher& hf = hasher(),
+ const key_equal& eql = key_equal(),
+ const allocator_type& 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<key_type, mapped_type></tt>,
+then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
+<tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
+
<p>
-The added signatures are:
+Add new section [unord.multimap.modifiers]:
</p>
-<blockquote><pre>long abs(long); // labs()
-long abs(long long); // llabs()
-</pre></blockquote>
+
+<blockquote>
+<pre><ins>iterator insert(const value_type& x);</ins>
+<ins>template <class P> iterator insert(P&& x);</ins>
+<ins>iterator insert(iterator hint, const value_type& x);</ins>
+<ins>template <class P> iterator insert(iterator hint, P&& x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
+<ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins>
+<ins>template <class InputIterator>
+ void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+
+<blockquote>
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const value_type&</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<const key_type,
+mapped_type></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>
-Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type?
+Add to 23.5.2.2 [unord.multimap.swap]:
</p>
+<blockquote>
+<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre>
+</blockquote>
+
+<p><b><tt>unordered_set</tt></b></p>
-<p><b>Proposed resolution:</b></p>
<p>
-Change 26.7 [c.math]:
+Change 23.5.3 [unord.set]:
</p>
-<blockquote><pre><ins>long </ins>long abs(long long); // llabs()
+
+<blockquote><pre>class unordered_set
+{
+ ...
+ unordered_set(const unordered_set&);
+ <ins>unordered_set(unordered_set&&);</ins>
+ ~unordered_set();
+ unordered_set& operator=(const unordered_set&);
+ <ins>unordered_set& operator=(unordered_set&&);</ins>
+ ...
+ // modifiers
+ <del>std::</del>pair<iterator, bool> insert(const value_type& obj);
+ <ins>pair<iterator, bool> insert(value_type&& obj);</ins>
+ iterator insert(iterator hint, const value_type& obj);
+ <ins>iterator insert(iterator hint, value_type&& obj);</ins>
+ const_iterator insert(const_iterator hint, const value_type& obj);
+ <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins>
+ ...
+ void swap(unordered_set&<ins>&</ins>);
+ ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins>
</pre></blockquote>
+<p>
+Add to 23.5.3.1 [unord.set.cnstr]:
+</p>
-<p><b>Rationale:</b></p>
-Had already been fixed in the WP by the time the LWG reviewed this.
+<blockquote>
+<pre>template <class InputIterator>
+ unordered_set(InputIterator f, InputIterator l,
+ size_type n = <i>implementation-defined</i>,
+ const hasher& hf = hasher(),
+ const key_equal& eql = key_equal(),
+ const allocator_type& 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<iterator, bool> insert(const value_type& x);</ins>
+<ins>pair<iterator, bool> insert(value_type&& x);</ins>
+<ins>iterator insert(iterator hint, const value_type& x);</ins>
+<ins>iterator insert(iterator hint, value_type&& x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
+<ins>const_iterator insert(const_iterator hint, value_type&& x);</ins>
+<ins>template <class InputIterator>
+ void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+<blockquote>
+
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const
+value_type&</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="697"></a>697. New <tt><system_error></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:
+Add to 23.5.3.2 [unord.set.swap]:
</p>
-<blockquote><pre>#include <system_error>
-#include <stdexcept>
+<blockquote>
+<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre>
+</blockquote>
-void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
-</pre></blockquote>
+<p><b><tt>unordered_multiset</tt></b></p>
<p>
-I propose that this enumeration type (and probably the remaining parts
-of
-<tt><system_error></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).
+Change 23.5.4 [unord.multiset]:
</p>
+<blockquote><pre>class unordered_multiset
+{
+ ...
+ unordered_multiset(const unordered_multiset&);
+ <ins>unordered_multiset(unordered_multiset&&);</ins>
+ ~unordered_multiset();
+ unordered_multiset& operator=(const unordered_multiset&);
+ <ins>unordered_multiset& operator=(unordered_multiset&&);</ins>
+ ...
+ // modifiers
+ iterator insert(const value_type& obj);
+ <ins>iterator insert(value_type&& obj);</ins>
+ iterator insert(iterator hint, const value_type& obj);
+ <ins>iterator insert(iterator hint, value_type&& obj);</ins>
+ const_iterator insert(const_iterator hint, const value_type& obj);
+ <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins>
+ ...
+ void swap(unordered_multiset&<ins>&</ins>);
+ ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
<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?
+Add to 23.5.4.1 [unord.multiset.cnstr]:
</p>
+<blockquote>
+<pre>template <class InputIterator>
+ unordered_multiset(InputIterator f, InputIterator l,
+ size_type n = <i>implementation-defined</i>,
+ const hasher& hf = hasher(),
+ const key_equal& eql = key_equal(),
+ const allocator_type& 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><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>.
+Add new section [unord.multiset.modifiers]:
</p>
+<blockquote>
+<pre><ins>iterator insert(const value_type& x);</ins>
+<ins>iterator insert(value_type&& x);</ins>
+<ins>iterator insert(iterator hint, const value_type& x);</ins>
+<ins>iterator insert(iterator hint, value_type&& x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
+<ins>const_iterator insert(const_iterator hint, value_type&& x);</ins>
+<ins>template <class InputIterator>
+ void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+<blockquote>
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const
+value_type&</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>
-<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>
+</blockquote>
<p>
-From the Toronto Core wiki:
+Add to 23.5.4.2 [unord.multiset.swap]:
</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>
+<blockquote>
+<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre>
+</blockquote>
-<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:
+Voted to WP in Bellevue.
+]</i></p>
+
+
+<p><i>[
+post Bellevue, Pete notes:
]</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.
+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>
-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.
+This issue is not ready. In addition to the relatively minor signature
+problem I mentioned earlier, it puts requirements in the wrong places.
+Instead of duplicating requirements throughout the template
+specifications, it should put them in the front matter that talks about
+requirements for unordered containers in general. This presentation
+problem is editorial, but I'm not willing to do the extensive rewrite
+that it requires. Please put it back into Open status.
</p>
</blockquote>
+<p><b>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
+<blockquote>
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
+</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>
+<h3><a name="683"></a>683. regex_token_iterator summary error</h3>
+<p><b>Section:</b> 28.13.2 [re.tokiter] <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> Eric Niebler <b>Opened:</b> 2007-06-02 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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#NAD%20Editorial">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&</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]:
+28.13.2 [re.tokiter], p3 says:
</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>&a[i+j] == &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>.
+After it is constructed, the iterator finds and stores a value
+<tt>match_results<BidirectionalIterator></tt> position and sets the
+internal count <tt>N</tt> to zero.
</p>
+</blockquote>
<p>
--4- Likewise, the expression <tt>&a[i] != &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>
+Should read:
</p>
+<blockquote>
<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.
+After it is constructed, the iterator finds and stores a value
+<tt><del>match_results</del><ins>regex_iterator</ins><BidirectionalIterator<ins>, charT, traits</ins>></tt>
+position and sets the internal count <tt>N</tt> to zero.
</p>
-
</blockquote>
+<p><i>[
+John adds:
+]</i></p>
+<blockquote><p>
+Yep, looks like a typo/administrative fix to me.
+</p></blockquote>
-<hr>
-<h3><a name="725"></a>725. Optional sequence container requirements column label</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> David Abrahams <b>Date:</b> 2007-09-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</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?"
+
+
+
+<hr>
+<h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3>
+<p><b>Section:</b> 28.11 [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>Opened:</b> 2007-05-27 <b>Last modified:</b> 2008-03-12</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>
+In 28.5 [re.syn] of N2284, two template functions
+are declared here:
</p>
+<blockquote><pre>// 28.10, class template match_results:
+ <<i>snip</i>>
+// match_results comparisons
+ template <class BidirectionalIterator, class Allocator>
+ bool operator== (const match_results<BidirectionalIterator, Allocator>& m1,
+ const match_results<BidirectionalIterator, Allocator>& m2);
+ template <class BidirectionalIterator, class Allocator>
+ bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1,
+ const match_results<BidirectionalIterator, Allocator>& 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><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><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>
-<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><b>Proposed resolution:</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<X::result_type>(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.
+Add a new section after 28.11.6 [re.results.swap], which reads:
</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<UintType>(s)</tt>, where <tt>UintType</tt> is an
-implementation specific unsigned integer type."
+28.10.7 match_results non-member functions.
</p>
+<blockquote>
+<pre>template<class BidirectionalIterator, class Allocator>
+ bool operator==(const match_results<BidirectionalIterator, Allocator>& m1,
+ const match_results<BidirectionalIterator, Allocator>& m2);
+</pre>
+<blockquote>
<p>
-Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
+<i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match.
</p>
+</blockquote>
+</blockquote>
+<blockquote>
+<pre>template<class BidirectionalIterator, class Allocator>
+ bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1,
+ const match_results<BidirectionalIterator, Allocator>& m2);
+</pre>
+<blockquote>
<p>
-Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified.
+<i>Returns:</i> <tt>!(m1 == m2)</tt>.
</p>
+</blockquote>
+</blockquote>
+<blockquote>
+<pre>template<class BidirectionalIterator, class Allocator>
+ void swap(match_results<BidirectionalIterator, Allocator>& m1,
+ match_results<BidirectionalIterator, Allocator>& m2);
+</pre>
+<blockquote>
<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for further discussion.
+<i>Returns:</i> <tt>m1.swap(m2)</tt>.
</p>
+</blockquote>
+</blockquote>
+
<p><i>[
-Stephan Tolksdorf adds pre-Bellevue:
+Bellevue: Proposed wording now in WP.
]</i></p>
-<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.8.12.2.4 [unique.ptr.single.observers], 20.8.13.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>Opened:</b> 2007-06-14 <b>Last modified:</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#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
<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:
+The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in
+five places. In three of those places (20.7.16.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>
-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<X::result_type>(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.
+This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those.
</p>
-</blockquote>
<p><i>[
Bellevue:
<blockquote>
-Propose close NAD for the reasons given in N2424.
+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>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for further discussion.
+To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>()
+const</tt>
+of 20.8.12.2.4 [unique.ptr.single.observers] paragraph 11 and
+20.8.13.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>[
-Stephan Tolksdorf adds pre-Bellevue:
+Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue.
]</i></p>
-<blockquote>
+
+
+
+<hr>
+<h3><a name="690"></a>690. abs(long long) should return long long</h3>
+<p><b>Section:</b> 26.8 [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>Opened:</b> 2007-06-10 <b>Last modified:</b> 2007-07-25</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>
-Change row 3 of table 105 "Random number engine requirements" in 26.4.1.3 [rand.req.eng]/3
+Quoting the latest draft (n2135), 26.8 [c.math]:
</p>
<blockquote>
-Creates an engine with initial state determined by
-<tt><del>static_cast<X::result_type>(</del>s<del>)</del></tt>
+<p>
+The added signatures are:
+</p>
+<blockquote><pre>long abs(long); // labs()
+long abs(long long); // llabs()
+</pre></blockquote>
</blockquote>
-
<p>
-Similarly, change 26.4.1.4 [rand.req.adapt]/3 e)
+Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type?
</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>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.8 [c.math]:
+</p>
+<blockquote><pre><ins>long </ins>long abs(long long); // llabs()
+</pre></blockquote>
+
+<p><b>Rationale:</b></p>
+Had already been fixed in the WP by the time the LWG reviewed this.
<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>
+<h3><a name="697"></a>697. New <tt><system_error></tt> header leads to name clashes</h3>
+<p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-24 <b>Last modified:</b> 2008-01-06</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>
-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.
+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.5 [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.2 [std.exceptions]/p.3. This clash makes
+e.g. the following snippet invalid:
</p>
+<blockquote><pre>#include <system_error>
+#include <stdexcept>
+
+void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
+</pre></blockquote>
+
<p>
-<b>Posssible resolution:</b> [As above]
+I propose that this enumeration type (and probably the remaining parts
+of
+<tt><system_error></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>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for further discussion.
+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><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.
+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="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>
+<h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
+<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-20 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</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.
+The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from
+most of the member functions of node-based containers. But the move-related changes
+unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
+require <tt>CopyAssignable</tt>.
</p>
+
<p>
-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:
+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> and containers with a <tt>propagate_never</tt> allocator require <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr>
+<tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
+ Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>.
+ Sequences and Associative containers with <tt>propagate_never</tt> and <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> and containers with <tt>propagate_never</tt> and
+ <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr>
+</tbody></table>
+
<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>
+<table border="1">
+<caption>Sequence Requirements</caption>
+<tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
+<tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
+<tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+ If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+ The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
+<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
+ The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+ The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
+<tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+ The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
+ If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
+ The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
+<tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.clear()</tt></td><td></td></tr>
+<tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
+ If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
+<tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
+ The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+</tbody></table>
+
<p>
-Supplement the <tt>seed_seq</tt> with a traits class
</p>
-<blockquote><pre>template <typename T>
-struct is_seed_seq { static const bool value = false; }
-</pre></blockquote>
-<p>and the specialization</p>
-<blockquote><pre>template <>
-struct is_seed_seq<seed_seq> { 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>
+<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>
-<blockquote>
-See N2424. Close NAD but note that "conceptizing" the library may cause
-this problem to be solved by that route.
-</blockquote>
+<p>
+</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><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>
+<table border="1">
+<caption>Miscellaneous Requirements</caption>
+<tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
+ The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
+ The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
+</tbody></table>
+<p><i>[
+Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
+]</i></p>
+<p><i>[
+Bellevue: This should be handled as part of the concepts work.
+]</i></p>
-<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><b>Proposed resolution:</b></p>
+
+
+
+<p><b>Rationale:</b></p>
<p><i>[
-Bellevue:
+post San Francisco:
]</i></p>
<blockquote>
-Close NAD for the reasons given in N2424. In practice it is not inconvenient to meet these requirements.
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
</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>
+<h3><a name="707"></a>707. null pointer constant for <tt>exception_ptr</tt></h3>
+<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2007-07-20 <b>Last modified:</b> 2008-02-25</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>
-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.
+From the Toronto Core wiki:
</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.
+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>
-Choosing unusual names for the parameters causes confusion among users and makes the
-interface unnecessarily inconvenient to use.
+Peter's response:
</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>.
+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>[
<blockquote>
-In N2424. NAD It has been around for a while. It is hardly universal,
-there is prior art, and this would confuse people.
+<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>
-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 other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<h3><a name="717"></a>717. Incomplete <tt>valarray::operator[]</tt> specification in [valarray.access]</h3>
+<p><b>Section:</b> 26.6.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> Daniel Krügler <b>Opened:</b> 2007-08-27 <b>Last modified:</b> 2008-09-22</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>
-<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.
+Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been
+changed to <tt>const T&</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.6.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><i>[
-Stephan Tolksdorf adds pre-Bellevue:
-]</i></p>
-
-<blockquote>
+<p><b>Proposed resolution:</b></p>
<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:
+Change 26.6.2.3 [valarray.access]:
</p>
+
+<blockquote>
<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 < n <=
-numeric_limits<IntType>::max() + 1</tt>" makes the implementation
-unnecessarily complicated, "<tt>0 < n <= numeric_limits<IntType>::max()</tt>"
-would be better.
+-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>
-</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 > 0 be replaced with 0 < 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.
+-3- The expression <tt>&a[i+j] == &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>
-As it stands now, it is convenient, and the changes proposed make it
-much less so.
+-4- Likewise, the expression <tt>&a[i] != &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>
-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.
+-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>
-<p><b>Proposed resolution:</b></p>
+
+
+
+
+<hr>
+<h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
+<p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2007-09-12 <b>Last modified:</b> 2008-09-23</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%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</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.
+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>[
-Stephan Tolksdorf adds pre-Bellevue:
+Bellevue:
]</i></p>
<blockquote>
<p>
-In 26.4.8.5.1 [rand.dist.samp.discrete]:
+Walking into the default/value-initialization mess...
</p>
-
<p>
-Proposed wording a):
+Why two lines? Because we need both expressions to be valid.
</p>
-
-<blockquote>
<p>
-Changae in para. 2
+AJM not sure what the phrase "default constructed" means. This is
+unfortunate, as the phrase is already used 24 times in the library!
</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
+Example: const int would not accept first line, but will accept the second.
</p>
-
-<blockquote>
-<i>Returns:</i> A <tt>vector<double></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):
+This is an issue that must be solved by concepts, but we might need to solve it independantly first.
</p>
-
-<blockquote>
<p>
-Change in para. 3:
+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>
+In section X [utility.arg.requirements], before table 33, add the
+following table:
+</p>
+
+<p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
+
+<div align="center">
+
+<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>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></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>> 0</del></tt>
-<ins>such that <tt>0 < n <= numeric_limits<IntType>::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>]
+We believe concepts will solve this problem
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>).
</blockquote>
-</blockquote>
+
+
+
+<hr>
+<h3><a name="725"></a>725. Optional sequence container requirements column label</h3>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> David Abrahams <b>Opened:</b> 2007-09-16 <b>Last modified:</b> 2008-09-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">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="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>
+<h3><a name="729"></a>729. Problem in [rand.req.eng]/3</h3>
+<p><b>Section:</b> X [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>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-02-27</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>
-<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
+The 3rd table row in X [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<X::result_type>(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>
-<blockquote><pre>template <class InputIteratorB, class InputIteratorW>
-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.
+<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<UintType>(s)</tt>, where <tt>UintType</tt> is an
+implementation specific unsigned integer type."
</p>
-</li>
-</ol>
<p>
-<b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface.
+Additionally, the definition of s in X [rand.req.eng]/1 c) could be restricted to unsigned integer types.
+</p>
+
+<p>
+Similarly, the type of the seed in X [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>
-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>.
+regarding this issue:
+</p>
+<p>
+The descriptions of all engines and engine adaptors given in sections
+26.5.3 [rand.eng] and 26.5.4 [rand.adapt] already specify the concrete
+types of the integer arguments for seeding. Hence, relaxing the general
+requirement in X [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<X::result_type>(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>[
<blockquote>
-In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD.
+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 the proposed resolution.
+for further discussion.
</p>
<p><i>[
<blockquote>
<p>
-In 26.4.8.5.2 [rand.dist.samp.pconst]:
-</p>
-
-<p>
-Proposed wording a)
+Change row 3 of table 105 "Random number engine requirements" in X [rand.req.eng]/3
</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>
+Creates an engine with initial state determined by
+<tt><del>static_cast<X::result_type>(</del>s<del>)</del></tt>
</blockquote>
<p>
-and change in para. 5
+Similarly, change X [rand.req.adapt]/3 e)
</p>
<blockquote>
-A <tt>vector<result_type></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>
+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> X [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>Opened:</b> 2007-09-21 <b>Last modified:</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#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-Proposed wording b)
+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>
-<blockquote>
<p>
-Change both occurrences of
+<b>Posssible resolution:</b> [As above]
</p>
-<blockquote>
-"piecewise_constant_distribution(InputIteratorB firstB, InputIteratorB lastB,
- InputIteratorW firstW<ins>, InputIteratorW lastW</ins>)
-</blockquote>
-
<p>
-and change in para. 3
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for further discussion.
</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 >= 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>
+<p><i>[
+Bellevue:
+]</i></p>
+<blockquote>
+Close NAD for the reasons given in N2424.
</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>
<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>
+<h3><a name="731"></a>731. proposal for a customizable <tt>seed_seq</tt></h3>
+<p><b>Section:</b> 26.
5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-02-27</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 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)).
+The proper way to seed random number engines seems to be the most frequently
+discussed issue of the 26.5 [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>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for further discussion.
+<b>Possible resolution:</b>
+</p>
+
+<ol type="a">
+<li>
+Turn the interface specification of 26.5.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 <typename T>
+struct is_seed_seq { static const bool value = false; }
+</pre></blockquote>
+<p>and the specialization</p>
+<blockquote><pre>template <>
+struct is_seed_seq<seed_seq> { static const bool value = true; }
+</pre></blockquote>
+<p>which users can supplement with further specializations.</p>
+</li>
+<li>
+Change X [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.5.3 [rand.eng] appropriately (the actual implementation
+could be done using the SFINAE technique).
+</li>
+</ol>
<p><i>[
Bellevue:
<blockquote>
-In N2424. Close NAD as described there.
+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>
<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.7.12.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3>
+<p><b>Section:</b> X [rand.dist.samp.genpdf] <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> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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#NAD%20Editorial">NAD Editorial</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>
-The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
+X [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>
<p>
-According to the recent draft N2369, both the header memory synopsis
-of 20.7 [memory] and 20.7.12.2.11 [util.smartptr.getdeleter] declare:
+<b>Possible resolution:</b> For these reasons, I propose to delete section X [rand.dist.samp.genpdf].
</p>
-<blockquote><pre>template<class D, class T> D* get_deleter(shared_ptr<T> const& 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.6.15.2 [func.wrap.func] or in 20.6.15.2.5 [func.wrap.func.targ] - do
-properly mirror the const-state of the owner.
-</p>
+<p><i>[
+Bellevue:
+]</i></p>
-<b>Possible proposed resolutions:</b>
+<blockquote>
<p>
-Replace the declarations of <tt>get_deleter</tt> in the header <tt><memory></tt>
-synopsis of 20.7 [memory] and in 20.7.12.2.11 [util.smartptr.getdeleter] by one of the
-following alternatives (A) or (B):
+Disagreement persists.
</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<class D, class T> const D* get_deleter(shared_ptr<T> const& p);
-</pre></blockquote>
-</li>
-<li>
-Just remove the function.
-</li>
-</ol>
-
<p>
-Alberto Ganesh Barbati adds:
+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>
-
-<ol start="3" type="A">
-<li>
<p>
-Replace it with two functions:
+Correction: The formula above should instead read 1+sin(n*x).
</p>
-<blockquote><pre>template <class D, class T> D get_deleter(shared_ptr<T> const&);
-template <class D, class T> bool has_deleter(shared_ptr<T> const&);
-</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.
+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>
-</ol>
-
-<p>
-Peter Dimov adds:
-</p>
-
-<blockquote>
-<p>
-My favorite option is "not a defect". A, B and C break useful code.
-</p>
+<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>
-<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>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2813.pdf">N2813</a>
+for the proposed resolution.
</p>
+<p><b>Rationale:</b></p>
+Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
+
+
<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>
+<h3><a name="733"></a>733. Comment on [rand.req.dist]/9</h3>
+<p><b>Section:</b> X [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>Opened:</b> 2007-09-21 <b>Last modified:</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#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.
+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>
-(Peter Dimov suggests NAD)
+<b>Proposed resolution:</b> I propose to drop this requirement.
</p>
<p><i>[
-Bellevue:
+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>
+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="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3>
-<p><b>Section:</b> 20.5.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
+<h3><a name="735"></a>735. Unfortunate naming</h3>
+<p><b>Section:</b> 26.5.8.2.2 [rand.dist.bern.bin], 26.5.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>Opened:</b> 2007-09-21 <b>Last modified:</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#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?
+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>
-For instance, is the following (non-polymorphic) type considered abstract?
+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>struct abstract {
-protected:
- abstract(){}
- abstract( abstract const & ) {}
- ~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)
+Choosing unusual names for the parameters causes confusion among users and makes the
+interface unnecessarily inconvenient to use.
</p>
-
-<p><b>Proposed resolution:</b></p>
<p>
-Core has clarified that the definition abstract is adequate. Issue withdrawn by submitter. NAD.
+<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>
-<hr>
-<h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3>
-<p><b>Section:</b> 20.7.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-10-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
<p>
-14882-2003, [lib.uninitialized.copy] is currently written as follows:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
</p>
-<blockquote>
-<pre>template <class InputIterator, class ForwardIterator>
- 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<void*>(&*result))
- typename iterator_traits<ForwardIterator>::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.7.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>
+
+<hr>
+<h3><a name="736"></a>736. Comment on [rand.dist.samp.discrete]</h3>
+<p><b>Section:</b> 26.5.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>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-02-27</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 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.
+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 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>).
+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>
-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>.
+<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>
-<p><b>Proposed resolution:</b></p>
+<blockquote>
<p>
-Change the wording of the return clause to say (20.7.10.1 [uninitialized.copy]):
+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>
-
-<blockquote>
<p>
--2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins>
+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 < n <=
+numeric_limits<IntType>::max() + 1</tt>" makes the implementation
+unnecessarily complicated, "<tt>0 < n <= numeric_limits<IntType>::max()</tt>"
+would be better.
</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="756"></a>756. Container adaptors push</h3>
-<p><b>Section:</b> 23.2.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-10-31</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-After n2369 we have a single <tt>push_back</tt> overload in the sequence containers,
-of the "emplace" type. At variance with that, still in n2461, we have
-two separate overloads, the C++03 one + one taking an rvalue reference
-in the container adaptors. Therefore, simply from a consistency point of
-view, I was wondering whether the container adaptors should be aligned
-with the specifications of the sequence container themselves: thus have
-a single <tt>push</tt> along the lines:
+In N2424. We agree with the observation and the proposed resolution to
+part b). We recommend the wording n > 0 be replaced with 0 < 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>
-<blockquote><pre>template<typename... _Args>
-void
-push(_Args&&... __args)
- { c.push_back(std::forward<_Args>(__args)...); }
-</pre></blockquote>
-
-<p><i>[
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
-]</i></p>
+<p>
+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>
-Change 23.2.5.1.1 [queue.defn]:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
</p>
-<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del>
-<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del>
-<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins>
-</pre></blockquote>
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
+
+<blockquote>
<p>
-Change 23.2.5.2 [priority.queue]:
+In 26.5.8.5.1 [rand.dist.samp.discrete]:
</p>
-<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del>
-<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del>
-<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins>
-</pre></blockquote>
-
<p>
-Change 23.2.5.2.2 [priqueue.members]:
+Proposed wording a):
</p>
<blockquote>
-<pre><del>void push(const value_type& x);</del>
-</pre>
-<blockquote>
<p>
-<del><i>Effects:</i></del>
+Changae in para. 2
</p>
-<blockquote><pre><del>c.push_back(x);</del>
-<del>push_heap(c.begin(), c.end(), comp);</del>
-</pre></blockquote>
-</blockquote>
-<pre><ins>template<class... Args></ins> void push(<del>value_type</del> <ins>Args</ins>&&<ins>...</ins> <del>x</del> <ins>args</ins>);
-</pre>
<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>
-<i>Effects:</i>
+and change in para. 5
</p>
-<blockquote><pre>c.push_back(std::<del>move</del><ins>forward<Args></ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>);
-push_heap(c.begin(), c.end(), comp);
-</pre></blockquote>
+
+<blockquote>
+<i>Returns:</i> A <tt>vector<double></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>
-Change 23.2.5.3.1 [stack.defn]:
+Proposed wording b):
</p>
-<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del>
-<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del>
-<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins>
-</pre></blockquote>
+<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>> 0</del></tt>
+<ins>such that <tt>0 < n <= numeric_limits<IntType>::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>
-<p><b>Rationale:</b></p>
-<p>
-Addressed by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
-</p>
+</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">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#NAD%20Editorial">NAD Editorial</a> status.</p>
+<h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</h3>
+<p><b>Section:</b> 26.5.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>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-02-27</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>
-In the synopsis 23.2.6 [vector], there is the signature:
+The design of the constructor
</p>
-
-<blockquote><pre>void insert(const_iterator position, size_type n, T&& x);
+<blockquote><pre>template <class InputIteratorB, class InputIteratorW>
+piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB,
+ InputIteratorW firstW);
</pre></blockquote>
-
<p>
-instead of:
+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>
-
-<blockquote><pre>iterator insert(const_iterator position, T&& x);
-</pre></blockquote>
+</li>
+</ol>
<p>
-23.2.6.4 [vector.modifiers] is fine.
+<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>
-Change the synopsis in 23.2.6 [vector]:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
</p>
-<blockquote><pre>iterator insert(const_iterator position, const T& x);
-<ins>iterator insert(const_iterator position, T&& x);</ins>
-void insert(const_iterator position, size_type n, const T& x);
-<del>void insert(const_iterator position, size_type n, T&& x);</del>
-</pre></blockquote>
-
-
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
+<blockquote>
+<p>
+In 26.5.8.5.2 [rand.dist.samp.pconst]:
+</p>
-<hr>
-<h3><a name="763"></a>763. Renaming <tt>emplace()</tt> overloads</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-04</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-The associative containers provide 2 overloads of <tt>emplace()</tt>:
+Proposed wording a)
</p>
-<blockquote><pre>template <class... Args> pair<iterator, bool> emplace(Args&&... args);
-template <class... Args> iterator emplace(const_iterator position, Args&&... args);
-</pre></blockquote>
+<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>
-This is a problem if you mean the first overload while passing
-a <tt>const_iterator</tt> as first argument.
+and change in para. 5
</p>
-<p><i>[
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
-]</i></p>
+<blockquote>
+A <tt>vector<result_type></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><i>[
-Bellevue:
-]</i></p>
+<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>
-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.
+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 >= 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.5.4.1 [rand.adapt.disc] <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> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-09-22</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>
-Resolution: Change state to NAD.
+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>
-Rename one of the two overloads.
-For example to <tt>emplace_here</tt>, <tt>hint_emplace</tt>...
+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="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.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-29</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<h3><a name="739"></a>739. Defect in [rand.util.canonical]/3</h3>
+<p><b>Section:</b> 26.5.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>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-02-27</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>
- 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>.
+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>
- 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<B::iterator, B::iterator></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<iterator, iterator></tt>, <tt>equal_range</tt> were to
-return <tt>pair<local_iterator, local_iterator></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.
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for further discussion.
</p>
<p><i>[
<blockquote>
-The proposed resolution breaks consistency with other container types
-for dubious benefit, and iterators are already constant time.
+In N2424. Close NAD as described there.
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Change the entry for <tt>equal_range</tt> in Table 93 (23.1.5 [unord.req]) as follows:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
</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<<ins>local_</ins>iterator,<ins>local_</ins>iterator>; pair<const_<ins>local_</ins>iterator,const_<ins>local_</ins>iterator></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 Θ<tt>(b.count(k))</tt>. Worst case Θ<tt>(b.size())</tt>. </td>
-</tr>
-</tbody></table>
<hr>
-<h3><a name="767"></a>767. Forwarding and backward compatibility</h3>
-<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<h3><a name="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3>
+<p><b>Section:</b> 20.8.13.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>Opened:</b> 2007-09-27 <b>Last modified:</b> 2008-02-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>
-Playing with g++'s C++0X mode, I noticed that the following
-code, which used to compile:
+The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
</p>
-<blockquote><pre>#include <vector>
+<p>
+According to the recent draft N2369, both the header memory synopsis
+of 20.8 [memory] and 20.8.13.2.11 [util.smartptr.getdeleter] declare:
+</p>
-int main()
-{
- std::vector<char *> v;
- v.push_back(0);
-}
+<blockquote><pre>template<class D, class T> D* get_deleter(shared_ptr<T> const& p);
</pre></blockquote>
<p>
-now fails with the following error message:
+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.7.16.2 [func.wrap.func] or in 20.7.16.2.5 [func.wrap.func.targ] - do
+properly mirror the const-state of the owner.
</p>
-<blockquote>.../include/c++/4.3.0/ext/new_allocator.h: In member
-function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*,
-_Args&& ...) [with _Args = int, _Tp = char*]':
-.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void
-std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with
-_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]'
-test.cpp:6: instantiated from here
-.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid
-conversion from 'int' to 'char*'
-</blockquote>
+<b>Possible proposed resolutions:</b>
<p>
-As far as I know, g++ follows the current draft here.
+Replace the declarations of <tt>get_deleter</tt> in the header <tt><memory></tt>
+synopsis of 20.8 [memory] and in 20.8.13.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<class D, class T> const D* get_deleter(shared_ptr<T> const& 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 <class D, class T> D get_deleter(shared_ptr<T> const&);
+template <class D, class T> bool has_deleter(shared_ptr<T> const&);
+</pre></blockquote>
+
<p>
-Does the committee really intend to break compatibility for such cases?
+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>[
-Sylvain adds:
+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>
-I just noticed that <tt>std::pair</tt> has the same issue.
-The following now fails with GCC's -std=c++0x mode:
</p>
-<blockquote><pre>#include <utility>
-int main()
+
+
+
+<hr>
+<h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
+<p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-26</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%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a> now just
+deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
+requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
+<tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
+</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 <class T>
+struct proxy {...};
+
+template <class T>
+struct proxied_iterator
{
- std::pair<char *, char *> p (0,0);
-}
+ typedef T value_type;
+ typedef proxy<T> reference;
+ reference operator*() const;
+ ...
+};
+
+struct A
+{
+ // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
+ void swap(A&);
+ ...
+};
+
+void swap(A&, A&);
+void swap(proxy<A>, A&);
+void swap(A&, proxy<A>);
+void swap(proxy<A>, proxy<A>);
+
+} // Mine
+
+...
+
+Mine::proxied_iterator<Mine::A> i(...)
+Mine::A a;
+<b>swap(*i1, a);</b>
</pre></blockquote>
<p>
-I have not made any general audit for such problems elsewhere.
+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>
-</blockquote>
-
-<p><i>[
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>
-]</i></p>
+<p>
+That is, no standard library code needs to change. We simply need to have a more flexible
+definition of <tt>Swappable</tt>.
+</p>
<p><i>[
Bellevue:
<blockquote>
<p>
-Motivation is to handle the old-style int-zero-valued NULL pointers.
-Problem: this solution requires concepts in some cases, which some users
-will be slow to adopt. Some discussion of alternatives involving
-prohibiting variadic forms and additional library-implementation
-complexity.
+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>
-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.
+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>
-Another approach is to change the member names. Yet another approach is
-to forbid the extension in absence of concepts.
+Motivation is proxy-iterators, but facility is considerably more
+general. Are we happy going so far?
</p>
<p>
-Resolution: These issues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>) will be subsumed into a
-paper to be produced by Alan Talbot in time for review at the 2008
-meeting in France. Once this paper is produced, these issues will be
-moved to NAD.
+We think this wording is probably correct and probably an improvement on
+what's there in the WP. On the other hand, what's already there in the
+WP is awfully complicated. Why do we need the two bullet points? They're
+too implementation-centric. They don't add anything to the semantics of
+what swap() means, which is there in the post-condition. What's wrong
+with saying that types are swappable if you can call swap() and it
+satisfies the semantics of swapping?
</p>
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Add the following rows to Table 90 "Optional sequence container operations", 23.1.3 [sequence.reqmts]:
+Change X [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> <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">
-<tbody><tr>
-<th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th>
-</tr>
+<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>
-<tr>
-<td>
-<tt>a.push_front(t)</tt>
-</td>
-<td>
-<tt>void</tt>
-</td>
-<td>
-<tt>a.insert(a.begin(), t)</tt><br>
-<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
-</td>
-<td>
-<tt>list, deque</tt>
-</td>
-</tr>
-<tr>
-<td>
-<tt>a.push_front(rv)</tt>
-</td>
-<td>
-<tt>void</tt>
-</td>
-<td>
-<tt>a.insert(a.begin(), rv)</tt><br>
-<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
-</td>
-<td>
-<tt>list, deque</tt>
-</td>
-</tr>
-<tr>
-<td>
-<tt>a.push_back(t)</tt>
-</td>
-<td>
-<tt>void</tt>
-</td>
-<td>
-<tt>a.insert(a.end(), t)</tt><br>
+<p><b>Rationale:</b></p>
+<p><i>[
+post San Francisco:
+]</i></p>
+
+
+<blockquote>
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2758.pdf">N2758</a>.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="745"></a>745. copy_exception API slices.</h3>
+<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-02-25</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.6.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>Opened:</b> 2007-10-10 <b>Last modified:</b> 2009-05-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#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:
+ abstract(){}
+ abstract( abstract const & ) {}
+ ~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.8.11.2 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-10-15 <b>Last modified:</b> 2008-07-02</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#NAD%20Editorial">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 <class InputIterator, class ForwardIterator>
+ 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<void*>(&*result))
+ typename iterator_traits<ForwardIterator>::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.8.11.2 [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.5.1.4 [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.8.11.2 [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="756"></a>756. Container adaptors push</h3>
+<p><b>Section:</b> 23.3.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-10-31 <b>Last modified:</b> 2008-06-18</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+After n2369 we have a single <tt>push_back</tt> overload in the sequence containers,
+of the "emplace" type. At variance with that, still in n2461, we have
+two separate overloads, the C++03 one + one taking an rvalue reference
+in the container adaptors. Therefore, simply from a consistency point of
+view, I was wondering whether the container adaptors should be aligned
+with the specifications of the sequence container themselves: thus have
+a single <tt>push</tt> along the lines:
+</p>
+
+<blockquote><pre>template<typename... _Args>
+void
+push(_Args&&... __args)
+ { c.push_back(std::forward<_Args>(__args)...); }
+</pre></blockquote>
+
+<p><i>[
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 23.3.5.1.1 [queue.defn]:
+</p>
+
+<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del>
+<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del>
+<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins>
+</pre></blockquote>
+
+<p>
+Change 23.3.5.2 [priority.queue]:
+</p>
+
+<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del>
+<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del>
+<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins>
+</pre></blockquote>
+
+<p>
+Change 23.3.5.2.2 [priqueue.members]:
+</p>
+
+<blockquote>
+<pre><del>void push(const value_type& 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<class... Args></ins> void push(<del>value_type</del> <ins>Args</ins>&&<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<Args></ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>);
+push_heap(c.begin(), c.end(), comp);
+</pre></blockquote>
+</blockquote>
+</blockquote>
+
+<p>
+Change 23.3.5.3.1 [stack.defn]:
+</p>
+
+<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del>
+<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del>
+<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins>
+</pre></blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="757"></a>757. Typo in the synopsis of vector</h3>
+<p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-11-04 <b>Last modified:</b> 2008-07-02</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%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In the synopsis 23.3.6 [vector], there is the signature:
+</p>
+
+<blockquote><pre>void insert(const_iterator position, size_type n, T&& x);
+</pre></blockquote>
+
+<p>
+instead of:
+</p>
+
+<blockquote><pre>iterator insert(const_iterator position, T&& x);
+</pre></blockquote>
+
+<p>
+23.3.6.4 [vector.modifiers] is fine.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 23.3.6 [vector]:
+</p>
+
+<blockquote><pre>iterator insert(const_iterator position, const T& x);
+<ins>iterator insert(const_iterator position, T&& x);</ins>
+void insert(const_iterator position, size_type n, const T& x);
+<del>void insert(const_iterator position, size_type n, T&& x);</del>
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="763"></a>763. Renaming <tt>emplace()</tt> overloads</h3>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Sylvain Pion <b>Opened:</b> 2007-12-04 <b>Last modified:</b> 2008-03-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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 <class... Args> pair<iterator, bool> emplace(Args&&... args);
+template <class... Args> iterator emplace(const_iterator position, Args&&... 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-closed.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.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-11-29 <b>Last modified:</b> 2008-03-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<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<B::iterator, B::iterator></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<iterator, iterator></tt>, <tt>equal_range</tt> were to
+return <tt>pair<local_iterator, local_iterator></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.2.5 [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<<ins>local_</ins>iterator,<ins>local_</ins>iterator>; pair<const_<ins>local_</ins>iterator,const_<ins>local_</ins>iterator></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 Θ<tt>(b.count(k))</tt>. Worst case Θ<tt>(b.size())</tt>. </td>
+</tr>
+</tbody></table>
+
+
+
+
+
+<hr>
+<h3><a name="767"></a>767. Forwarding and backward compatibility</h3>
+<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Sylvain Pion <b>Opened:</b> 2007-12-28 <b>Last modified:</b> 2008-06-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Playing with g++'s C++0X mode, I noticed that the following
+code, which used to compile:
+</p>
+
+<blockquote><pre>#include <vector>
+
+int main()
+{
+ std::vector<char *> v;
+ v.push_back(0);
+}
+</pre></blockquote>
+
+<p>
+now fails with the following error message:
+</p>
+
+<blockquote>.../include/c++/4.3.0/ext/new_allocator.h: In member
+function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*,
+_Args&& ...) [with _Args = int, _Tp = char*]':
+.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void
+std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with
+_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]'
+test.cpp:6: instantiated from here
+.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid
+conversion from 'int' to 'char*'
+</blockquote>
+
+<p>
+As far as I know, g++ follows the current draft here.
+</p>
+<p>
+Does the committee really intend to break compatibility for such cases?
+</p>
+
+<p><i>[
+Sylvain adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I just noticed that <tt>std::pair</tt> has the same issue.
+The following now fails with GCC's -std=c++0x mode:
+</p>
+
+<blockquote><pre>#include <utility>
+
+int main()
+{
+ std::pair<char *, char *> p (0,0);
+}
+</pre></blockquote>
+
+<p>
+I have not made any general audit for such problems elsewhere.
+</p>
+</blockquote>
+
+<p><i>[
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Motivation is to handle the old-style int-zero-valued NULL pointers.
+Problem: this solution requires concepts in some cases, which some users
+will be slow to adopt. Some discussion of alternatives involving
+prohibiting variadic forms and additional library-implementation
+complexity.
+</p>
+<p>
+Discussion of "perfect world" solutions, the only such solution put
+forward being to retroactively prohibit use of the integer zero for a
+NULL pointer. This approach was deemed unacceptable given the large
+bodies of pre-existing code that do use integer zero for a NULL pointer.
+</p>
+<p>
+Another approach is to change the member names. Yet another approach is
+to forbid the extension in absence of concepts.
+</p>
+<p>
+Resolution: These issues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>) will be subsumed into a
+paper to be produced by Alan Talbot in time for review at the 2008
+meeting in France. Once this paper is produced, these issues will be
+moved to NAD.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following rows to Table 90 "Optional sequence container operations", 23.2.3 [sequence.reqmts]:
+</p>
+
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th>
+</tr>
+
+<tr>
+<td>
+<tt>a.push_front(t)</tt>
+</td>
+<td>
+<tt>void</tt>
+</td>
+<td>
+<tt>a.insert(a.begin(), t)</tt><br>
+<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
+</td>
+<td>
+<tt>list, deque</tt>
+</td>
+</tr>
+
+<tr>
+<td>
+<tt>a.push_front(rv)</tt>
+</td>
+<td>
+<tt>void</tt>
+</td>
+<td>
+<tt>a.insert(a.begin(), rv)</tt><br>
+<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
+</td>
+<td>
+<tt>list, deque</tt>
+</td>
+</tr>
+
+<tr>
+<td>
+<tt>a.push_back(t)</tt>
+</td>
+<td>
+<tt>void</tt>
+</td>
+<td>
+<tt>a.insert(a.end(), t)</tt><br>
<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
</td>
<td>
</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>
+<td>
+<tt>a.push_back(rv)</tt>
+</td>
+<td>
+<tt>void</tt>
+</td>
+<td>
+<tt>a.insert(a.end(), rv)</tt><br>
+<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
+</td>
+<td>
+<tt>list, deque, vector, basic_string</tt>
+</td>
+</tr>
+
+</tbody></table>
+</blockquote>
+
+<p>
+Change the synopsis in 23.3.2 [deque]:
+</p>
+
+<blockquote><pre><ins>void push_front(const T& x);</ins>
+<ins>void push_front(T&& x);</ins>
+<ins>void push_back(const T& x);</ins>
+<ins>void push_back(T&& x);</ins>
+template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
+template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
+</pre></blockquote>
+
+<p>
+Change 23.3.2.3 [deque.modifiers]:
+</p>
+
+<blockquote><pre><ins>void push_front(const T& x);</ins>
+<ins>void push_front(T&& x);</ins>
+<ins>void push_back(const T& x);</ins>
+<ins>void push_back(T&& x);</ins>
+template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
+template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
+</pre></blockquote>
+
+<p>
+Change the synopsis in 23.3.4 [list]:
+</p>
+
+<blockquote><pre><ins>void push_front(const T& x);</ins>
+<ins>void push_front(T&& x);</ins>
+<ins>void push_back(const T& x);</ins>
+<ins>void push_back(T&& x);</ins>
+template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
+template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
+</pre></blockquote>
+
+<p>
+Change 23.3.4.3 [list.modifiers]:
+</p>
+
+<blockquote><pre><ins>void push_front(const T& x);</ins>
+<ins>void push_front(T&& x);</ins>
+<ins>void push_back(const T& x);</ins>
+<ins>void push_back(T&& x);</ins>
+template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
+template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
+</pre></blockquote>
+
+<p>
+Change the synopsis in 23.3.6 [vector]:
+</p>
+
+<blockquote><pre><ins>void push_back(const T& x);</ins>
+<ins>void push_back(T&& x);</ins>
+template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
+</pre></blockquote>
+
+<p>
+Change 23.3.6.4 [vector.modifiers]:
+</p>
+
+<blockquote><pre><ins>void push_back(const T& x);</ins>
+<ins>void push_back(T&& x);</ins>
+template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
+</pre></blockquote>
+
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
+</p>
+
+<p>
+If there is still an issue with pair, Howard should submit another issue.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="773"></a>773. issues with random</h3>
+<p><b>Section:</b> 26.5.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>Opened:</b> 2008-01-14 <b>Last modified:</b> 2008-02-27</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.5.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.5.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.5.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.4.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>Opened:</b> 2008-02-02 <b>Last modified:</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#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.4.3.2 [thread.lock.unique]:
+</p>
+
+<blockquote><pre>template <class Mutex>
+class unique_lock
+{
+public:
+ ...
+ mutex_type* <del>release</del> <ins>disown</ins>();
+ ...
+};
+</pre></blockquote>
+
+<p>
+Change 30.4.3.2.3 [thread.lock.unique.mod]:
+</p>
+
+<blockquote><pre>mutex_type *<del>release</del> <ins>disown</ins>();
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3>
+<p><b>Section:</b> 20.9 [time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Opened:</b> 2008-02-03 <b>Last modified:</b> 2008-09-30</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time">issues</a> in [time].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The draft C++0x thread library requires that the time points of type
+<tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated
+Universal Time (UTC) (section X [datetime.system]). This can lead to
+surprising behavior when a library user performs a duration-based wait,
+such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the
+problem may be found in the
+<a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a>
+section in POSIX, but in summary:
+</p>
+
+<ul>
+<li>
+Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX
+equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times
+to address the problem of spurious wakeups.
+</li>
+
+<li>
+The typical use of the timed wait operations is to perform a relative
+wait. This may be achieved by first calculating an absolute time as the
+sum of the current time and the desired duration. In fact, the C++0x
+thread library includes duration-based overloads of
+<tt>condition_variable::timed_wait()</tt> that behave as if by calling the
+corresponding absolute time overload with a time point value of
+<tt>get_system_time() + rel_time</tt>.
+</li>
+
+<li>
+A UTC clock may be affected by changes to the system time, such as
+synchronization with an external source, leap seconds, or manual changes
+to the clock.
+</li>
+
+<li>
+Should the clock change during a timed wait operation, the actual
+duration of the wait will not be the expected length. For example, a
+user may intend a timed wait of one second duration but, due to an
+adjustment of the system clock backwards by a minute, the wait instead
+takes 61 seconds.
+</li>
+</ul>
+
+<p>
+POSIX solves the problem by introducing a new monotonic clock, which is
+unaffected by changes to the system time. When a condition variable is
+initialized, the user may specify whether the monotonic clock is to be
+used. (It is worth noting that on POSIX systems it is not possible to
+use <tt>condition_variable::native_handle()</tt> to access this facility, since
+the desired clock type must be specified during construction of the
+condition variable object.)
+</p>
+
+<p>
+In the context of the C++0x thread library, there are added dimensions
+to the problem due to the need to support platforms other than POSIX:
+</p>
+
+<ul>
+<li>
+Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
+</li>
+
+<li>
+Some environments do not have a monotonic clock, but do have a UTC clock.
+</li>
+
+<li>
+The Microsoft Windows API's synchronization functions use relative
+timeouts based on an implied monotonic clock. A program that switches
+from the Windows API to the C++0x thread library will now find itself
+susceptible to clock changes.
+</li>
+</ul>
+
+<p>
+One possible minimal solution:
+</p>
+
+<ul>
+<li>
+Strike normative references to UTC and an epoch based on 1970-01-01.
+</li>
+
+<li>
+Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt>
+implementation-defined (i.e standard library implementors may choose the
+appropriate underlying clock based on the capabilities of the target
+platform).
+</li>
+
+<li>
+Add a non-normative note encouraging use of a monotonic clock.
+</li>
+
+<li>
+Remove <tt>system_time::seconds_since_epoch()</tt>.
+</li>
+
+<li>
+Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns
+= 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>.
+</li>
+</ul>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+<p><b>Rationale:</b></p>
+Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661: A Foundation to Sleep On</a>.
+
+
+
+
+
+<hr>
+<h3><a name="790"></a>790. <tt>xor_combine::seed</tt> not specified</h3>
+<p><b>Section:</b> X [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>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-02-27</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&)</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-defects.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.5.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>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-03-11</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.5.8.5.2 [rand.dist.samp.pconst]:
+</p>
+
+<blockquote><pre>template <class RealType = double>
+class piecewise_constant_distribution
+{
+public:
+ ...
+ vector<double> <del>densities</del> <ins>probabilities</ins>() const;
+ ...
+};
+</pre></blockquote>
+
+<p>
+Change 26.5.8.5.2 [rand.dist.samp.pconst]/6:
+</p>
+
+<blockquote><pre>vector<double> <del>densities</del> <ins>probabilities</ins>() const;
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
+<p><b>Section:</b> 26.5.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%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>discrete_distribution</tt> should have a constructor like:
+</p>
+
+<blockquote><pre>template<class _Fn>
+ discrete_distribution(result_type _Count, double _Low, double _High,
+ _Fn& _Func);
+</pre></blockquote>
+
+<p>
+(Makes it easier to fill a histogram with function values 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><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Bill is not requesting this.
+</p>
+<p>
+Marc Paterno: <tt>_Fn</tt> cannot return negative values at the points where the
+function is sampled. It is sampled in the middle of each bin. <tt>_Fn</tt> cannot
+return 0 everywhere it is sampled.
+</p>
+<p>
+Jens: lambda expressions are rvalues
+</p>
+<p>
+Add a library issue to provide an
+<tt>initializer_list<double></tt> constructor for
+<tt>discrete_distribution</tt>.
+</p>
+<p>
+Marc Paterno: dislikes reference for <tt>_Fn</tt> parameter. Make it pass-by-value (to use lambda),
+use <tt>std::ref</tt> to wrap giant-state function objects.
+</p>
+<p>
+Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference.
+</p>
+<p>
+Daniel to draft wording.
+</p>
+</blockquote>
+
+<p><i>[
+Pre San Francisco, Daniel provided wording:
+]</i></p>
+
+
+<blockquote>
+The here proposed changes of the WP refer to the current state of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
+During the Sophia Antipolis meeting two different proposals came up
+regarding the functor argument type, either by value or by rvalue-reference.
+For consistence with existing conventions (state-free algorithms and the
+<tt>general_pdf_distribution</tt> c'tor signature) the author decided to propose a
+function argument that is provided by value. If severe concerns exists that
+stateful functions would be of dominant relevance, it should be possible to
+replace the two occurrences of <tt>Func</tt> by <tt>Func&&</tt> in this proposal as part
+of an editorial process.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p><b>Non-concept version of the proposed resolution</b></p>
+
+<ol>
+<li>
+<p>
+In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
+<em>before</em> the member declaration
+</p>
+
+<blockquote><pre>explicit discrete_distribution(const param_type& parm);
+</pre></blockquote>
+
+<p>
+insert:
+</p>
+
+
+<blockquote><pre>template<typename Func>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+</pre></blockquote>
+</li>
+
+<li>
+<p>
+Between p.4 and p.5 insert a series of new paragraphs as part of the
+new member description::
+</p>
+<blockquote><pre>template<typename Func>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+</pre>
+
+<p>
+<i>Complexity:</i> Exactly nf invocations of fw.
+</p>
+<p>
+<i>Requires:</i>
+</p>
+<ol type="a">
+<li>
+fw shall be callable with one argument of type double, and shall
+return values of a type convertible to double;</li>
+
+<li>If nf > 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> < <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
+<tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN,
+and non-infinity;</li>
+
+<li>The following relations shall hold: nf ≥ 0, and 0 < S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
+
+</ol>
+
+<p>
+<i>Effects:</i>
+</p>
+<ol type="a">
+<li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
+ consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
+
+<li>
+<p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> +
+0.5 * deltax.</p>
+<blockquote><pre>For each k = 0, . . . ,n-1, calculates:
+ <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
+ <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
+</pre></blockquote>
+</li>
+<li>
+<p>Constructs a discrete_distribution object with probabilities:</p>
+<blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S for k = 0, . . . , n-1.
+</pre></blockquote>
+</li>
+</ol>
+</blockquote>
+</li>
+</ol>
+
+<p><b>Concept version of the proposed resolution</b></p>
+
+
+<ol>
+<li>
+<p>
+In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
+<em>before</em> the member declaration
+</p>
+
+<blockquote><pre>explicit discrete_distribution(const param_type& parm);
+</pre></blockquote>
+
+<p>
+insert:
+</p>
+
+
+<blockquote><pre>template<Callable<auto, double> Func>
+ requires Convertible<Func::result_type, double>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+</pre></blockquote>
+</li>
+
+<li>
+<p>
+Between p.4 and p.5 insert a series of new paragraphs as part of the
+new member description::
+</p>
+<blockquote><pre>template<Callable<auto, double> Func>
+ requires Convertible<Func::result_type, double>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+</pre>
+
+<p>
+<i>Complexity:</i> Exactly nf invocations of fw.
+</p>
+<p>
+<i>Requires:</i>
+</p>
+<ol type="a">
+<li>If nf > 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> < <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
+<tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN,
+and non-infinity;</li>
+
+<li>The following relations shall hold: nf ≥ 0, and 0 < S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
+
+</ol>
+
+<p>
+<i>Effects:</i>
+</p>
+<ol type="a">
+<li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
+ consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
+
+<li>
+<p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> +
+0.5 * deltax.</p>
+<blockquote><pre>For each k = 0, . . . ,n-1, calculates:
+ <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
+ <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
+</pre></blockquote>
+</li>
+<li>
+<p>Constructs a discrete_distribution object with probabilities:</p>
+<blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S for k = 0, . . . , n-1.
+</pre></blockquote>
+</li>
+</ol>
+</blockquote>
+</li>
+</ol>
+
+
+
+<p><b>Rationale:</b></p>
+Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
+
+
+
+
+
+<hr>
+<h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
+<p><b>Section:</b> 26.5.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%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>piecewise_constant_distribution</tt> should have a constructor like:
+</p>
+
+<blockquote><pre>template<class _Fn>
+ piecewise_constant_distribution(size_t _Count,
+ _Ty _Low, _Ty _High, _Fn& _Func);
+</pre></blockquote>
+
+<p>
+(Makes it easier to fill a histogram with function values over a range.
+The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>) make a sensible replacement for
+<tt>general_pdf_distribution</tt>.)
+</p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Marc: uses variable width of bins and weight for each bin. This is not
+giving enough flexibility to control both variables.
+</p>
+<p>
+Add a library issue to provide an constructor taking an
+<tt>initializer_list<double></tt> and <tt>_Fn</tt> for <tt>piecewise_constant_distribution</tt>.
+</p>
+<p>
+Daniel to draft wording.
+</p>
+</blockquote>
+
+<p><i>[
+Pre San Francisco, Daniel provided wording.
+]</i></p>
+
+
+<blockquote>
+The here proposed changes of the WP refer to the current state of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
+For reasons explained in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, the author decided to propose a function
+argument that is provided by value. The issue proposes a c'tor signature,
+that does not take advantage of the full flexibility of
+<tt>piecewise_constant_distribution</tt>,
+because it restricts on a constant bin width, but the use-case seems to
+be popular enough to justify it's introduction.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p><b>Non-concept version of the proposed resolution</b></p>
+
+<ol>
+<li>
+<p>
+In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
+just <em>before</em> the member declaration
+</p>
+
+<blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm);
+</pre></blockquote>
+<p>
+insert:
+</p>
+<blockquote><pre>template<typename Func>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+</pre></blockquote>
+</li>
+
+<li>
+<p>
+Between p.4 and p.5 insert a new sequence of paragraphs nominated
+below as [p5_1], [p5_2],
+[p5_3], and [p5_4] as part of the new member description:
+</p>
+
+<blockquote><pre>template<typename Func>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+</pre>
+<blockquote>
+<p>
+[p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
+</p>
+<p>
+[p5_2] <i>Requires:</i>
+</p>
+<ol type="a">
+<li><tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
+return values of a type convertible to double;
+</li>
+<li>
+For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight
+value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
+</li>
+<li>
+The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> < <tt><i>x<sub>max</sub></i></tt>, and
+0 < S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
+</li>
+</ol>
+<p>
+[p5_3] <i>Effects:</i>
+</p>
+<ol type="a">
+<li>
+<p>If nf == 0,</p>
+ <ol type="a">
+ <li>
+sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
+<li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
+ value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
+<li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and
+ <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
+</li>
+</ol>
+</li>
+<li>
+<p>Otherwise,</p>
+<ol type="a">
+<li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n,
+ <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
+</li>
+<li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p>
+<blockquote><pre>for each k = 0, . . . ,n-1, calculates:
+ <tt><i>dx<sub>k</sub></i></tt> = k * deltax
+ <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
+ <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
+ <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
+</pre></blockquote>
+<p> and</p>
+</li>
+<li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
+</ol>
+</li>
+<li>
+<p>
+Constructs a <tt>piecewise_constant_distribution</tt> object with
+the above computed sequence <tt>b</tt> as the interval boundaries
+and with the probability densities:
+</p>
+<blockquote><pre><tt><i>ρ<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax) for k = 0, . . . , n-1.
+</pre></blockquote>
+</li>
+</ol>
+<p>
+[p5_4] [<i>Note:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly
+ known as the <i>bins</i> of a histogram. <i>-- end note</i>]
+ </p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+<p><b>Concept version of the proposed resolution</b></p>
+
+<ol>
+<li>
+<p>
+In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
+just <em>before</em> the member declaration
+</p>
+
+<blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm);
+</pre></blockquote>
+<p>
+insert:
+</p>
+<blockquote><pre>template<Callable<auto, RealType> Func>
+ requires Convertible<Func::result_type, double>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+</pre></blockquote>
+</li>
+
+<li>
+<p>
+Between p.4 and p.5 insert a new sequence of paragraphs nominated
+below as [p5_1], [p5_2],
+[p5_3], and [p5_4] as part of the new member description:
+</p>
+
+<blockquote><pre>template<Callable<auto, RealType> Func>
+ requires Convertible<Func::result_type, double>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+</pre>
+<blockquote>
+<p>
+[p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
+</p>
+<p>
+[p5_2] <i>Requires:</i>
+</p>
+<ol type="a">
+<li>
+For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight
+value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
+</li>
+<li>
+The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> < <tt><i>x<sub>max</sub></i></tt>, and
+0 < S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
+</li>
+</ol>
+<p>
+[p5_3] <i>Effects:</i>
+</p>
+<ol type="a">
+<li>
+<p>If nf == 0,</p>
+ <ol type="a">
+ <li>
+sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
+<li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
+ value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
+<li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and
+ <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
+</li>
+</ol>
+</li>
+<li>
+<p>Otherwise,</p>
+<ol type="a">
+<li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n,
+ <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
+</li>
+<li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p>
+<blockquote><pre>for each k = 0, . . . ,n-1, calculates:
+ <tt><i>dx<sub>k</sub></i></tt> = k * deltax
+ <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
+ <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
+ <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
+</pre></blockquote>
+<p> and</p>
+</li>
+<li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
+</ol>
+</li>
+<li>
+<p>
+Constructs a <tt>piecewise_constant_distribution</tt> object with
+the above computed sequence <tt>b</tt> as the interval boundaries
+and with the probability densities:
+</p>
+<blockquote><pre><tt><i>ρ<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax) for k = 0, . . . , n-1.
+</pre></blockquote>
+</li>
+</ol>
+<p>
+[p5_4] [<i>Note:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly
+ known as the <i>bins</i> of a histogram. <i>-- end note</i>]
+ </p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+
+
+<p><b>Rationale:</b></p>
+Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
+
+
+
+
+
+<hr>
+<h3><a name="795"></a>795. <tt>general_pdf_distribution</tt> should be dropped</h3>
+<p><b>Section:</b> X [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>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-03-11</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-closed.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-closed.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.5.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>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-02-27</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.5.5 [rand.predef]/p5:
+</p>
+
+<blockquote>
+<pre>typedef subtract_with_carry_engine<uint_fast64_t, 48, 5, 12>
+ 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.5.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>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-02-27</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.5.5 [rand.predef]/p6:
+</p>
+
+<blockquote>
+<pre>typedef discard_block_engine<ranlux48_base, 389, 11>
+ 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.5.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>Opened:</b> 2008-02-18 <b>Last modified:</b> 2008-03-11</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.5.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.5.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.5.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="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3>
+<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2008-02-18 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is
+defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities.
+Previous versions of this algorithm and the general logic behind it
+suggest that this is an oversight and that in the context of the
+for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded
+upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits
+in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt>
+to 0.
+</p>
+
+<p>
+There are two more minor issues:
+</p>
+
+<ul>
+<li>
+Strictly speaking <tt>end - begin</tt> is not defined since
+<tt>InputIterator</tt> is not required to be a random access iterator.
+</li>
+<li>
+Currently all integral types are allowed as input to the <tt>seed_seq</tt>
+constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily
+complicates the implementation without any real benefit to the user.
+I'd suggest to exclude <tt>bool</tt>s as input.
+</li>
+</ul>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<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>
+This issue is made moot if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a> is accepted.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Replace 26.5.7.1 [rand.util.seedseq] paragraph 6 with:
+</p>
+
+<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 > 0; n -= 32 )
+ v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
+</pre></blockquote>
+</blockquote>
+
+
+<p><b>Rationale:</b></p>
+Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
+
+
+
+
+
+<hr>
+<h3><a name="802"></a>802. <tt>knuth_b</tt> returns wrong value</h3>
+<p><b>Section:</b> 26.5.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>Opened:</b> 2008-02-20 <b>Last modified:</b> 2008-03-17</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.5.5 [rand.predef]/p8:
+</p>
+
+<blockquote>
+<pre>typedef shuffle_order_engine<minstd_rand0, 256>
+ 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>
+
+
+
+
+
+<hr>
+<h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3>
+<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Charles Karney <b>Opened:</b> 2008-02-22 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt>
+object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a
+32-bit vector.
+</p>
+<p>
+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 < 32) v.push_back(n);</tt>" (Otherwise
+the unsigned short vectors [1, 0] and [1] generate the same sequence.)
+</li>
+<li>
+Portability demanded the introduction of the template parameter <tt>u</tt>.
+(Otherwise some sequences could not be obtained on computers where no
+integer types are exactly 32-bits wide.)
+</li>
+<li>
+The description and algorithm have become unduly complicated.
+</li>
+</ol>
+<p>
+I 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>
+Here's how the description would read
+</p>
+<blockquote>
+<p>
+26.5.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
+</p>
+
+<blockquote>
+<pre>template<class InputIterator>
+ 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<InputIterator>::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-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Marc Paterno wants portable behavior between 32bit and 64bit machines;
+we've gone to significant trouble to support portability of engines and
+their values.
+</p>
+<p>
+Jens: the new algorithm looks perfectly portable
+</p>
+<p>
+Marc Paterno to review off-line.
+</p>
+<p>
+Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..."
+</p>
+<p>
+Disposition: move to review; unanimous consent.
+</p>
+<p>
+(moots <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>)
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.5.7.1 [rand.util.seedseq]:
+</p>
+
+<blockquote>
+<pre>template<class InputIterator<del>,
+ size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
+ 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<InputIterator>::value_type</tt> shall denote an integral type.
+</p>
+<p>
+-6- Constructs a <tt>seed_seq</tt> object by <ins>the following algorithm</ins> <del>rearranging some or all of the bits of the supplied sequence
+<tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
+</p>
+<p>
+<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 = ∑<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$ < 32)
+ v.push_back($n$);
+for( ; $n$ > 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>
+
+
+<p><b>Rationale:</b></p>
+Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
+
+
+
+
+
+<hr>
+<h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
+<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-03-14 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<blockquote><pre>#include <utility>
+
+int main()
+{
+ std::pair<char *, char *> p (0,0);
+}
+</pre></blockquote>
+
+<p>
+I just got a bug report about that, because it's valid C++03, but not
+C++0x. The important realization, for me, is that the emplace
+proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
+issue---didn't cause this break in backward compatibility. The break
+actually happened when we added this pair constructor as part of adding
+rvalue references into the language, long before variadic templates or
+emplace came along:
+</p>
+
+<blockquote><pre>template<class U, class V> pair(U&& x, V&& y);
+</pre></blockquote>
+
+<p>
+Now, concepts will address this issue by constraining that <tt>pair</tt>
+constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
+"second", e.g. (from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
+</p>
+
+<blockquote><pre>template<class U , class V >
+requires Constructible<T1, U&&> && Constructible<T2, V&&>
+pair(U&& x , V&& y );
+</pre></blockquote>
+
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+<p>
+Suggested to resolve using pass-by-value for that case.
+</p>
+<p>
+Side question: Should pair interoperate with tuples? Can construct a
+tuple of a pair, but not a pair from a two-element tuple.
+</p>
+<p>
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+<p><b>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+Solved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
+</blockquote>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3>
+<p><b>Section:</b> 25.5.1 [alg.sort] <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> Paul McKenney <b>Opened:</b> 2008-02-27 <b>Last modified:</b> 2008-09-17</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>
+Multi-threading is a good thing, but unsolicited multi-threading can
+potentially be harmful. For example, <tt>sort()</tt> performance might be
+greatly increased via a multithreaded implementation. However, such
+a multithreaded implementation could result in concurrent invocations
+of the user-supplied comparator. This would in turn result in problems
+given a caching comparator that might be written for complex sort keys.
+Please note that this is not a theoretical issue, as multithreaded
+implementations of <tt>sort()</tt> already exist.
+</p>
+<p>
+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>
+<p>
+</p>
+
+
+<p><b>Rationale:</b></p>
+This is already covered by 17.6.5.6/20 in N2723.
+
+
+
+
+
+<hr>
+<h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3>
+<p><b>Section:</b> 22.4.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-07 <b>Last modified:</b> 2008-06-18</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In the spirit of <tt>printf vs iostream</tt>...
+</p>
+
+<p>
+POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the
+implication is that in the absence of <tt>'</tt> no grouping characters are
+inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert
+grouping characters. Can this be considered a defect worth fixing for
+C++0x? Maybe <tt>ios_base</tt> needs an additional flag?
+</p>
+
+<p><i>[
+Pablo Halpern:
+]</i></p>
+
+
+<blockquote>
+I'm not sure it constitutes a defect, but I would be in favor of adding
+another flag (and corresponding manipulator).
+</blockquote>
+
+<p><i>[
+Martin Sebor:
+]</i></p>
+
+
+<blockquote>
+I don't know if it qualifies as a defect but I agree that there
+should be an easy way to control whether the thousands separator
+should or shouldn't be inserted. A new flag would be in line with
+the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or
+<tt>showbase</tt>).
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+This is not a part of C99. LWG suggests submitting a paper may be appropriate.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="831"></a>831. wrong type for not_eof()</h3>
+<p><b>Section:</b> 21.2.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2008-04-23 <b>Last modified:</b> 2008-06-19</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+ In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function
+ is using an argument of type <i>e</i> which denotes an object of
+ type <code>X::int_type</code>. However, the specializations in
+ 21.2.3 [char.traits.specializations] all use <code>char_type</code>.
+ This would effectively mean that the argument type actually can't
+ represent EOF in the first place. I'm pretty sure that the type used
+ to be <code>int_type</code> which is quite obviously the only sensible
+ argument.
+</p>
+<p>
+ This issue is close to being editorial. I suspect that the proposal
+ changing this section to include the specializations for <code>char16_t</code>
+ and <code>char32_t</code> accidentally used the wrong type.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+ In 21.2.3.1 [char.traits.specializations.char],
+ 21.2.3.2 [char.traits.specializations.char16_t],
+ 21.2.3.3 [char.traits.specializations.char32_t], and
+ [char.traits.specializations.wchar_t] correct the
+ argument type from <code>char_type</code> to <code>int_type</code>.
+</p>
+
+
+<p><b>Rationale:</b></p>
+Already fixed in WP.
+
+
+
+
+
+<hr>
+<h3><a name="832"></a>832. Applying constexpr to System error support</h3>
+<p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-05-14 <b>Last modified:</b> 2008-09-17</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">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Initialization of objects of class <tt>error_code</tt>
+(19.5.2 [syserr.errcode]) and class
+<tt>error_condition</tt> (19.5.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>
+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-defects.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.5.2 [syserr.errcode]) and class
+<tt>error_condition</tt> (19.5.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-defects.html#804">804</a> that is arguably an editorial question,
+presenting it as a pointer becomes more or less required with this
+proposal, given <tt>constexpr</tt> does not play well with references. The
+proposed resolution thus changes the private member to a pointer, which
+also brings it in sync with real implementations.
+</p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+On going question of extern pointer vs. inline functions for interface.
+</blockquote>
+
+<p><i>[
+Pre-San Francisco:
+]</i></p>
+
+
+<blockquote>
+<p>
+Beman Dawes reports that this proposal is unimplementable, and thus NAD.
+</p>
+<p>
+Implementation would require <tt>constexpr</tt> objects of classes derived
+from class <tt>error_category</tt>, which has virtual functions, and that is
+not allowed by the core language. This was determined when trying to
+implement the proposal using a constexpr enabled compiler provided
+by Gabriel Dos Reis, and subsequently verified in discussions with
+Gabriel and Jens Maurer.
+</p>
+
+</blockquote>
+
+
+<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-defects.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-defects.html#805">805</a> has not been applied, the names in this
+proposal must be adjusted accordingly.
+</p>
+
+<p>
+Change 19.5.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& get_generic_category();</del>
+<del>const error_category& get_system_category();</del>
+
+<del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
+<del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
+</pre></blockquote>
+
+<p>
+Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
+</p>
+
+<blockquote>
+<pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
+</pre>
+<p>
+<del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
+to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
+class <tt>error_category</tt>.
+</p>
+
+<p>
+<del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
+functions shall behave as specified for the class <tt>error_category</tt>. The
+object's <tt>name</tt> virtual function shall return a pointer to the string
+<tt>"GENERIC"</tt>.
+</p>
+
+<pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
+</pre>
+
+<p>
+<del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
+to <del>an</del> <ins>a statically
+initialized</ins> object of a type derived from class <tt>error_category</tt>.
+</p>
+
+<p>
+<del><i>Remarks:</i></del> The object's <tt>equivalent</tt> virtual functions shall behave as
+specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
+shall return a pointer to the string <tt>"system"</tt>. The object's
+<tt>default_error_condition</tt> virtual function shall behave as follows:
+</p>
+
+<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.5.2.2 [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>&</del><ins>*</ins> cat);
+ ...
+ void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
+ ...
+ const error_category<del>&</del><ins>*</ins> category() const;
+ ...
+private:
+ int val_; // exposition only
+ const error_category<del>&</del><ins>*</ins> cat_; // exposition only
+</pre></blockquote>
+
+<p>
+Change 19.5.2.3 [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>&</del><ins>*</ins> cat);
+</pre>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+
+<p>
+Change 19.5.2.4 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers as indicated:
+</p>
+
+<blockquote>
+<pre>void assign(int val, const error_category<del>&</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.5.2.5 [syserr.errcode.observers] Class <tt>error_code</tt> observers as indicated:
+</p>
+
+<blockquote>
+<pre>const error_category<del>&</del><ins>*</ins> category() const;
+</pre>
+
+<p>
+<i>Returns:</i> <tt>cat_</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+
+<p>
+Change 19.5.3.2 [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>&</del><ins>*</ins> cat);
+ ...
+ void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
+ ...
+ const error_category<del>&</del><ins>*</ins> category() const;
+ ...
+private:
+ int val_; // exposition only
+ const error_category<del>&</del><ins>*</ins> cat_; // exposition only
+</pre>
+</blockquote>
+
+<p>
+Change 19.5.3.3 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
+</p>
+
+<blockquote>
+<pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat);
+</pre>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+
+<p>
+Change 19.5.3.4 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
+</p>
+
+<blockquote>
+<pre>void assign(int val, const error_category<del>&</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.5.3.5 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
+</p>
+
+<blockquote>
+<pre>const error_category<del>&</del><ins>*</ins> category() const;
+</pre>
+<p>
+<i>Returns:</i> <tt>cat_</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+
+<p>
+Throughout 19.5 [syserr] System error support, change "<tt>category().</tt>" to "<tt>category()-></tt>".
+Appears approximately six times.
+</p>
+
+<p>
+<i>[Partially Editorial]</i> In 19.5.4 [syserr.compare] Comparison operators,
+paragraphs 2 and 4, change "<tt>category.equivalent(</tt>" to
+"<tt>category()->equivalent(</tt>".
+</p>
+
+<p>
+Change 19.5.5.1 [syserr.syserr.overview] Class system_error overview as indicated:
+</p>
+
+<blockquote><pre>public:
+ system_error(error_code ec, const string& what_arg);
+ system_error(error_code ec);
+ system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat,
+ const string& what_arg);
+ system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat);
+</pre></blockquote>
+
+<p>
+Change 19.5.5.2 [syserr.syserr.members] Class system_error members as indicated:
+</p>
+
+<blockquote>
+<pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat, const string& what_arg);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
+<tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
+</p>
+</blockquote>
+
+<pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
+<tt>strcmp(runtime_error::what(), "") == 0</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+NAD because Beman said so.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="840"></a>840. <tt>pair</tt> default template argument</h3>
+<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-05-23 <b>Last modified:</b> 2008-06-18</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I have one issue with <tt>std::pair</tt>. Well, it might just be a very annoying
+historical accident, but why is there no default template argument for
+the second template argument? This is so annoying when the type in
+question is looong and hard to write (type deduction with <tt>auto</tt> won't
+help those cases where we use it as a return or argument type).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 20.3 [utility] to read:
+</p>
+
+<blockquote><pre>template <class T1, class T2 <ins>= T1</ins>> struct pair;
+</pre></blockquote>
+
+<p>
+Change 20.3.3 [pairs] to read:
+</p>
+
+<blockquote><pre>namespace std {
+ template <class T1, class T2 <ins>= T1</ins>>
+ struct pair {
+ typedef T1 first_type;
+ typedef T2 second_type;
+ ...
+</pre></blockquote>
+
+
+<p><b>Rationale:</b></p>
+<tt>std::pair</tt> is a heterogeneous container.
+
+
+
+
+
+<hr>
+<h3><a name="841"></a>841. cstdint.syn inconsistent with C99</h3>
+<p><b>Section:</b> 18.4.1 [cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2008-09-17</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+ <p>
+
+In specifying the names of macros and types defined in
+header <code><stdint.h></code>, C99 makes use of the
+symbol <code><i>N</i></code> to accommodate unusual platforms with
+word sizes that aren't powers of two. C99
+permits <code><i>N</i></code> to take on any positive integer value
+(including, for example, 24).
+
+ </p>
+ <p>
+
+In cstdint.syn Header <code><cstdint></code>
+synopsis, C++ on the other hand, fixes the value
+of <code><i>N</i></code> to 8, 16, 32, and 64, and specifies only
+types with these exact widths.
+
+ </p>
+ <p>
+ </p>
+
+In addition, paragraph 1 of the same section makes use of a rather
+informal shorthand notation to specify sets of macros. When
+interpreted strictly, the notation specifies macros such
+as <code>INT_8_MIN</code> that are not intended to be specified.
+
+ <p>
+
+Finally, the section is missing the usual table of symbols defined
+in that header, making it inconsistent with the rest of the
+specification.
+
+ </p>
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+
+I propose to use the same approach in the C++ spec as C99 uses, that
+is, to specify the header synopsis in terms of "exposition only" types
+that make use of the symbol <code><i>N</i></code> to denote one or
+more of a theoretically unbounded set of widths.
+
+ </p>
+ <p>
+
+Further, I propose to add a new table to section listing the symbols
+defined in the header using a more formal notation that avoids
+introducing inconsistencies.
+
+ </p>
+ <p>
+
+To this effect, in cstdint.syn
+Header <code><cstdint></code> synopsis, replace both the
+synopsis and paragraph 1 with the following text:
+
+ </p>
+ <blockquote>
+ <p>
+ </p><ol>
+ <li>
+
+In the names defined in the <code><cstdint></code> header, the
+symbol <code><i>N</i></code> represents a positive decimal integer
+with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the
+exception of exact-width types, macros and types for values
+of <code><i>N</i></code> in the set of 8, 16, 32, and 64 are
+required. Exact-width types, and any macros and types for values
+of <code><i>N</i></code> other than 8, 16, 32, and 64 are
+optional. However, if an implementation provides integer types with
+widths of 8, 16, 32, or 64 bits, the corresponding exact-width types
+and macros are required.
+
+ </li>
+ </ol>
+
+ <pre>namespace std {
+
+ // required types
+
+ // Fastest minimum-width integer types
+ typedef <i>signed integer type</i> int_fast8_t;
+ typedef <i>signed integer type</i> int_fast16_t;
+ typedef <i>signed integer type</i> int_fast32_t;
+ typedef <i>signed integer type</i> int_fast64_t;
+
+ typedef <i>unsigned integer type</i> uint_fast8_t;
+ typedef <i>unsigned integer type</i> uint_fast16_t;
+ typedef <i>unsigned integer type</i> uint_fast32_t;
+ typedef <i>unsigned integer type</i> uint_fast64_t;
+
+ // Minimum-width integer types
+ typedef <i>signed integer type</i> int_least8_t;
+ typedef <i>signed integer type</i> int_least16_t;
+ typedef <i>signed integer type</i> int_least32_t;
+ typedef <i>signed integer type</i> int_least64_t;
+
+ typedef <i>unsigned integer type</i> uint_least8_t;
+ typedef <i>unsigned integer type</i> uint_least16_t;
+ typedef <i>unsigned integer type</i> uint_least32_t;
+ typedef <i>unsigned integer type</i> uint_least64_t;
+
+ // Greatest-width integer types
+ typedef <i>signed integer type</i> intmax_t;
+ typedef <i>unsigned integer type</i> uintmax_t;
+
+ // optionally defined types
+
+ // Exact-width integer types
+ typedef <i>signed integer type</i> int<i>N</i>_t;
+ typedef <i>unsigned integer type</i> uint<i>N</i>_t;
+
+ // Fastest minimum-width integer types for values
+ // of <i>N</i> other than 8, 16, 32, and 64
+ typedef <i>signed integer type</i> uint_fast<i>N</i>_t;
+ typedef <i>unsigned integer type</i> uint_fast<i>N</i>_t;
+
+ // Minimum-width integer types for values
+ // of <i>N</i> other than 8, 16, 32, and 64
+ typedef <i>signed integer type</i> uint_least<i>N</i>_t;
+ typedef <i>unsigned integer type</i> uint_least<i>N</i>_t;
+
+ // Integer types capable of holding object pointers
+ typedef <i>signed integer type</i> intptr_t;
+ typedef <i>signed integer type</i> intptr_t;
+
+}</pre>
+ </blockquote>
+ <p>
+
+[Note to editor: Remove all of the existing paragraph 1 from cstdint.syn.]
+
+ </p>
+ <blockquote>
+ Table ??: Header <code><cstdint></code> synopsis
+ <table border="1">
+ <thead>
+ <tr>
+ <th>Type</th>
+ <th colspan="3">Name(s)</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td rowspan="11"><b>Macros:</b></td>
+ <td><tt>INT<i>N</i>_MIN</tt></td>
+ <td><tt>INT<i>N</i>_MAX</tt></td>
+ <td><tt>UINT<i>N</i>_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>INT_FAST<i>N</i>_MIN</tt></td>
+ <td><tt>INT_FAST<i>N</i>_MAX</tt></td>
+ <td><tt>UINT_FAST<i>N</i>_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>INT_LEAST<i>N</i>_MIN</tt></td>
+ <td><tt>INT_LEAST<i>N</i>_MAX</tt></td>
+ <td><tt>UINT_LEAST<i>N</i>_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>INTPTR_MIN</tt></td>
+ <td><tt>INTPTR_MAX</tt></td>
+ <td><tt>UINTPTR_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>INTMAX_MIN</tt></td>
+ <td><tt>INTMAX_MAX</tt></td>
+ <td><tt>UINTMAX_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>PTRDIFF_MIN</tt></td>
+ <td><tt>PTRDIFF_MAX</tt></td>
+ <td><tt>PTRDIFF_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>SIG_ATOMIC_MIN</tt></td>
+ <td><tt>SIG_ATOMIC_MAX</tt></td>
+ <td><tt>SIZE_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>WCHAR_MIN</tt></td>
+ <td><tt>WCHAR_MAX</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>WINT_MIN</tt></td>
+ <td><tt>WINT_MAX</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>INT<i>N</i>_C()</tt></td>
+ <td><tt>UINT<i>N</i>_C()</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>INTMAX_C()</tt></td>
+ <td><tt>UINTMAX_C()</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td rowspan="5"><b>Types:</b></td>
+ <td><tt>int<i>N</i>_t</tt></td>
+ <td><tt>uint<i>N</i>_t</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>int_fast<i>N</i>_t</tt></td>
+ <td><tt>uint_fast<i>N</i>_t</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>int_least<i>N</i>_t</tt></td>
+ <td><tt>uint_least<i>N</i>_t</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>intptr_t</tt></td>
+ <td><tt>uintptr_t</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>intmax_t</tt></td>
+ <td><tt>uintmax_t</tt></td>
+ <td></td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="849"></a>849. missing type traits to compute root class and derived class of types in a class hierachy</h3>
+<p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2008-09-16</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The type traits library contains various traits to dealt with
+polymorphic types, e.g. <tt>std::has_virtual_destructor</tt>, <tt>std::is_polymorphic</tt>
+and <tt>std::is_base_of</tt>. However, there is no way to compute the unique
+public base class of a type if such one exists. Such a trait could be
+very useful if one needs to instantiate a specialization made for the
+root class whenever a derived class is passed as parameter. For example,
+imagine that you wanted to specialize <tt>std::hash</tt> for a class
+hierarchy---instead of specializing each class, you could specialize the
+<tt>std::hash<root_class></tt> and provide a partial specialization that worked
+for all derived classes.
+</p>
+
+<p>
+This ability---to specify operations in terms of their equivalent in the
+root class---can be done with e.g. normal functions, but there is,
+AFAIK, no way to do it for class templates. Being able to access
+compile-time information about the type-hierachy can be very powerful,
+and I therefore also suggest traits that computes the directly derived
+class whenever that is possible.
+</p>
+
+<p>
+If the computation can not be done, the traits should fall back on an
+identity transformation. I expect this gives the best overall usability.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following to the synopsis in 20.6.2 [meta.type.synop] under "other transformations":
+</p>
+
+<blockquote><pre>template< class T > struct direct_base_class;
+template< class T > struct direct_derived_class;
+template< class T > struct root_base_class;
+</pre></blockquote>
+
+<p>
+Add three new entries to table 51 (20.6.7 [meta.trans.other]) with the following content
+</p>
+
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>Template</th><th>Condition</th><th>Comments</th>
+</tr>
+<tr>
+<td><tt>template< class T > struct direct_base_class;</tt></td>
+<td><tt>T</tt> shall be a complete type.</td>
+<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous direct base class of <tt>T</tt>.
+If no such type exists, the member typedef <tt>type</tt> shall equal <tt>T</tt>.</td>
+</tr>
+<tr>
+<td><tt>template< class T > struct direct_derived_class;</tt></td>
+<td><tt>T</tt> shall be a complete type.</td>
+<td>The member typedef <tt>type</tt> shall equal the unambiguous type which has <tt>T</tt>
+as an accessible unambiguous direct base class. If no such type exists, the member typedef
+<tt>type</tt> shall equal <tt>T</tt>.</td>
+</tr>
+<tr>
+<td><tt>template< class T > struct root_base_class;</tt></td>
+<td><tt>T</tt> shall be a complete type.</td>
+<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous most indirect base class of
+<tt>T</tt>. If no such type exists, the member typedef type shall equal <tt>T</tt>.</td>
</tr>
-
</tbody></table>
</blockquote>
+
+
+<p><b>Rationale:</b></p>
+2008-9-16 San Francisco: Issue pulled by author prior to being reviewed by the LWG.
+
+
+
+
+
+<hr>
+<h3><a name="855"></a>855. capacity() and reserve() for deque?</h3>
+<p><b>Section:</b> 23.3.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Hervé Brönnimann <b>Opened:</b> 2008-06-11 <b>Last modified:</b> 2008-09-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The main point is that <tt>capacity</tt> can be viewed as a mechanism to
+guarantee the validity of <tt>iterators</tt> when only <tt>push_back/pop_back</tt>
+operations are used. For <tt>vector</tt>, this goes with reallocation. For
+<tt>deque</tt>, this is a bit more subtle: <tt>capacity()</tt> of a <tt>deque</tt> may shrink,
+whereas that of <tt>vector</tt> doesn't. In a circular buffer impl. of the
+map, as Howard did, there is very similar notion of capacity: as long
+as <tt>size()</tt> is less than <tt>B * (</tt>total size of the map <tt>- 2)</tt>, it is
+guaranteed that no <tt>iterator</tt> is invalidated after any number of
+<tt>push_front/back</tt> and <tt>pop_front/back</tt> operations. But this does not
+hold for other implementations.
+</p>
+<p>
+Still, I believe, <tt>capacity()</tt> can be defined by <tt>size() +</tt> how many
+<tt>push_front/back</tt> minus <tt>pop_front/back</tt> that can be performed before
+terators are invalidated. In a classical impl., <tt>capacity() = size()
++ </tt> the min distance to either "physical" end of the deque (i.e.,
+counting the empty space in the last block plus all the blocks until
+the end of the map of block pointers). In Howard's circular buffer
+impl., <tt>capacity() = B * (</tt>total size of the map <tt>- 2)</tt> still works with
+this definition, even though the guarantee could be made stronger.
+</p>
+<p>
+A simple picture of a deque:
+</p>
+<blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z
+</pre></blockquote>
+<p>
+(A,Z mark the beginning/end, | the block boundaries, F=front, B=back,
+and - are uninitialized, + are initialized)
+In that picture: <tt>capacity = size() + min(dist(A,F),dist(B,Z)) = min
+(dist(A,B),dist(F,Z))</tt>.
+</p>
+<p>
+<tt>Reserve(n)</tt> can grow the map of pointers and add possibly a number of
+empty blocks to it, in order to guarantee that the next <tt>n-size()
+push_back/push_front</tt> operations will not invalidate iterators, and
+also will not allocate (i.e. cannot throw). The second guarantee is
+not essential and can be left as a QoI. I know well enough existing
+implementations of <tt>deque</tt> (sgi/stl, roguewave, stlport, and
+dinkumware) to know that either can be implemented with no change to
+the existing class layout and code, and only a few modifications if
+blocks are pre-allocated (instead of always allocating a new block,
+check if the next entry in the map of block pointers is not zero).
+</p>
+<p>
+Due to the difference with <tt>vector</tt>, wording is crucial. Here's a
+proposed wording to make things concrete; I tried to be reasonably
+careful but please double-check me:
+</p>
+
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+<p>
+Hans: should the Returns clause for capacity read "1 Returns: A lower
+bound..." rather than "1 Returns: An upper bound..."
+</p>
+<p>
+Howard: maybe what's needed is capacity_front and capacity_back. In
+fact, I think I implemented a deque that had these members as
+implementation details.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Add new signatures to synopsis in 23.3.2 [deque]:
+</p>
+
+<blockquote><pre>size_type capacity() const;
+bool reserve(size_type n);
+</pre></blockquote>
+
+<p>
+Add new signatures to 23.3.2.2 [deque.capacity]:
+</p>
+
+<blockquote>
+<pre>size_type capacity() const;
+</pre>
+<blockquote>
+<p>
+1 <i>Returns:</i> An upper bound on <tt>n + max(n_f - m_f, n_b - m_b)</tt> such
+that, for any sequence of <tt>n_f push_front</tt>, <tt>m_f pop_front</tt>, <tt>n_b
+push_back</tt>, and <tt>m_b pop_back</tt> operations, interleaved in any order,
+starting with the current <tt>deque</tt> of size <tt>n</tt>, the <tt>deque</tt> does not
+invalidate any of its iterators except to the erased elements.
+</p>
+<p>
+2 <i>Remarks:</i> Unlike a <tt>vector</tt>'s capacity, the capacity of a <tt>deque</tt> can
+decrease after a sequence of insertions at both ends, even if none of
+the operations caused the <tt>deque</tt> to invalidate any of its iterators
+except to the erased elements.
+</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>bool reserve(size_type n);
+</pre>
+<blockquote>
+<p>
+2 <i>Effects:</i> A directive that informs a <tt>deque</tt> of a planned sequence of
+<tt>push_front</tt>, <tt>pop_front</tt>, <tt>push_back</tt>, and <tt>pop_back</tt> operations, so that it
+can manage iterator invalidation accordingly. After <tt>reserve()</tt>,
+<tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt> if this
+operation returns <tt>true</tt>; and equal to the previous value of <tt>capacity()</tt>
+otherwise. If an exception is thrown, there are no effects.
+</p>
+<p>
+3 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this
+operation, and false otherwise.
+</p>
+<p>
+4 <i>Complexity:</i> It does not change the size of the sequence and takes
+at most linear time in <tt>n</tt>.
+</p>
+<p>
+5 <i>Throws:</i> <tt>length_error</tt> if <tt>n > max_size()</tt>.
+</p>
+<p>
+6 <i>Remarks:</i> It is guaranteed that no invalidation takes place during a
+sequence of <tt>insert</tt> or <tt>erase</tt> operations at either end that happens
+after a call to <tt>reserve()</tt> except to the erased elements, until the
+time when an insertion would make <tt>max(n_f-m_f, n_b-m_b)</tt> larger than
+<tt>capacity()</tt>, where <tt>n_f</tt> is the number of <tt>push_front</tt>, <tt>m_f</tt> of <tt>pop_front</tt>,
+<tt>n_b</tt> of <tt>push_back</tt>, and <tt>m_b</tt> of <tt>pop_back</tt> operations since the call to
+<tt>reserve()</tt>.
+</p>
+<p>
+7 An implementation is free to pre-allocate buffers so as to
+offer the additional guarantee that no exception will be thrown
+during such a sequence other than by the element constructors.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+And 23.3.2.3 [deque.modifiers] para 1, can be enhanced:
+</p>
+
+<blockquote>
+1 <i>Effects:</i> An insertion in the middle of the deque invalidates all the iterators and references to elements of the
+deque. An insertion at either end of the deque invalidates all the iterators to the deque,
+<ins>unless provisions have been made with reserve,</ins>
+but has no effect on the validity of references to elements of the deque.
+</blockquote>
+
+
+<p><b>Rationale:</b></p>
+Complication outweighs the benefit.
+
+
+
+
+
+<hr>
+<h3><a name="864"></a>864. Defect in atomic wording</h3>
+<p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-07-10 <b>Last modified:</b> 2008-09-17</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+There's an error in 29.6 [atomics.types.operations]/p9:
+</p>
+
+<blockquote>
+<pre>C atomic_load(const volatile A * object);
+C atomic_load_explicit(const volatile A * object, memory_order);
+C A ::load(memory_order order = memory_order_seq_cst) const volatile;
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> The <tt>order</tt> argument shall not be <tt>memory_order_acquire</tt> nor
+<tt>memory_order_acq_rel</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+I believe that this should state
+</p>
+<blockquote>
+shall not be <tt>memory_order_release</tt>.
+</blockquote>
+
+<p>
+There's also an error in 29.6 [atomics.types.operations]/p17:
+</p>
+
+<blockquote>
+... When only one <tt>memory_order</tt> argument is supplied, the value of success
+is <tt>order</tt>, and
+the value of failure is <tt>order</tt> except that a value of
+<tt>memory_order_acq_rel</tt> shall be replaced by the value
+<tt>memory_order_require</tt> ...
+</blockquote>
+<p>
+I believe this should state
+</p>
+<blockquote>
+shall be replaced by the value <tt>memory_order_acquire</tt> ...
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 29.6 [atomics.types.operations]/p9:
+</p>
+
+<blockquote>
+<pre>C atomic_load(const volatile A * object);
+C atomic_load_explicit(const volatile A * object, memory_order);
+C A ::load(memory_order order = memory_order_seq_cst) const volatile;
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> The <tt>order</tt> argument shall not be <del><tt>memory_order_acquire</tt></del>
+<ins><tt>memory_order_release</tt></ins> nor <tt>memory_order_acq_rel</tt>.
+</p>
+</blockquote>
+</blockquote>
+
<p>
-Change the synopsis in 23.2.2 [deque]:
+Change 29.6 [atomics.types.operations]/p17:
</p>
-<blockquote><pre><ins>void push_front(const T& x);</ins>
-<ins>void push_front(T&& x);</ins>
-<ins>void push_back(const T& x);</ins>
-<ins>void push_back(T&& x);</ins>
-template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
-template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
-</pre></blockquote>
+<blockquote>
+... When only one <tt>memory_order</tt> argument is supplied, the value of success
+is <tt>order</tt>, and
+the value of failure is <tt>order</tt> except that a value of
+<tt>memory_order_acq_rel</tt> shall be replaced by the value
+<del><tt>memory_order_require</tt></del> <ins><tt>memory_order_acquire</tt></ins> ...
+</blockquote>
-<p>
-Change 23.2.2.3 [deque.modifiers]:
-</p>
-<blockquote><pre><ins>void push_front(const T& x);</ins>
-<ins>void push_front(T&& x);</ins>
-<ins>void push_back(const T& x);</ins>
-<ins>void push_back(T&& x);</ins>
-template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
-template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
-</pre></blockquote>
-<p>
-Change the synopsis in 23.2.4 [list]:
-</p>
+<p><b>Rationale:</b></p>
+Already fixed by the time the LWG processed it.
+
-<blockquote><pre><ins>void push_front(const T& x);</ins>
-<ins>void push_front(T&& x);</ins>
-<ins>void push_back(const T& x);</ins>
-<ins>void push_back(T&& x);</ins>
-template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
-template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
-</pre></blockquote>
-<p>
-Change 23.2.4.3 [list.modifiers]:
-</p>
-<blockquote><pre><ins>void push_front(const T& x);</ins>
-<ins>void push_front(T&& x);</ins>
-<ins>void push_back(const T& x);</ins>
-<ins>void push_back(T&& x);</ins>
-template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
-template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
-</pre></blockquote>
+<hr>
+<h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3>
+<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-17 <b>Last modified:</b> 2008-09-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-Change the synopsis in 23.2.6 [vector]:
+Good ol' associative containers allow both function pointers and
+function objects as feasible
+comparators, as described in 23.2.4 [associative.reqmts]/2:
</p>
-<blockquote><pre><ins>void push_back(const T& x);</ins>
-<ins>void push_back(T&& x);</ins>
-template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
-</pre></blockquote>
+<blockquote>
+Each associative container is parameterized on <tt>Key</tt> and an ordering
+relation <tt>Compare</tt> that
+induces a strict weak ordering (25.3) on elements of Key. [..]. The
+object of type <tt>Compare</tt> is
+called the comparison object of a container. This comparison object
+may be a pointer to
+function or an object of a type with an appropriate function call operator.[..]
+</blockquote>
<p>
-Change 23.2.6.4 [vector.modifiers]:
+The corresponding wording for unordered containers is not so clear,
+but I read it to disallow
+function pointers for the hasher and I miss a clear statement for the
+equality predicate, see
+23.2.5 [unord.req]/3+4+5:
</p>
-<blockquote><pre><ins>void push_back(const T& x);</ins>
-<ins>void push_back(T&& x);</ins>
-template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
-</pre></blockquote>
-
+<blockquote>
+<p>
+Each unordered associative container is parameterized by <tt>Key</tt>, by a
+function object <tt>Hash</tt> that
+acts as a hash function for values of type <tt>Key</tt>, and by a binary
+predicate <tt>Pred</tt> that induces an
+equivalence relation on values of type <tt>Key</tt>.[..]
+</p>
+<p>
+A hash function is a function object that takes a single argument of
+type <tt>Key</tt> and returns a
+value of type <tt>std::size_t</tt>.
+</p>
+<p>
+Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the
+container's equality function object
+returns <tt>true</tt> when passed those values.[..]
+</p>
+</blockquote>
+<p>
+and table 97 says in the column "assertion...post-condition" for the
+expression X::hasher:
+</p>
+<blockquote>
+<tt>Hash</tt> shall be a unary function object type such that the expression
+<tt>hf(k)</tt> has type <tt>std::size_t</tt>.
+</blockquote>
-<p><b>Rationale:</b></p>
<p>
-Addressed by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
+Note that 20.7 [function.objects]/1 defines as "Function objects are
+objects with an <tt>operator()</tt> defined.[..]"
</p>
-
<p>
-If there is still an issue with pair, Howard should submit another issue.
+Does this restriction exist by design or is it an oversight? If an
+oversight, I suggest that to apply
+the following
</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 23.2.5 [unord.req]/3, just after the second sentence which is written as
+</p>
+<blockquote>
+Additionally, <tt>unordered_map</tt> and <tt>unordered_multimap</tt> associate an
+arbitrary mapped type <tt>T</tt> with the <tt>Key</tt>.
+</blockquote>
+<p>
+add one further sentence:
+</p>
-<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>
+<blockquote>
+Both <tt>Hash</tt> and <tt>Pred</tt> may be pointers to function or objects of a type
+with an appropriate function call operator.
+</blockquote>
-<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>
+<p>
+[Note1: Since the detailed requirements for <tt>Pred</tt> and <tt>Hash</tt> are given in
+p.4 and p.5, it an alternative resolution
+would be to insert a new paragraph just after p.5, which contains the
+above proposed sentence]
+</p>
+<p>
+[Note2: I do not propose a change of above quoted element in table 97,
+because the mis-usage of the
+notion of "function object" seems already present in the standard at
+several places, even if it includes
+function pointers, see e.g. 25 [algorithms]/7. The important point is
+that in those places a statement is
+given that the actually used symbol, like "Predicate" applies for
+function pointers as well]
+</p>
-<li>
-26.4.8.1.2 [rand.dist.uni.real] <tt>uniform_real</tt>. Same issue as #2.
-</li>
-</ol>
+<p><b>Rationale:</b></p>
<p><i>[
-Bellevue:
+San Francisco:
]</i></p>
<blockquote>
-NAD. Withdrawn.
+This is fixed by
+<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
</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>
+<h3><a name="871"></a>871. Iota's requirements on T are too strong</h3>
+<p><b>Section:</b>
26.7.5 [numeric.iota] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-20 <b>Last modified:</b> 2008-09-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>
-<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.
+According to the recent WP
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>,
+26.7.5 [numeric.iota]/1, the requires clause
+of <tt>std::iota</tt> says:
</p>
-<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>
+<blockquote>
+<tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and
+shall be convertible to <tt>ForwardIterator</tt>'s value type.[..]
+</blockquote>
<p>
-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.
+Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt>
+seems to be the correct choice. I guess the current wording resulted as an
+artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>.
</p>
<p>
-An alternative name for release may be <tt>disown</tt>.
+Note: If this function will be conceptualized, the here proposed
+<tt>MoveConstructible</tt>
+requirement can be removed, because this is an implied requirement of
+function arguments, see
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet.
</p>
+
+
+<p><b>Proposed resolution:</b></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>).
+Change the first sentence of 26.7.5 [numeric.iota]/1:
</p>
+<blockquote>
+<i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of
+<tt>CopyConstructible</tt> and <tt>Assignable</tt> types,</del>
+<ins>
+be <tt>MoveConstructible</tt> (Table 34)
+</ins>
+and shall be
+convertible to <tt>ForwardIterator</tt>'s value type. [..]
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
<p><i>[
-Bellevue:
+post San Francisco:
]</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
+Issue pulled by author prior to review.
</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 30.3.3.2 [thread.lock.unique]:
-</p>
-<blockquote><pre>template <class Mutex>
-class unique_lock
-{
-public:
- ...
- mutex_type* <del>release</del> <ins>disown</ins>();
- ...
-};
-</pre></blockquote>
+
+
+<hr>
+<h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3>
+<p><b>Section:</b> 24.5.3.2.12 [move.iter.op.index] <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>Opened:</b> 2008-08-21 <b>Last modified:</b> 2008-09-22</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>
-Change 30.3.3.2.3 [thread.lock.unique.mod]:
+<tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as:
</p>
-<blockquote><pre>mutex_type *<del>release</del> <ins>disown</ins>();
+<blockquote><pre>reference operator[](difference_type n) const;
</pre></blockquote>
+<p>
+This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to
+have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the
+implicit conversion to <tt>value_type&&</tt> could end up referencing a temporary
+that has already been destroyed. This is essentially the same issue that
+we dealt with for <tt>reverse_iterator</tt> in DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>.
+</p>
-
-
-<hr>
-<h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3>
-<p><b>Section:</b> X [datetime.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Date:</b> 2008-02-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Proposed resolution:</b></p>
<p>
-The draft C++0x thread library requires that the time points of type
-<tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated
-Universal Time (UTC) (section X [datetime.system]). This can lead to
-surprising behavior when a library user performs a duration-based wait,
-such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the
-problem may be found in the
-<a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a>
-section in POSIX, but in summary:
+In 24.5.3.1 [move.iterator] and 24.5.3.2.12 [move.iter.op.index], change the declaration of
+<tt>move_iterator</tt>'s <tt>operator[]</tt> to:
</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>
+<blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const;
+</pre></blockquote>
-<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><b>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></p>
-<p>
-POSIX solves the problem by introducing a new monotonic clock, which is
-unaffected by changes to the system time. When a condition variable is
-initialized, the user may specify whether the monotonic clock is to be
-used. (It is worth noting that on POSIX systems it is not possible to
-use <tt>condition_variable::native_handle()</tt> to access this facility, since
-the desired clock type must be specified during construction of the
-condition variable object.)
-</p>
-<p>
-In the context of the C++0x thread library, there are added dimensions
-to the problem due to the need to support platforms other than POSIX:
-</p>
+<blockquote>
+NAD Editorial, see
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2777.pdf">N2777</a>.
+</blockquote>
-<ul>
-<li>
-Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
-</li>
-<li>
-Some environments do not have a monotonic clock, but do have a UTC clock.
-</li>
-<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>
+<hr>
+<h3><a name="874"></a>874. Missing <tt>initializer_list</tt> constructor for <tt>discrete_distribution</tt></h3>
+<p><b>Section:</b> 26.5.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%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-One possible minimal solution:
+During the Sophia Antipolis meeting it was decided to separate from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a> a
+subrequest that adds initializer list support to
+<tt>discrete_distribution</tt>, specifically,
+the issue proposed to add a c'tor taking a <tt>initializer_list<double></tt>.
</p>
-<ul>
-<li>
-Strike normative references to UTC and an epoch based on 1970-01-01.
-</li>
-
-<li>
-Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt>
-implementation-defined (i.e standard library implementors may choose the
-appropriate underlying clock based on the capabilities of the target
-platform).
-</li>
-<li>
-Add a non-normative note encouraging use of a monotonic clock.
-</li>
+<p><b>Proposed resolution:</b></p>
+<ol>
<li>
-Remove <tt>system_time::seconds_since_epoch()</tt>.
-</li>
+<p>
+In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>,
+just <em>before</em> the member declaration
+</p>
-<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>
+<blockquote><pre>explicit discrete_distribution(const param_type& parm);
+</pre></blockquote>
+<p>
+insert
+</p>
+<blockquote><pre>discrete_distribution(initializer_list<double> wl);
+</pre></blockquote>
+</li>
-<p><b>Proposed resolution:</b></p>
+<li>
<p>
+Between p.4 and p.5 of the same section insert a new
+paragraph as part of the new member description:
</p>
+<blockquote><pre>discrete_distribution(initializer_list<double> wl);
+</pre>
+
+<blockquote>
+<i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>.
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
<p><b>Rationale:</b></p>
Addressed by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661: A Foundation to Sleep On</a>.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
<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>
+<h3><a name="875"></a>875. Missing <tt>initializer_list</tt> constructor for <tt>piecewise_constant_distribution</tt></h3>
+<p><b>Section:</b> 26.5.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%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-<tt>xor_combine::seed(result_type)</tt> and <tt>seed(seed_seq&)</tt> don't say what
-happens to each of the sub-engine seeds. (Should probably do the same
-to both, unlike TR1.)
+During the Sophia Antipolis meeting it was decided to separate from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a> a subrequest that adds initializer list support to
+<tt>piecewise_constant_distribution</tt>, specifically, the issue proposed
+to add a c'tor taking a <tt>initializer_list<double></tt> and a <tt>Callable</tt> to evaluate
+weight values. For consistency with the remainder of this class and
+the remainder of the <tt>initializer_list</tt>-aware library the author decided to
+change the list argument type to the template parameter <tt>RealType</tt>
+instead. For the reasoning to use <tt>Func</tt> instead of <tt>Func&&</tt> as c'tor
+function argument see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>.
</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-defects.html#789">789</a>.
-</blockquote>
-
-
<p><b>Proposed resolution:</b></p>
+<p><b>Non-concept version of the proposed resolution</b></p>
+<ol>
+<li>
+<p>
+In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
+just <em>before</em> the member declaration
+</p>
+<blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm);
+</pre></blockquote>
+<p>
+insert
+</p>
+<blockquote><pre>template<typename Func>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
+</pre></blockquote>
+</li>
-<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>
+<li>
<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.)
+Between p.4 and p.5 of the same section insert a series of
+new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
+as part of the new member description:
</p>
-<p><i>[
-Bellevue:
-]</i></p>
-
+<blockquote><pre>template<typename Func>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
+</pre>
<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.
+[p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
</p>
<p>
-We don't think this should be changed.
+[p5_2] <i>Requires:</i>
</p>
+<ol type="a">
+<li>
+<tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
+ return values of a type convertible to <tt>double</tt>;
+</li>
+<li>
+The relation <tt>0 < S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold.
+For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight
+ value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
+</li>
+<li>
+If <tt>nf > 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
+following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> < b<sub><i>k+1</i></sub></tt>.
+</li>
+</ol>
+
<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.
+[p5_3] <i>Effects:</i>
</p>
-</blockquote>
+<ol type="a">
+<li>
+<p>If <tt>nf == 0</tt>,</p>
+<ol type="a">
+<li>
+lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
+ value <tt>w<sub>0</sub> = 1</tt>, and
+</li>
+<li>
+lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>.
+</li>
+</ol>
+</li>
+
+<li>
+<p>Otherwise,</p>
+<ol type="a">
+<li>
+sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
+length <tt>n+1</tt>, and
+</li>
+<li>
+<p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
+ calculates:</p>
+<blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
+w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
+</pre></blockquote>
+</li>
+</ol>
+</li>
+
+<li>
+<p>
+Constructs a <tt>piecewise_constant_distribution</tt> object with
+the above computed sequence <tt>b</tt> as the interval boundaries
+and with the probability densities:
+</p>
+<blockquote><pre>ρ<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
+</pre></blockquote>
+
+</li>
+</ol>
+</blockquote>
+</blockquote>
+</li>
+</ol>
-<p><b>Proposed resolution:</b></p>
+<p><b>Concept version of the proposed resolution</b></p>
+<ol>
+<li>
<p>
-Change synopsis in 26.4.8.5.2 [rand.dist.samp.pconst]:
+In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
+just <em>before</em> the member declaration
</p>
-<blockquote><pre>template <class RealType = double>
-class piecewise_constant_distribution
-{
-public:
- ...
- vector<double> <del>densities</del> <ins>probabilities</ins>() const;
- ...
-};
+<blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm);
</pre></blockquote>
<p>
-Change 26.4.8.5.2 [rand.dist.samp.pconst]/6:
+insert
</p>
-<blockquote><pre>vector<double> <del>densities</del> <ins>probabilities</ins>() const;
+<blockquote><pre>template<Callable<auto, RealType> Func>
+ requires Convertible<Func::result_type, double>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
</pre></blockquote>
+</li>
+
+<li>
+<p>
+Between p.4 and p.5 of the same section insert a series of
+new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
+as part of the new member description:
+</p>
+<blockquote><pre>template<Callable<auto, RealType> Func>
+ requires Convertible<Func::result_type, double>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
+</pre>
+<blockquote>
+<p>
+[p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
+</p>
+<p>
+[p5_2] <i>Requires:</i>
+</p>
+<ol type="a">
+<li>
+The relation <tt>0 < S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold.
+For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight
+ value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
+</li>
+<li>
+If <tt>nf > 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
+following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> < b<sub><i>k+1</i></sub></tt>.
+</li>
+</ol>
-<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.)
+[p5_3] <i>Effects:</i>
</p>
-<p><i>[
-Stephan Tolksdorf notes:
-]</i></p>
+<ol type="a">
+<li>
+<p>If <tt>nf == 0</tt>,</p>
+<ol type="a">
+<li>
+lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
+ value <tt>w<sub>0</sub> = 1</tt>, and
+</li>
+<li>
+lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>.
+</li>
+</ol>
+</li>
+
+<li>
+<p>Otherwise,</p>
+<ol type="a">
+<li>
+sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
+length <tt>n+1</tt>, and
+</li>
+<li>
+<p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
+ calculates:</p>
+<blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
+w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
+</pre></blockquote>
+</li>
+</ol>
+</li>
+
+<li>
+<p>
+Constructs a <tt>piecewise_constant_distribution</tt> object with
+the above computed sequence <tt>b</tt> as the interval boundaries
+and with the probability densities:
+</p>
+<blockquote><pre>ρ<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
+</pre></blockquote>
+</li>
+</ol>
-<blockquote>
-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>
+</blockquote>
+</li>
+</ol>
-<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+Addressed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
<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>
+<h3><a name="892"></a>892. Forward_list issues...</h3>
+<p><b>Section:</b> 23.3.3.5 [forwardlist.ops] <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> Ed Smith-Rowland <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</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.)
+I was looking at the latest draft on <tt>forward_list</tt>. Especially the splice methods.
+</p>
+<p>
+The first one splices a whole list after a given iterator in <tt>this</tt>. The name is <tt>splice_after</tt>.
+I think in 23.3.3.5 [forwardlist.ops] paragraph 40
+change:
+</p>
+<blockquote>
+<i>Effect:</i> Insert the contents of <tt>x</tt> <del>before</del> <ins>after</ins> <tt>position</tt>, ...
+</blockquote>
+
+<p>
+A deeper issue involves the complexity. <tt>forward_list</tt> has no <tt>size</tt> and we
+don't know when we've reached the end except to walk up to it. To
+splice we would need to hook the end of the source list to the item
+after <tt>position</tt> in this list. This would involve walking length of the
+source list until we got to the last dereference-able element in source.
+There's no way we could do this in O(1) unless we stored a bogus end in
+<tt>forward_list</tt>.
+</p>
+<p>
+OTOH, the last version of <tt>splice_after</tt> with iterator ranges we could do
+in O(1) because we know how to hook the end of the source range to ...
+</p>
+<p>
+Unless I'm misconceiving the whole thing. Which is possible. I'll look at it again.
+</p>
+<p>
+I'm pretty sure about the first part though.
</p>
<p><i>[
-Bellevue:
+San Francisco:
]</i></p>
<blockquote>
-Submitter withdraws defect.
+<p>
+This issue is more complicated than it looks.
+</p>
+<p>
+paragraph 47: replace each <tt>(first, last) with (first, last]</tt>
+</p>
+<p>
+add a statement after paragraph 48 that complexity is O(1)
+</p>
+<p>
+remove the complexity statement from the first overload of splice_after
+</p>
+<p>
+We may have the same problems with other modifiers, like erase_after.
+Should it require that all iterators in the range (position, last] be
+dereferenceable?
+</p>
+<p>
+We do, however, like the proposed changes and consider them Editorial.
+Move to NAD Editorial, Pending. Howard to open a new issue to handle the
+problems with the complexity requirements.
+</p>
+<p>
+Opened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>.
+</p>
</blockquote>
-
<p><b>Proposed resolution:</b></p>
<p>
-Change 26.4.5 [rand.predef]/p5:
+In 23.3.3.5 [forwardlist.ops] paragraph 40
+change:
</p>
-
-<blockquote>
-<pre>typedef subtract_with_carry_engine<uint_fast64_t, 48, 5, 12>
- 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>
+<i>Effect:</i> Insert the contents of <tt>x</tt> <del>before</del> <ins>after</ins> <tt>position</tt>, ...
</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>
+<h3><a name="905"></a>905. Mutex specification questions</h3>
+<p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-09-18 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.class">active issues</a> in [thread.mutex.class].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a></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>.)
+A few questions on the current WP,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>:
+</p>
+<p>
+30.4.1 [thread.mutex.requirements]/24 says an expression
+<tt>mut.unlock()</tt> "Throws: Nothing." I'm assuming that, per 17.6.3.11 [res.on.required], errors that violate the precondition "The
+calling thread shall own the mutex" opens the door for throwing an
+exception anyway, such as to report unbalanced unlock operations and
+unlocking from a thread that does not have ownership. Right?
+</p>
+<p>
+30.4.1.1 [thread.mutex.class]/3 (actually numbered paragraph "27"
+in the WP; this is just a typo I think) says
+</p>
+<blockquote>
+<p>
+The behavior of a program is undefined if:
+</p>
+<ul>
+<li>it destroys a <tt>mutex</tt> object owned by any thread,</li>
+<li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</li>
+<li>a thread terminates while owning a <tt>mutex</tt> object.</li>
+</ul>
+</blockquote>
+
+<p>
+As already discussed, I think the second bullet should be removed, and
+such a <tt>lock()</tt> or <tt>try_lock()</tt> should fail with an
+exception or returning <tt>false</tt>, respectively.
+</p>
+<p>
+A potential addition to the list would be
+</p>
+<ul>
+<li>a thread unlocks a <tt>mutex</tt> it does not have ownership of.</li>
+</ul>
+<p>
+but without that the status quo text endorses the technique of the
+program logically transferring ownership of a mutex to another thread
+with correctness enforced by programming discipline. Was that intended?
</p>
+
<p><i>[
-Bellevue:
+Summit:
]</i></p>
<blockquote>
-Submitter withdraws defect.
+<p>
+Two resolutions: "not a defect" and "duplicate", as follows:
+</p>
+<ul>
+<li>
+30.4.1 [thread.mutex.requirements]/24: NAD. If the precondition
+fails the program has undefined behaviour and therefore an
+implementation may throw an exception already.
+</li>
+<li>
+30.4.1.1 [thread.mutex.class]/3 bullet 2: Already addressed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>.
+</li>
+<li>
+30.4.1.1 [thread.mutex.class]/3 proposed addition: NAD. This is
+already covered by the mutex requirements, which have ownership as a
+Precondition.
+</li>
+</ul>
</blockquote>
-
<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.4.5 [rand.predef]/p6:
-</p>
-<blockquote>
-<pre>typedef discard_block_engine<ranlux48_base, 389, 11>
- 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>
+<h3><a name="937"></a>937. Atomics for standard typedef types</h3>
+<p><b>Section:</b> 29 [atomics] <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> Clark Nelson <b>Opened:</b> 2008-12-05 <b>Last modified:</b> 2009-05-23</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
+
+<p><b>Addresses US 89</b></p>
+
+<blockquote>
<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.
+The types in the table "Atomics for standard typedef types" should be
+typedefs, not classes. These semantics are necessary for compatibility
+with C.
</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.
+Change the classes to typedefs.
+</p>
+</blockquote>
+
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>
+specified different requirements for atomic analogs of fundamental
+integer types (such as <tt>atomic_int</tt>) and for atomic analogs of <tt><cstdint></tt>
+typedefs (such as <tt>atomic_size_t</tt>). Specifically, <tt>atomic_int</tt> et al. were
+specified to be distinct classes, whereas <tt>atomic_size_t</tt> et al. were
+specified to be typedefs. Unfortunately, in applying
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>
+to the WD, that distinction was erased, and the atomic analog of every <tt><cstdint></tt>
+typedef is required to be a distinct class.
</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.
+It shouldn't be required that the atomic analog of every <tt><cstdint></tt>
+typedef be a typedef for some fundamental integer type. After all,
+<tt><cstdint></tt> is supposed to provide standard names for extended integer
+types. So there was a problem in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>,
+which certainly could have been
+interpreted to require that. But the status quo in the WD is even worse,
+because it's unambiguously wrong.
</p>
<p>
-These changes would likely have no practical effect, but would allow an
-implementation that does the right thing to be standard-conformant.
+What is needed are words to require the existence of a bunch of type
+names, without specifying whether they are class names or typedef names.
</p>
<p><i>[
-Bellevue:
+Summit:
]</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!
+Change status to NAD, editorial. See US 89 comment notes above.
</p>
<p>
-Revisted: Agree that the fact that there is no practical difference means that no change can be justified.
+Direct the editor to turn the types into typedefs as proposed in the
+comment. Paper approved by committee used typedefs, this appears to have
+been introduced as an editorial change. Rationale: for compatibility
+with C.
</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>
+
+
+
+<hr>
+<h3><a name="942"></a>942. Atomics synopsis typo</h3>
+<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
+ <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a></p>
+<p><b>Discussion:</b></p>
+
+
<p>
-In para 5. change:
+I'm looking at 29 [atomics] and can't really make sense of a couple of things.
+</p>
+<p>
+Firstly, there appears to be a typo in the <tt><cstdatomic></tt> synopsis:
</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>
-
+<p>
+The <tt>atomic_exchange</tt> overload taking an <tt>atomic_address</tt>
+is missing the second parameter:
+</p>
+<blockquote><pre>void* atomic_exchange(volatile atomic_address*);
+</pre></blockquote>
+<p>
+should be
+</p>
+<blockquote><pre>void* atomic_exchange(volatile atomic_address*<ins>, void*</ins>);
+</pre></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.
+Note, that this is <em>not</em> covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a> "Missing atomic exchange parameter",
+which only talks about the <tt>atomic_bool</tt>.
</p>
+</blockquote>
+
<p><b>Proposed resolution:</b></p>
<p>
-Change 26.4.5 [rand.predef]/p8:
+Change the synopsis in 29 [atomics]/2:
</p>
-<blockquote>
-<pre>typedef shuffle_order_engine<minstd_rand0, 256>
- 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>
-
+<blockquote><pre>void* atomic_exchange(volatile atomic_address*<ins>, void*</ins>);
+</pre></blockquote>
-<p><i>[
-Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD.
-]</i></p>
<hr>
-<h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3>
-<p><b>Section:</b> 22.2.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-07</p>
+<h3><a name="980"></a>980. <tt>mutex lock()</tt> missing error conditions</h3>
+<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Ion Gaztañaga <b>Opened:</b> 2009-02-07 <b>Last modified:</b> 2009-03-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In the spirit of <tt>printf vs iostream</tt>...
+POSIX 2008 adds two return values for <tt>pthread_mutex_xxxlock()</tt>:
+<tt>EOWNERDEAD</tt> (<tt>owner_dead</tt>) and <tt>ENOTRECOVERABLE</tt>
+(<tt>state_not_recoverable</tt>). In the first case the mutex is locked,
+in the second case the mutex is not locked.
</p>
<p>
-POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the
-implication is that in the absence of <tt>'</tt> no grouping characters are
-inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert
-grouping characters. Can this be considered a defect worth fixing for
-C++0x? Maybe <tt>ios_base</tt> needs an additional flag?
+Throwing an exception in the first case can be incompatible with the use
+of Locks, since the <tt>Lock::owns_lock()</tt> will be <tt>false</tt> when the lock is
+being destroyed.
</p>
-<p><i>[
-Pablo Halpern:
-]</i></p>
-
-
-<blockquote>
-I'm not sure it constitutes a defect, but I would be in favor of adding
-another flag (and corresponding manipulator).
-</blockquote>
+<p>
+Consider:
+</p>
-<p><i>[
-Martin Sebor:
-]</i></p>
+<blockquote><pre>//Suppose mutex.lock() throws "owner_dead"
+unique_lock ul(&mutex);
+//mutex left locked if "owner_dead" is thrown
+</pre></blockquote>
+<p>
+Throwing an exception with <tt>owner_dead</tt> might be also undesirable if
+robust-mutex support is added to C++ and the user has the equivalent of
+<tt>pthread_mutex_consistent()</tt> to notify the user has fixed the corrupted
+data and the mutex state should be marked consistent.
+</p>
-<blockquote>
-I don't know if it qualifies as a defect but I agree that there
-should be an easy way to control whether the thousands separator
-should or shouldn't be inserted. A new flag would be in line with
-the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or
-<tt>showbase</tt>).
-</blockquote>
+<ol>
+<li>
+For <tt>state_not_recoverable</tt> add it to the list of Error conditions:
+</li>
+<li>
+For <tt>owner_dead</tt>, no proposed resolution.
+</li>
+</ol>
<p><i>[
-Sophia Antipolis:
+Summit:
]</i></p>
<blockquote>
-This is not a part of C99. LWG suggests submitting a paper may be appropriate.
+Not a defect. Handling these error conditions is an implementation
+detail and must be handled below the C++ interface.
</blockquote>
<p><b>Proposed resolution:</b></p>
+
+<p>
+Add to 30.4.1 [thread.mutex.requirements], p12:
+</p>
+
+<blockquote>
<p>
+-12- <i>Error conditions:</i>
</p>
+<ul>
+<li>
+<tt>operation_not_permitted</tt> -- if the thread does not have the necessary permission to change
+the state of the mutex.
+</li>
+<li>
+<tt>resource_deadlock_would_occur</tt> -- if the current thread already owns the mutex and is able
+to detect it.
+</li>
+<li>
+<tt>device_or_resource_busy</tt> -- if the mutex is already locked and blocking is not possible.
+</li>
+<li>
+<ins><tt>state_not_recoverable</tt> -- if the state protected by the mutex is not recoverable.</ins>
+</li>
+</ul>
+</blockquote>
+
<hr>
-<h3><a name="831"></a>831. wrong type for not_eof()</h3>
-<p><b>Section:</b> 2
1.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
+<h3><a name="1022"></a>1022. Response to UK 212</h3>
+<p><b>Section:</b> 2
0.8.13.7 [util.dynamic.safety] <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> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
-<p>
- In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function
- is using an argument of type <i>e</i> which denotes an object of
- type <code>X::int_type</code>. However, the specializations in
- 21.1.3 [char.traits.specializations] all use <code>char_type</code>.
- This would effectively mean that the argument type actually can't
- represent EOF in the first place. I'm pretty sure that the type used
- to be <code>int_type</code> which is quite obviously the only sensible
- argument.
-</p>
-<p>
- This issue is close to being editorial. I suspect that the proposal
- changing this section to include the specializations for <code>char16_t</code>
- and <code>char32_t</code> accidentally used the wrong type.
-</p>
+<p><b>Addresses UK 212</b></p>
-<p><b>Proposed resolution:</b></p>
<p>
- In 21.1.3.1 [char.traits.specializations.char],
- 21.1.3.2 [char.traits.specializations.char16_t],
- 21.1.3.3 [char.traits.specializations.char32_t], and
- [char.traits.specializations.wchar_t] correct the
- argument type from <code>char_type</code> to <code>int_type</code>.
+The pointer-safety API is nothing to do with smart pointers, so does not
+belong in 20.8.13 [util.smartptr]. In fact it is a set of language
+support features are really belongs in clause 18 [language.support], with the contents declared in a header that
+deals with language-support of memory management.
</p>
+<p><i>[
+Summit:
+]</i></p>
+
-<p><b>Rationale:</b></p>
-Already fixed in WP.
+<blockquote>Agree in principle, but not with the proposed resolution.
+We believe it
+belongs either a subsection of either 20 [utilities] or 20.8 [memory]
+as part of the general reorganization of 20 [utilities]. The
+declaration should stay in
+<tt><memory></tt>.
+</blockquote>
+<p><b>Proposed resolution:</b></p>
-<hr>
-<h3><a name="840"></a>840. <tt>pair</tt> default template argument</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-05-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I have one issue with <tt>std::pair</tt>. Well, it might just be a very annoying
-historical accident, but why is there no default template argument for
-the second template argument? This is so annoying when the type in
-question is looong and hard to write (type deduction with <tt>auto</tt> won't
-help those cases where we use it as a return or argument type).
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 20.2 [utility] to read:
-</p>
-<blockquote><pre>template <class T1, class T2 <ins>= T1</ins>> struct pair;
-</pre></blockquote>
+<hr>
+<h3><a name="1025"></a>1025. Response to UK 208</h3>
+<p><b>Section:</b> 20.7.17 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
+<p><b>Discussion:</b></p>
+
+<p><b>Addresses UK 208</b></p>
<p>
-Change 20.2.3 [pairs] to read:
+<tt>std::hash</tt> should be implemented for much more of the standard
+library. In particular for <tt>pair</tt>, <tt>tuple</tt> and all the
+standard containers.
</p>
-<blockquote><pre>namespace std {
- template <class T1, class T2 <ins>= T1</ins>>
- struct pair {
- typedef T1 first_type;
- typedef T2 second_type;
- ...
-</pre></blockquote>
-<p><b>Rationale:</b></p>
-<tt>std::pair</tt> is a heterogeneous container.
+<p><b>Proposed resolution:</b></p>
<table>
<tbody><tr>
<td align="left">Doc. no.</td>
-<td align="left">N2728=08-0238</td>
+<td align="left">N2895=09-0085</td>
</tr>
<tr>
<td align="left">Date:</td>
-<td align="left">2008-08-24</td>
+<td align="left">2009-06-21</td>
</tr>
<tr>
<td align="left">Project:</td>
<td align="left">Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>></td>
</tr>
</tbody></table>
-<h1>C++ Standard Library Defect Report List (Revision R59)</h1>
+<h1>C++ Standard Library Defect Report List (Revision R65)</h1>
- <p>Reference ISO/IEC IS 14882:1998(E)</p>
+ <p>Reference ISO/IEC IS 14882:2003(E)</p>
<p>Also see:</p>
<ul>
<li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
<h2>Revision History</h2>
<ul>
+<li>R65:
+2009-06-19 pre-Frankfurt mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>378 open issues, up by 32.</li>
+<li>765 closed issues, up by 0.</li>
+<li>1143 issues total, up by 32.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1143">1143</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1112">1112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>.</li>
+<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</a>.</li>
+<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>.</li>
+<li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#568">568</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#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</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>.</li>
+<li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>.</li>
+<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#988">988</a>.</li>
+<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#884">884</a>.</li>
+<li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>.</li>
+<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.</li>
+<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>.</li>
+<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>.</li>
+<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R64:
+2009-05-01 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>346 open issues, up by 19.</li>
+<li>765 closed issues, up by 0.</li>
+<li>1111 issues total, up by 19.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</a>.</li>
+<li>Changed the following issues from DR to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#406">406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#434">434</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438">438</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#444">444</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#455">455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#469">469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>.</li>
+<li>Changed the following issues from Review to New: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R63:
+2009-03-20 post-Summit mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>327 open issues, up by 96.</li>
+<li>765 closed issues, up by 14.</li>
+<li>1092 issues total, up by 110.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1022">1022</a>.</li>
+<li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1089">1089</a>.</li>
+<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li>
+<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#988">988</a>.</li>
+<li>Changed the following issues from New to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>.</li>
+<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>.</li>
+<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>.</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#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</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#683">683</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
+<li>Changed the following issues from Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
+<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#466">466</a>.</li>
+<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#219">219</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>.</li>
+<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>.</li>
+<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>.</li>
+<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>.</li>
+<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>.</li>
+<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>.</li>
+<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</a>.</li>
+<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R62:
+2009-02-06 pre-Summit mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>231 open issues, up by 44.</li>
+<li>751 closed issues, up by 0.</li>
+<li>982 issues total, up by 44.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R61:
+2008-12-05 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>187 open issues, up by 20.</li>
+<li>751 closed issues, up by 0.</li>
+<li>938 issues total, up by 20.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R60:
+2008-10-03 post-San Francisco mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>167 open issues, down by 25.</li>
+<li>751 closed issues, up by 65.</li>
+<li>918 issues total, up by 40.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#896">896</a>.</li>
+<li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
+<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
+<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</a>.</li>
+<li>Changed the following issues from New to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>.</li>
+<li>Changed the following issues from Ready to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
+<li>Changed the following issues from Review to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>.</li>
+<li>Changed the following issues from WP to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#44">44</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#167">167</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#231">231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#239">239</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#240">240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#282">282</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#291">291</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#300">300</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#305">305</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#310">310</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#315">315</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#316">316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#318">318</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#319">319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#320">320</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#321">321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#324">324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#325">325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#328">328</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#331">331</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#333">333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#337">337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#338">338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#340">340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#341">341</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#345">345</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#346">346</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#349">349</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#352">352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#354">354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#355">355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#358">358</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#359">359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#360">360</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#363">363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#364">364</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#365">365</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#370">370</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#373">373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#375">375</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#379">379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#380">380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#381">381</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#391">391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#395">395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#400">400</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#403">403</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#405">405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#410">410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#411">411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#414">414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#415">415</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#420">420</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#425">425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#426">426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#428">428</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#435">435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#436">436</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#442">442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#443">443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#448">448</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#449">449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
+<li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>.</li>
+<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</a>.</li>
+<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
+<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#872">872</a>.</li>
+<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#742">742</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</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#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
+<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>.</li>
+<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
+<li>Changed the following issues from TC to TC1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1">1</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#7">7</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#11">11</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#13">13</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#14">14</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#15">15</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#16">16</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#18">18</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#20">20</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#21">21</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#27">27</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#30">30</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#32">32</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#34">34</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#35">35</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#36">36</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#37">37</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#39">39</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#40">40</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#42">42</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#46">46</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#47">47</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#48">48</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50">50</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#51">51</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#52">52</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#53">53</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#54">54</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#56">56</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#57">57</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#59">59</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#62">62</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#66">66</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#68">68</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#71">71</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#74">74</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#78">78</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#79">79</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#80">80</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#90">90</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#106">106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#124">124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#125">125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#141">141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#148">148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#150">150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#151">151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#152">152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#154">154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#155">155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#156">156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#158">158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#161">161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#168">168</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#169">169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#174">174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#175">175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#176">176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.</li>
+</ul></li>
+</ul>
+</li>
<li>R59:
2008-08-22 pre-San Francisco mailing.
<ul>
<li>878 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
</ul></li>
</ul>
</li>
<li>869 issues total, up by 8.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
-<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li>
+<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>.</li>
+<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>.</li>
</ul></li>
</ul>
</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li>
+<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li>
-<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
-<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>.</li>
+<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
+<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
+<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>.</li>
+<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
</ul></li>
</ul>
</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-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li>
+<li>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-
defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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><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 New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li>
<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 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-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
-<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
-<li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
+<li>Changed the following issues from 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-
defects.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-
defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
+<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-
defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
+<li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
<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-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>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-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li>
<li>Changed the following issues from 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>
<li>754 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.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-defects.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-closed.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-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
+<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
<li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
+<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
<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-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
</ul></li>
</ul>
</li>
<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-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>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-
defects.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-closed.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-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 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-
closed.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-active.html#644">644</a>.</li>
<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
<li>696 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
<li>Added the following 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>
<li>676 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
+<li>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-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>.</li>
<li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li>
-<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.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-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 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-
active.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-active.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
<li>656 issues total, up by 37.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
+<li>Changed the following issues from 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-
active.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>
<li>619 issues total, up by 10.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
</ul></li>
</ul>
</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#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-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#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-
closed.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>
+<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-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</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#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li>
</ul></li>
</ul>
</li>
<li>592 issues total, up by 5.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
</ul></li>
</ul>
</li>
<li>587 issues total, up by 13.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li>
<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.</li>
</ul></li>
<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-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-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>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-active.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-
defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
<li>566 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a> ,<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
<li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
</ul></li>
<li>535 issues total.</li>
</ul></li>
<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
+<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>
, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
</ul></li>
</ul>
</li>
</li>
<li>R38:
2005-07-03 pre-Mont Tremblant mailing.
-Merged open TR1 issues in <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-active.html#522">522</a>.
+Merged open TR1 issues in <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-defects.html#522">522</a>.
Added new issues <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-active.html#523">523</a>
</li>
<li>R37:
</li>
<li>R36:
2005-04 post-Lillehammer mailing. All issues in "ready" status except
-for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues
+for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> were moved to "DR" status, and all issues
previously in "DR" status were moved to "WP".
</li>
<li>R35:
<li>R24:
Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
meeting. All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
-moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
+moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
defects.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
at the meeting.) Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
</li>
to Ready.
Closed issues
-<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#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
as NAD.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>. Reopened
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>. Reopened
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.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-active.html#128">128</a>,
</li>
<li>R4:
post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
issues corrected. (22 Oct 98)
</li>
<li>R3:
<h2>Defect Reports</h2>
<hr>
<h3><a name="1"></a>1. C library linkage editing oversight</h3>
-<p><b>Section:</b> 17.4.2.2 [using.linkage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</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>Section:</b> 17.6.2.3 [using.linkage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1997-11-16 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The change specified in the proposed resolution below did not make
it into the Standard. This change was accepted in principle at the
<p><b>Proposed resolution:</b></p>
-<p>Change 17.4.2.2 [using.linkage] paragraph 2
+<p>Change 17.6.2.3 [using.linkage] paragraph 2
from:</p>
<blockquote>
<hr>
<h3><a name="3"></a>3. Atexit registration during atexit() call is not described</h3>
-<p><b>Section:</b> 18.4 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1997-12-12</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>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1997-12-12 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>We appear not to have covered all the possibilities of
exit processing with respect to
<hr>
<h3><a name="5"></a>5. String::compare specification questionable</h3>
-<p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Jack Reeves <b>Date:</b> 1997-12-11</p>
+<p><b>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Jack Reeves <b>Opened:</b> 1997-12-11 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#87">87</a></p>
<p><b>Discussion:</b></p>
<p>At the very end of the basic_string class definition is the signature: int
<p><b>Proposed resolution:</b></p>
-<p>Replace the compare signature in 21.3 [basic.string]
+<p>Replace the compare signature in 21.4 [basic.string]
(at the very end of the basic_string synopsis) which reads:</p>
<blockquote>
size_type n2) const;</tt></p>
</blockquote>
-<p>Replace the portion of 21.3.6.8 [string::swap]
+<p>Replace the portion of 21.4.6.8 [string::swap]
paragraphs 5 and 6 which read:</p>
<blockquote>
<hr>
<h3><a name="7"></a>7. String clause minor problems</h3>
-<p><b>Section:</b> 21 [strings] <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> 1997-12-15</p>
+<p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-15 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>(1) In 21.3.6.4 [string::insert], the description of template
+<p>(1) In 21.4.6.4 [string::insert], the description of template
<class InputIterator> insert(iterator, InputIterator,
InputIterator) makes no sense. It refers to a member function that
doesn't exist. It also talks about the return value of a void
charT* in the description. Second, given what it says in RETURNS,
leaving out the final argument will always result in an exception
getting thrown. This is paragraphs 5 and 6 of
-21.3.6.8 [string::swap]</p>
+21.4.6.8 [string::swap]</p>
-<p>(6) In table 37, in section 21.1.1 [char.traits.require],
+<p>(6) In table 37, in section 21.2.1 [char.traits.require],
there's a note for X::move(s, p, n). It says "Copies correctly
even where p is in [s, s+n)". This is correct as far as it goes,
but it doesn't go far enough; it should also guarantee that the copy
<hr>
<h3><a name="8"></a>8. Locale::global lacks guarantee</h3>
-<p><b>Section:</b> 22.1.1.5 [locale.statics] <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> 1997-12-24</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>Section:</b> 22.3.1.5 [locale.statics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-24 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>It appears there's an important guarantee missing from clause
22. We're told that invoking locale::global(L) sets the C locale if L
<p><b>Proposed resolution:</b></p>
-<p>Add a sentence at the end of 22.1.1.5 [locale.statics],
+<p>Add a sentence at the end of 22.3.1.5 [locale.statics],
paragraph 2: </p>
<blockquote>
<hr>
<h3><a name="9"></a>9. Operator new(0) calls should not yield the same pointer</h3>
-<p><b>Section:</b> 18.5.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-01-04</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>Section:</b> 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-01-04 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete">issues</a> in [new.delete].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
section 3.7.3.1 of CD2 seems to allow for the possibility that all
<hr>
<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>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-22 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>(1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is
not documented in 23.3.5.2. </p>
<p><b>Proposed resolution:</b></p>
<p>ITEMS 1 AND 2:<br>
<br>
-In the bitset synopsis (23.3.5 [template.bitset]),
+In the bitset synopsis (20.3.6 [template.bitset]),
replace the member function <br>
<br>
<tt> reference operator[](size_t pos);<br>
<tt> bool operator[](size_t pos) const; <br>
reference operator[](size_t pos); <br>
</tt><br>
-Add the following text at the end of 23.3.5.2 [bitset.members],
+Add the following text at the end of 20.3.6.2 [bitset.members],
immediately after paragraph 45:</p>
<blockquote>
<p><b>Rationale:</b></p>
<p>The LWG believes Item 3 is not a defect. "Formatted
-input" implies the desired semantics. See 27.6.1.2 [istream.formatted].
+input" implies the desired semantics. See 27.7.1.2 [istream.formatted].
</p>
<hr>
<h3><a name="13"></a>13. Eos refuses to die</h3>
-<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> William M. Miller <b>Date:</b> 1998-03-03</p>
+<p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> William M. Miller <b>Opened:</b> 1998-03-03 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 27.6.1.2.3, there is a reference to "eos", which is
the only one in the whole draft (at least using Acrobat search), so
<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.2.3 [istream::extractors], replace "eos" with
+<p>In 27.7.1.2.3 [istream::extractors], replace "eos" with
"charT()"</p>
<hr>
<h3><a name="14"></a>14. Locale::combine should be const</h3>
-<p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>locale::combine is the only member function of locale (other than constructors and
destructor) that is not const. There is no reason for it not to be const, and good reasons
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1 [locale] and also in 22.1.1.3 [locale.members], add
+<p>In 22.3.1 [locale] and also in 22.3.1.3 [locale.members], add
"const" to the declaration of member combine: </p>
<blockquote>
<pre>template <class Facet> locale combine(const locale& other) const; </pre>
<hr>
<h3><a name="15"></a>15. Locale::name requirement inconsistent</h3>
-<p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>locale::name() is described as returning a string that can be passed to a locale
constructor, but there is no matching constructor. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1.3 [locale.members], paragraph 5, replace
+<p>In 22.3.1.3 [locale.members], paragraph 5, replace
"<tt>locale(name())</tt>" with
"<tt>locale(name().c_str())</tt>".
</p>
<hr>
<h3><a name="16"></a>16. Bad ctype_byname<char> decl</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The new virtual members ctype_byname<char>::do_widen and do_narrow did not get
edited in properly. Instead, the member do_widen appears four times, with wrong argument
<p><b>Proposed resolution:</b></p>
<p>The correct declarations for the overloaded members
<tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
-from 22.2.1.3 [facet.ctype.special].</p>
+from 22.4.1.3 [facet.ctype.special].</p>
<hr>
<h3><a name="17"></a>17. Bad bool parsing</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#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>This section describes the process of parsing a text boolean value from the input
stream. It does not say it recognizes either of the sequences "true" or
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14,
+<p>In 22.4.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14,
change "&&" to "&".</p>
<p>Then, replace paragraphs 15 and 16 as follows:</p>
<hr>
<h3><a name="18"></a>18. Get(...bool&) omitted</h3>
-<p><b>Section:</b> 22.2.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.4.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.members">issues</a> in [facet.num.get.members].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In the list of num_get<> non-virtual members on page 22-23, the member
that parses bool values was omitted from the list of definitions of non-virtual
<p><b>Proposed resolution:</b></p>
-<p>Add at the beginning of 22.2.2.1.1 [facet.num.get.members]
+<p>Add at the beginning of 22.4.2.1.1 [facet.num.get.members]
another get member for bool&, copied from the entry in
-22.2.2.1 [locale.num.get].</p>
+22.4.2.1 [locale.num.get].</p>
<hr>
<h3><a name="19"></a>19. "Noconv" definition too vague</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#10">10</a></p>
<p><b>Discussion:</b></p>
<p>
<p><b>Proposed resolution:</b></p>
<p>
Change the entry for noconv in the table under paragraph 4 in section
-22.2.1.4.2 [locale.codecvt.virtuals] to read:
+22.4.1.4.2 [locale.codecvt.virtuals] to read:
</p>
<blockquote>
<p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
<hr>
<h3><a name="20"></a>20. Thousands_sep returns wrong type</h3>
-<p><b>Section:</b> 22.2.3.1.2 [facet.numpunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-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>Section:</b> 22.4.3.1.2 [facet.numpunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The synopsis for numpunct<>::do_thousands_sep, and the
definition of numpunct<>::thousands_sep which calls it, specify
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change
+<p>In 22.4.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change
"string_type" to "char_type". </p>
<hr>
<h3><a name="21"></a>21. Codecvt_byname<> instantiations</h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In the second table in the section, captioned "Required
instantiations", the instantiations for codecvt_byname<>
<p><b>Proposed resolution:</b></p>
-<p>Add in 22.1.1.1.1 [locale.category] to the table captioned
+<p>Add in 22.3.1.1.1 [locale.category] to the table captioned
"Required instantiations", in the category "ctype"
the lines </p>
<hr>
<h3><a name="22"></a>22. Member open vs. flags</h3>
-<p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 27.9.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The description of basic_istream<>::open leaves unanswered questions about how it
responds to or changes flags in the error status for the stream. A strict reading
<p><b>Proposed resolution:</b></p>
-<p>In 27.8.1.9 [ifstream.members] paragraph 3, <i>and</i> in 27.8.1.13 [ofstream.members] paragraph 3, under open() effects, add a footnote:
+<p>In 27.9.1.9 [ifstream.members] paragraph 3, <i>and</i> in 27.9.1.13 [ofstream.members] paragraph 3, under open() effects, add a footnote:
</p>
<blockquote>
<hr>
+<h3><a name="23"></a>23. Num_get overflow result</h3>
+<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>The current description of numeric input does not account for the
+possibility of overflow. This is an implicit result of changing the
+description to rely on the definition of scanf() (which fails to
+report overflow), and conflicts with the documented behavior of
+traditional and current implementations. </p>
+
+<p>Users expect, when reading a character sequence that results in a
+value unrepresentable in the specified type, to have an error
+reported. The standard as written does not permit this. </p>
+
+<p><b>Further comments from Dietmar:</b></p>
+
+<p>
+I don't feel comfortable with the proposed resolution to issue 23: It
+kind of simplifies the issue to much. Here is what is going on:
+</p>
+
+<p>
+Currently, the behavior of numeric overflow is rather counter intuitive
+and hard to trace, so I will describe it briefly:
+</p>
+
+<ul>
+ <li>
+ According to 22.4.2.1.2 [facet.num.get.virtuals]
+ paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
+ return an input error; otherwise a value is converted to the rules
+ of <tt>scanf</tt>.
+ </li>
+ <li>
+ <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>.
+ </li>
+ <li>
+ <tt>fscanf()</tt> returns an input failure if during conversion no
+ character matching the conversion specification could be extracted
+ before reaching EOF. This is the only reason for <tt>fscanf()</tt>
+ to fail due to an input error and clearly does not apply to the case
+ of overflow.
+ </li>
+ <li>
+ Thus, the conversion is performed according to the rules of
+ <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
+ <tt>strtol()</tt>, etc. are to be used for the conversion.
+ </li>
+ <li>
+ The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
+ many matching characters as there are and on overflow continue to
+ consume matching characters but also return a value identical to
+ the maximum (or minimum for signed types if there was a leading minus)
+ value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
+ </li>
+ <li>
+ Thus, according to the current wording in the standard, overflows
+ can be detected! All what is to be done is to check <tt>errno</tt>
+ after reading an element and, of course, clearing <tt>errno</tt>
+ before trying a conversion. With the current wording, it can be
+ detected whether the overflow was due to a positive or negative
+ number for signed types.
+ </li>
+</ul>
+
+<p><b>Further discussion from Redmond:</b></p>
+
+<p>The basic problem is that we've defined our behavior,
+including our error-reporting behavior, in terms of C90. However,
+C90's method of reporting overflow in scanf is not technically an
+"input error". The <tt>strto_*</tt> functions are more precise.</p>
+
+<p>There was general consensus that <tt>failbit</tt> should be set
+upon overflow. We considered three options based on this:</p>
+<ol>
+<li>Set failbit upon conversion error (including overflow), and
+ don't store any value.</li>
+<li>Set failbit upon conversion error, and also set <tt>errno</tt> to
+ indicated the precise nature of the error.</li>
+<li>Set failbit upon conversion error. If the error was due to
+ overflow, store +-numeric_limits<T>::max() as an
+ overflow indication.</li>
+</ol>
+
+<p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
+
+
+<p>Discussed at Lillehammer. General outline of what we want the
+ solution to look like: we want to say that overflow is an error, and
+ provide a way to distinguish overflow from other kinds of errors.
+ Choose candidate field the same way scanf does, but don't describe
+ the rest of the process in terms of format. If a finite input field
+ is too large (positive or negative) to be represented as a finite
+ value, then set failbit and assign the nearest representable value.
+ Bill will provide wording.</p>
+
+<p>
+Discussed at Toronto:
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
+is in alignment with the direction we wanted to go with in Lillehammer. Bill
+to work on.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change 22.4.2.1.2 [facet.num.get.virtuals], end of p3:
+</p>
+
+<blockquote>
+<p>
+<b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del>
+<ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is
+converted to a numeric value by the rules of one of the functions declared
+in the header <tt><cstdlib></tt>:</ins>
+</p>
+<ul>
+<li>
+<del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is
+converted (according to the rules of <tt>scanf</tt>) to a value of the
+type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is
+stored in <i>err</i>.</del>
+<ins>For a signed integer value, the function <tt>strtoll</tt>.</ins>
+</li>
+<li>
+<del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused
+<tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is
+assigned to <i>err</i>.</del>
+<ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins>
+</li>
+<li>
+<ins>For a floating-point value, the function <tt>strtold</tt>.</ins>
+</li>
+</ul>
+<p>
+<ins>The numeric value to be stored can be one of:</ins>
+</p>
+<ul>
+<li><ins>zero, if the conversion function fails to convert the entire field.
+<tt>ios_base::failbit</tt> is assigned to err.</ins></li>
+<li><ins>the most positive representable value, if the field represents a value
+too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned
+to <i>err</i>.</ins></li>
+<li><ins>the most negative representable value (zero for unsigned integer), if
+the field represents a value too large negative to be represented in <i>val</i>.
+<tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li>
+<li><ins>the converted value, otherwise.</ins></li>
+</ul>
+
+<p><ins>
+The resultant numeric value is stored in <i>val</i>.
+</ins></p>
+</blockquote>
+
+<p>
+Change 22.4.2.1.2 [facet.num.get.virtuals], p6-p7:
+</p>
+
+<blockquote>
+<pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base& <i>str</i>,
+ ios_base::iostate& <i>err</i>, bool& <i>val</i>) const;
+</pre>
+<blockquote>
+<p>
+-6- <i>Effects:</i> If
+<tt>(<i>str</i>.flags()&ios_base::boolalpha)==0</tt> then input
+proceeds as it would for a <tt>long</tt> except that if a value is being
+stored into <i>val</i>, the value is determined according to the
+following: If the value to be stored is 0 then <tt>false</tt> is stored.
+If the value is 1 then <tt>true</tt> is stored. Otherwise
+<del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is
+stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins>
+</p>
+<p>
+-7- Otherwise target sequences are determined "as if" by calling the
+members <tt>falsename()</tt> and <tt>truename()</tt> of the facet
+obtained by <tt>use_facet<numpunct<charT>
+>(<i>str</i>.getloc())</tt>. Successive characters in the range
+<tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched
+against corresponding positions in the target sequences only as
+necessary to identify a unique match. The input iterator <i>in</i> is
+compared to <i>end</i> only when necessary to obtain a character. If <del>and
+only if</del> a target sequence is uniquely matched, <i>val</i> is set to the
+corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt>
+is assigned to <i>err</i>.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
<h3><a name="24"></a>24. "do_convert" doesn't exist</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#72">72</a></p>
<p><b>Discussion:</b></p>
<p>The description of codecvt<>::do_out and do_in mentions a
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.4 [locale.codecvt], paragraph 3, change
-"do_convert" to "do_in or do_out". Also, in 22.2.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in
+<p>In 22.4.1.4 [locale.codecvt], paragraph 3, change
+"do_convert" to "do_in or do_out". Also, in 22.4.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in
or do_out". </p>
<hr>
<h3><a name="25"></a>25. String operator<< uses width() value wrong</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#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#67">67</a></p>
<p><b>Discussion:</b></p>
<p>In the description of operator<< applied to strings, the standard says that uses
<p><b>Proposed resolution:</b></p>
-<p>Change 21.3.8.9 [string.io] paragraph 4 from:<br>
+<p>Change 21.4.8.9 [string.io] paragraph 4 from:<br>
<br>
"... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
..."<br>
<hr>
<h3><a name="26"></a>26. Bad sentry example</h3>
-<p><b>Section:</b> 27.6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In paragraph 6, the code in the example: </p>
<p><b>Proposed resolution:</b></p>
-<p>Remove the example above from 27.6.1.1.3 [istream::sentry]
+<p>Remove the example above from 27.7.1.1.3 [istream::sentry]
paragraph 6.</p>
<hr>
<h3><a name="27"></a>27. String::erase(range) yields wrong iterator</h3>
-<p><b>Section:</b> 21.3.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 21.4.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::erase">issues</a> in [string::erase].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The string::erase(iterator first, iterator last) is specified to return an element one
place beyond the next element after the last one erased. E.g. for the string
<p><b>Proposed resolution:</b></p>
-<p>In 21.3.6.5 [string::erase], paragraph 10, change: </p>
+<p>In 21.4.6.5 [string::erase], paragraph 10, change: </p>
<blockquote>
<p>Returns: an iterator which points to the element immediately following _last_ prior to
<hr>
<h3><a name="28"></a>28. Ctype<char>is ambiguous</h3>
-<p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#236">236</a></p>
<p><b>Discussion:</b></p>
<p>The description of the vector form of ctype<char>::is can be interpreted to mean
<p><b>Proposed resolution:</b></p>
-<p>Change 22.2.1.3.2 [facet.ctype.char.members], paragraph 4, to read </p>
+<p>Change 22.4.1.3.2 [facet.ctype.char.members], paragraph 4, to read </p>
<blockquote>
<p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
<hr>
<h3><a name="29"></a>29. Ios_base::init doesn't exist</h3>
-<p><b>Section:</b> 27.3.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 27.4.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#narrow.stream.objects">issues</a> in [narrow.stream.objects].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>Sections 27.3.1 [narrow.stream.objects] and 27.3.2 [wide.stream.objects] mention
+<p>Sections 27.4.1 [narrow.stream.objects] and 27.4.2 [wide.stream.objects] mention
a function ios_base::init, which is not defined. Probably they mean
-basic_ios<>::init, defined in 27.4.4.1 [basic.ios.cons],
+basic_ios<>::init, defined in 27.5.4.1 [basic.ios.cons],
paragraph 3. </p>
<p><b>Proposed resolution:</b></p>
<p>[R12: modified to include paragraph 5.]</p>
-<p>In 27.3.1 [narrow.stream.objects] paragraph 2 and 5, change </p>
+<p>In 27.4.1 [narrow.stream.objects] paragraph 2 and 5, change </p>
<blockquote>
<p>ios_base::init </p>
<p>basic_ios<char>::init </p>
</blockquote>
-<p>Also, make a similar change in 27.3.2 [wide.stream.objects] except it
+<p>Also, make a similar change in 27.4.2 [wide.stream.objects] except it
should read </p>
<blockquote>
<hr>
<h3><a name="30"></a>30. Wrong header for LC_*</h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>,
where they are in fact defined elsewhere to appear in <clocale>. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1.1.1 [locale.category], paragraph 2, change
+<p>In 22.3.1.1.1 [locale.category], paragraph 2, change
"<cctype>" to read "<clocale>". </p>
<hr>
<h3><a name="31"></a>31. Immutable locale values</h3>
-<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#378">378</a></p>
<p><b>Discussion:</b></p>
<p>Paragraph 6, says "An instance of <tt>locale</tt> is
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1 [locale] replace paragraph 6</p>
+<p>In 22.3.1 [locale] replace paragraph 6</p>
<blockquote>
<p>An instance of <tt>locale</tt> is immutable; once a facet
<hr>
<h3><a name="32"></a>32. Pbackfail description inconsistent</h3>
-<p><b>Section:</b> 27.5.2.4.4 [streambuf.virt.pback] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-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>Section:</b> 27.6.2.4.4 [streambuf.virt.pback] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The description of the required state before calling virtual member
basic_streambuf<>::pbackfail requirements is inconsistent with the conditions
<p><b>Proposed resolution:</b></p>
-<p>In 27.5.2.4.4 [streambuf.virt.pback], paragraph 1, change:</p>
+<p>In 27.6.2.4.4 [streambuf.virt.pback], paragraph 1, change:</p>
<blockquote>
<p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
<hr>
<h3><a name="33"></a>33. Codecvt<> mentions from_type</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#43">43</a></p>
<p><b>Discussion:</b></p>
<p>In the table defining the results from do_out and do_in, the specification for the
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition
+<p>In 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition
in the table for the case of _error_ with </p>
<blockquote>
<hr>
<h3><a name="34"></a>34. True/falsename() not in ctype<></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#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In paragraph 19, Effects:, members truename() and falsename are used from facet
ctype<charT>, but it has no such members. Note that this is also a problem in
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects:
+<p>In 22.4.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects:
clause for member put(...., bool), replace the initialization of the
string_type value s as follows: </p>
<hr>
<h3><a name="35"></a>35. No manipulator unitbuf in synopsis</h3>
-<p><b>Section:</b> 27.4 [iostreams.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-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>Section:</b> 27.5 [iostreams.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In 27.4.5.1 [fmtflags.manip], we have a definition for a manipulator
+<p>In 27.5.5.1 [fmtflags.manip], we have a definition for a manipulator
named "unitbuf". Unlike other manipulators, it's not listed
in synopsis. Similarly for "nounitbuf". </p>
<p><b>Proposed resolution:</b></p>
-<p>Add to the synopsis for <ios> in 27.4 [iostreams.base], after
+<p>Add to the synopsis for <ios> in 27.5 [iostreams.base], after
the entry for "nouppercase", the prototypes: </p>
<blockquote>
<hr>
<h3><a name="36"></a>36. Iword & pword storage lifetime omitted</h3>
-<p><b>Section:</b> 27.4.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 27.5.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
specified badly, so that an implementation which only keeps the last value stored appears
<p><b>Proposed resolution:</b></p>
-<p>Add in 27.4.2.5 [ios.base.storage], in both paragraph 2 and also in
+<p>Add in 27.5.2.5 [ios.base.storage], in both paragraph 2 and also in
paragraph 4, replace the sentence: </p>
<blockquote>
<hr>
<h3><a name="37"></a>37. Leftover "global" reference</h3>
-<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In the overview of locale semantics, paragraph 4, is the sentence </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1 [locale], paragraph 4, delete the parenthesized
+<p>In 22.3.1 [locale], paragraph 4, delete the parenthesized
expression </p>
<blockquote>
<hr>
<h3><a name="38"></a>38. Facet definition incomplete</h3>
-<p><b>Section:</b> 22.1.2 [locale.global.templates] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-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>Section:</b> 22.3.2 [locale.global.templates] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>It has been noticed by Esa Pulkkinen that the definition of
"facet" is incomplete. In particular, a class derived from
<blockquote>
<p>Requires: <tt>Facet</tt> is a facet class whose definition
- contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 [locale.facet]. </p>
+ contains the public static member <tt>id</tt> as defined in 22.3.1.1.2 [locale.facet]. </p>
</blockquote>
<p><i>[
<hr>
<h3><a name="39"></a>39. istreambuf_iterator<>::operator++(int) definition garbled</h3>
-<p><b>Section:</b> 24.5.3.4 [istreambuf.iterator::op++] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-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>Section:</b> 24.6.3.4 [istreambuf.iterator::op++] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Following the definition of istreambuf_iterator<>::operator++(int) in paragraph
3, the standard contains three lines of garbage text left over from a previous edit. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 24.5.3.4 [istreambuf.iterator::op++], delete the three lines of code at the
+<p>In 24.6.3.4 [istreambuf.iterator::op++], delete the three lines of code at the
end of paragraph 3. </p>
<hr>
<h3><a name="40"></a>40. Meaningless normative paragraph in examples</h3>
-<p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 22.4.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 3 of the locale examples is a description of part of an
implementation technique that has lost its referent, and doesn't mean
<p><b>Proposed resolution:</b></p>
-<p>Delete 22.2.8 [facets.examples] paragraph 3 which begins "This
+<p>Delete 22.4.8 [facets.examples] paragraph 3 which begins "This
initialization/identification system depends...", or (at the
editor's option) replace it with a place-holder to keep the paragraph
numbering the same. </p>
<hr>
<h3><a name="41"></a>41. Ios_base needs clear(), exceptions()</h3>
-<p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 27.5.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#157">157</a></p>
<p><b>Discussion:</b></p>
-<p>The description of ios_base::iword() and pword() in 27.4.2.4 [ios.members.static], say that if they fail, they "set badbit,
+<p>The description of ios_base::iword() and pword() in 27.5.2.4 [ios.members.static], say that if they fail, they "set badbit,
which may throw an exception". However, ios_base offers no
interface to set or to test badbit; those interfaces are defined in
basic_ios<>. </p>
<p><b>Proposed resolution:</b></p>
-<p>Change the description in 27.4.2.5 [ios.base.storage] in
+<p>Change the description in 27.5.2.5 [ios.base.storage] in
paragraph 2, and also in paragraph 4, as follows. Replace</p>
<blockquote>
<hr>
<h3><a name="42"></a>42. String ctors specify wrong default allocator</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#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The basic_string<> copy constructor: </p>
<p><b>Proposed resolution:</b></p>
-<p> In 21.3 [basic.string], replace the declaration of the copy
+<p> In 21.4 [basic.string], replace the declaration of the copy
constructor as follows: </p>
<blockquote>
const Allocator& a = Allocator());</pre>
</blockquote>
-<p>In 21.3.1 [string.require], replace the copy constructor declaration
+<p>In 21.4.1 [string.require], replace the copy constructor declaration
as above. Add to paragraph 5, Effects:</p>
<blockquote>
<p>The LWG considered two other possible resolutions:</p>
-<p>A. In 21.3 [basic.string], replace the declaration of the copy
+<p>A. In 21.4 [basic.string], replace the declaration of the copy
constructor as follows:</p>
<blockquote>
size_type n, const Allocator& a); </pre>
</blockquote>
-<p>In 21.3.1 [string.require], replace the copy constructor declaration
+<p>In 21.4.1 [string.require], replace the copy constructor declaration
as above. Add to paragraph 5, Effects: </p>
<blockquote>
value <tt>str.get_allocator()</tt>. </p>
</blockquote>
-<p>B. In 21.3 [basic.string], and also in 21.3.1 [string.require], replace
+<p>B. In 21.4 [basic.string], and also in 21.4.1 [string.require], replace
the declaration of the copy constructor as follows: </p>
<blockquote>
<hr>
<h3><a name="44"></a>44. Iostreams use operator== on int_type values</h3>
-<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Many of the specifications for iostreams specify that character
values or their int_type equivalents are compared using operators ==
<hr>
<h3><a name="46"></a>46. Minor Annex D errors</h3>
-<p><b>Section:</b> D.7 [depr.str.strstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1998-06-01</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>Section:</b> D.7 [depr.str.strstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Brendan Kehoe <b>Opened:</b> 1998-06-01 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p><p>See lib-6522 and edit-814.</p>
<p><b>Proposed resolution:</b></p>
<hr>
<h3><a name="47"></a>47. Imbue() and getloc() Returns clauses swapped</h3>
-<p><b>Section:</b> 27.4.2.3 [ios.base.locales] <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-06-21</p>
+<p><b>Section:</b> 27.5.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.locales">issues</a> in [ios.base.locales].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
section has two RETURNS clauses, and they make no sense as
<p><b>Proposed resolution:</b></p>
-<p>In 27.4.2.3 [ios.base.locales] swap paragraphs 2 and 4.</p>
+<p>In 27.5.2.3 [ios.base.locales] swap paragraphs 2 and 4.</p>
<hr>
<h3><a name="48"></a>48. Use of non-existent exception constructor</h3>
-<p><b>Section:</b> 27.4.2.1.1 [ios::failure] <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-06-21</p>
+<p><b>Section:</b> 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.4.2.1.1, paragraph 2, says that class failure initializes the
base class, exception, with exception(msg). Class exception (see
<p><b>Proposed resolution:</b></p>
-<p>Replace 27.4.2.1.1 [ios::failure], paragraph 2, with</p>
+<p>Replace 27.5.2.1.1 [ios::failure], paragraph 2, with</p>
<blockquote>
<p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
<hr>
<h3><a name="49"></a>49. Underspecification of ios_base::sync_with_stdio</h3>
-<p><b>Section:</b> 27.4.2.4 [ios.members.static] <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-06-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>Section:</b> 27.5.2.4 [ios.members.static] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Two problems</p>
<p><b>Proposed resolution:</b></p>
-<p>Change the following sentence in 27.4.2.4 [ios.members.static]
+<p>Change the following sentence in 27.5.2.4 [ios.members.static]
returns clause from:</p>
<blockquote>
<tt>false</tt>.</p>
</blockquote>
-<p>Add the following immediately after 27.4.2.4 [ios.members.static],
+<p>Add the following immediately after 27.5.2.4 [ios.members.static],
paragraph 2:</p>
<blockquote>
<hr>
<h3><a name="50"></a>50. Copy constructor and assignment operator of ios_base</h3>
-<p><b>Section:</b> 27.4.2 [ios.base] <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-06-21</p>
+<p><b>Section:</b> 27.5.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>As written, ios_base has a copy constructor and an assignment
operator. (Nothing in the standard says it doesn't have one, and all
<p><b>Proposed resolution:</b></p>
-<p>In 27.4.2 [ios.base], class ios_base, specify the copy
+<p>In 27.5.2 [ios.base], class ios_base, specify the copy
constructor and operator= members as being private.</p>
<hr>
<h3><a name="51"></a>51. Requirement to not invalidate iterators missing</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#TC">TC</a>
- <b>Submitter:</b> David Vandevoorde <b>Date:</b> 1998-06-23</p>
+<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> David Vandevoorde <b>Opened:</b> 1998-06-23 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The std::sort algorithm can in general only sort a given sequence
by moving around values. The list<>::sort() member on the other
<hr>
<h3><a name="52"></a>52. Small I/O problems</h3>
-<p><b>Section:</b> 27.4.3.2 [fpos.operations] <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-06-23</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>Section:</b> 27.5.3.2 [fpos.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-23 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>First, 27.4.4.1 [basic.ios.cons], table 89. This is pretty obvious:
+<p>First, 27.5.4.1 [basic.ios.cons], table 89. This is pretty obvious:
it should be titled "basic_ios<>() effects", not
"ios_base() effects". </p>
<p>[The second item is a duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#6">6</a> for
resolution.]</p>
-<p>Second, 27.4.3.2 [fpos.operations] table 88 . There are a couple
+<p>Second, 27.5.3.2 [fpos.operations] table 88 . There are a couple
different things wrong with it, some of which I've already discussed
with Jerry, but the most obvious mechanical sort of error is that it
uses expressions like P(i) and p(i), without ever defining what sort
<p><b>Proposed resolution:</b></p>
-<p>Change 27.4.4.1 [basic.ios.cons] table 89 title from
+<p>Change 27.5.4.1 [basic.ios.cons] table 89 title from
"ios_base() effects" to "basic_ios<>()
effects". </p>
<hr>
<h3><a name="53"></a>53. Basic_ios destructor unspecified</h3>
-<p><b>Section:</b> 27.4.4.1 [basic.ios.cons] <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-06-23</p>
+<p><b>Section:</b> 27.5.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-23 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
The important question is whether basic_ios::~basic_ios() destroys
<p><b>Proposed resolution:</b></p>
-<p>Add after 27.4.4.1 [basic.ios.cons] paragraph 2:</p>
+<p>Add after 27.5.4.1 [basic.ios.cons] paragraph 2:</p>
<blockquote>
<p><tt>virtual ~basic_ios();</tt></p>
<p><b>Rationale:</b></p>
<p>The LWG reviewed the additional question of whether or not
<tt>rdbuf(0)</tt> may set <tt>badbit</tt>. The answer is
-clearly yes; it may be set via <tt>clear()</tt>. See 27.4.4.2 [basic.ios.members], paragraph 6. This issue was reviewed at length
+clearly yes; it may be set via <tt>clear()</tt>. See 27.5.4.2 [basic.ios.members], paragraph 6. This issue was reviewed at length
by the LWG, which removed from the original proposed resolution a
footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
<tt>badbit</tt>".</p>
<hr>
<h3><a name="54"></a>54. Basic_streambuf's destructor</h3>
-<p><b>Section:</b> 27.5.2.1 [streambuf.cons] <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-06-25</p>
+<p><b>Section:</b> 27.6.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-25 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.cons">issues</a> in [streambuf.cons].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The class synopsis for basic_streambuf shows a (virtual)
destructor, but the standard doesn't say what that destructor does. My
<p><b>Proposed resolution:</b></p>
-<p>Add after 27.5.2.1 [streambuf.cons] paragraph 2:</p>
+<p>Add after 27.6.2.1 [streambuf.cons] paragraph 2:</p>
<blockquote>
<p><tt>virtual ~basic_streambuf();</tt></p>
<hr>
<h3><a name="55"></a>55. Invalid stream position is undefined</h3>
-<p><b>Section:</b> 27 [input.output] <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-06-26</p>
+<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-26 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Several member functions in clause 27 are defined in certain
circumstances to return an "invalid stream position", a term
stream position" should not be changed:</p>
<blockquote>
- <p>27.7.1.4 [stringbuf.virtuals], paragraph 14<br>
- 27.8.1.5 [filebuf.virtuals], paragraph 14<br>
+ <p>27.8.1.4 [stringbuf.virtuals], paragraph 14<br>
+ 27.9.1.5 [filebuf.virtuals], paragraph 14<br>
D.7.1.3 [depr.strstreambuf.virtuals], paragraph 17
</p>
</blockquote>
<p><b>Proposed resolution:</b></p>
-<p>In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an
+<p>In 27.6.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an
object of class pos_type that stores an invalid stream position
(_lib.iostreams.definitions_)" to "Returns
<tt>pos_type(off_type(-1))</tt>".
</p>
-<p>In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns
+<p>In 27.6.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns
an object of class pos_type that stores an invalid stream
position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
-<p>In 27.7.1.4 [stringbuf.virtuals], paragraph 13, change "the object
+<p>In 27.8.1.4 [stringbuf.virtuals], paragraph 13, change "the object
stores an invalid stream position" to "the return value is
<tt>pos_type(off_type(-1))</tt>". </p>
-<p>In 27.8.1.5 [filebuf.virtuals], paragraph 13, change "returns an
+<p>In 27.9.1.5 [filebuf.virtuals], paragraph 13, change "returns an
invalid stream position (27.4.3)" to "returns
<tt>pos_type(off_type(-1))</tt>" </p>
-<p>In 27.8.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise
+<p>In 27.9.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise
returns an invalid stream position (_lib.iostreams.definitions_)"
to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
</p>
<hr>
<h3><a name="56"></a>56. Showmanyc's return type</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#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-29</p>
+<p><b>Section:</b> 27.6.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-29 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The class summary for basic_streambuf<>, in 27.5.2, says that
showmanyc has return type int. However, 27.5.2.4.3 says that its
<p><b>Proposed resolution:</b></p>
<p>Change <tt>showmanyc</tt>'s return type in the
-27.5.2 [streambuf] class summary to <tt>streamsize</tt>.</p>
+27.6.2 [streambuf] class summary to <tt>streamsize</tt>.</p>
<hr>
<h3><a name="57"></a>57. Mistake in char_traits</h3>
-<p><b>Section:</b> 21.1.3.4 [char.traits.specializations.wchar.t] <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-07-01</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>Section:</b> 21.2.3.4 [char.traits.specializations.wchar.t] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-01 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>21.1.3.2, paragraph 3, says "The types streampos and
wstreampos may be different if the implementation supports no shift
<p><b>Proposed resolution:</b></p>
-<p>Remove the sentence in 21.1.3.4 [char.traits.specializations.wchar.t] paragraph 3 which
+<p>Remove the sentence in 21.2.3.4 [char.traits.specializations.wchar.t] paragraph 3 which
begins "The types streampos and wstreampos may be
different..." . </p>
<hr>
<h3><a name="59"></a>59. Ambiguity in specification of gbump</h3>
-<p><b>Section:</b> 27.5.2.3.2 [streambuf.get.area] <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-07-28</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>Section:</b> 27.6.2.3.2 [streambuf.get.area] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-28 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
next pointer for the input sequence by n." </p>
<p><b>Proposed resolution:</b></p>
-<p>Change 27.5.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:</p>
+<p>Change 27.6.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:</p>
<blockquote>
<p>Effects: Advances the next pointer for the input sequence by n.</p>
<p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
</blockquote>
-<p>Make the same change to 27.5.2.3.3 [streambuf.put.area] paragraph 4 pbump
+<p>Make the same change to 27.6.2.3.3 [streambuf.put.area] paragraph 4 pbump
effects.</p>
<hr>
<h3><a name="60"></a>60. What is a formatted input function?</h3>
-<p><b>Section:</b> 27.6.1.2.1 [istream.formatted.reqmts] <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-08-03</p>
+<p><b>Section:</b> 27.7.1.2.1 [istream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-03 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#163">163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a></p>
<p><b>Discussion:</b></p>
<p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
apply to them. </p>
<p>Additional comments from Dietmar Kühl: It appears to be somewhat
-nonsensical to consider the functions defined in 27.6.1.2.3
+nonsensical to consider the functions defined in 27.7.1.2.3
[istream::extractors] paragraphs 1 to 5 to be "Formatted input
function" but since these functions are defined in a section
labeled "Formatted input functions" it is unclear to me
whether these operators are considered formatted input functions which
-have to conform to the "common requirements" from 27.6.1.2.1
+have to conform to the "common requirements" from 27.7.1.2.1
[istream.formatted.reqmts]: If this is the case, all manipulators, not
just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
set (... but setting <tt>noskipws</tt> using the manipulator syntax
would also skip whitespace :-)</p> <p>It is not clear which functions
are to be considered unformatted input functions. As written, it seems
-that all functions in 27.6.1.3 [istream.unformatted] are unformatted input
+that all functions in 27.7.1.3 [istream.unformatted] are unformatted input
functions. However, it does not really make much sense to construct a
sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
unclear what happens to the <tt>gcount()</tt> if
<hr>
<h3><a name="61"></a>61. Ambiguity in iostreams exception policy</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#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The introduction to the section on unformatted input (27.6.1.3)
says that every unformatted input function catches all exceptions that
<hr>
<h3><a name="62"></a>62. <tt>Sync</tt>'s return value</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#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-06</p>
+<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
"calls rdbuf()->pubsync() and, if that function returns -1
<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.3 [istream.unformatted], paragraph 36, change "returns
+<p>In 27.7.1.3 [istream.unformatted], paragraph 36, change "returns
<tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
</p>
<hr>
<h3><a name="63"></a>63. Exception-handling policy for unformatted output</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#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-11</p>
+<p><b>Section:</b> 27.7.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-11 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Clause 27 details an exception-handling policy for formatted input,
unformatted input, and formatted output. It says nothing for
<hr>
<h3><a name="64"></a>64. Exception handling in <tt>basic_istream::operator>>(basic_streambuf*)</tt></h3>
-<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <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-08-11</p>
+<p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-11 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
different ways, depending on whether the second sentence is read as an
<p><b>Proposed resolution:</b></p>
-<p>Replace 27.6.1.2.3 [istream::extractors], paragraph 13, which begins
+<p>Replace 27.7.1.2.3 [istream::extractors], paragraph 13, which begins
"If the function inserts no characters ..." with:</p>
<blockquote>
<hr>
<h3><a name="66"></a>66. Strstreambuf::setbuf</h3>
-<p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <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-08-18</p>
+<p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-18 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
"Performs an operation that is defined separately for each class
<hr>
<h3><a name="68"></a>68. Extractors for char* should store null at end</h3>
-<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1998-07-14</p>
+<p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1998-07-14 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Extractors for char* (27.6.1.2.3) do not store a null character
after the extracted character sequence whereas the unformatted
<p><b>Proposed resolution:</b></p>
-<p>27.6.1.2.3 [istream::extractors], paragraph 7, change the last list
+<p>27.7.1.2.3 [istream::extractors], paragraph 7, change the last list
item from:</p>
<blockquote><p>
<hr>
<h3><a name="69"></a>69. Must elements of a vector be contiguous?</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#TC">TC</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1998-07-29</p>
+<p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1998-07-29 <b>Last modified:</b> 2008-09-26</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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
<p><b>Proposed resolution:</b></p>
-<p>Add the following text to the end of 23.2.6 [vector],
+<p>Add the following text to the end of 23.3.6 [vector],
paragraph 1. </p>
<blockquote>
<ul>
<li>An operational definition similar to the above proposed resolution is
- already used for valarray (26.5.2.3 [valarray.access]).</li>
+ already used for valarray (26.6.2.3 [valarray.access]).</li>
<li>There is no need to explicitly consider a user-defined operator&
- because elements must be copyconstructible (23.1 [container.requirements] para 3)
- and copyconstructible (20.1.1 [utility.arg.requirements]) specifies
+ because elements must be copyconstructible (23.2 [container.requirements] para 3)
+ and copyconstructible (X [utility.arg.requirements]) specifies
requirements for operator&.</li>
<li>There is no issue of one-past-the-end because of language rules.</li>
</ul>
<hr>
<h3><a name="70"></a>70. Uncaught_exception() missing throw() specification</h3>
-<p><b>Section:</b> 18.7 [support.exception], 18.7.4 [uncaught] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-08-03</p>
+<p><b>Section:</b> 18.8 [support.exception], 18.8.4 [uncaught] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-08-03 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.exception">issues</a> in [support.exception].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
<p><b>Proposed resolution:</b></p>
-<p>In 15.5.3 [except.uncaught], paragraph 1, 18.7 [support.exception],
-and 18.7.4 [uncaught], add "throw()" to uncaught_exception().</p>
+<p>In 15.5.3 [except.uncaught], paragraph 1, 18.8 [support.exception],
+and 18.8.4 [uncaught], add "throw()" to uncaught_exception().</p>
<hr>
<h3><a name="71"></a>71. Do_get_monthname synopsis missing argument</h3>
-<p><b>Section:</b> 22.2.5.1 [locale.time.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-13</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>Section:</b> 22.4.5.1 [locale.time.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-13 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The locale facet member <tt>time_get<>::do_get_monthname</tt>
-is described in 22.2.5.1.2 [locale.time.get.virtuals] with five arguments,
+is described in 22.4.5.1.2 [locale.time.get.virtuals] with five arguments,
consistent with do_get_weekday and with its specified use by member
get_monthname. However, in the synopsis, it is specified instead with
four arguments. The missing argument is the "end" iterator
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.5.1 [locale.time.get], add an "end" argument to
+<p>In 22.4.5.1 [locale.time.get], add an "end" argument to
the declaration of member do_monthname as follows:</p>
<pre> virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&,
<hr>
<h3><a name="74"></a>74. Garbled text for <tt>codecvt::do_max_length</tt></h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <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-09-08</p>
+<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-09-08 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
<p><b>Proposed resolution:</b></p>
-<p>Replace 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the
+<p>Replace 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the
following:</p>
<blockquote><p>
<hr>
<h3><a name="75"></a>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
+<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
<b>Submitter:</b> Matt
-Austern <b>Date:</b> 1998-09-18</p>
+Austern <b>Opened:</b> 1998-09-18 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The class synopses for classes <tt>codecvt<></tt> (22.2.1.5)
and <tt>codecvt_byname<></tt> (22.2.1.6) say that the first
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.4 [locale.codecvt], and also in 22.2.1.5 [locale.codecvt.byname],
+<p>In 22.4.1.4 [locale.codecvt], and also in 22.4.1.5 [locale.codecvt.byname],
change the <tt>stateT</tt> argument type on both member
<tt>length()</tt> and member <tt>do_length()</tt> from </p>
<p><tt>stateT&</tt></p>
</blockquote>
-<p>In 22.2.1.4.2 [locale.codecvt.virtuals], add to the definition for member
+<p>In 22.4.1.4.2 [locale.codecvt.virtuals], add to the definition for member
<tt>do_length</tt> a paragraph:</p>
<blockquote>
<hr>
<h3><a name="76"></a>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <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-09-25</p>
+<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-09-25 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>This issue concerns the requirements on classes derived from
<tt>codecvt</tt>, including user-defined classes. What are the
subsequence that maps to <i>N-1</i> internal characters.) </p>
<p>Some of the wording in the standard, such as the description of
-<tt>codecvt::do_max_length</tt> (22.2.1.4.2 [locale.codecvt.virtuals],
-paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be
+<tt>codecvt::do_max_length</tt> (22.4.1.4.2 [locale.codecvt.virtuals],
+paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.9.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be
possible to pick off internal characters one at a time from a sequence
of external characters. However, this is never explicitly stated one
way or the other. </p>
<p><b>Proposed resolution:</b></p>
-<p>Add the following text as a new paragraph, following 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 2:</p>
+<p>Add the following text as a new paragraph, following 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 2:</p>
<blockquote>
<p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
-(27.8 [file.streams]) must have the property that if</p>
+(27.9 [file.streams]) must have the property that if</p>
<pre> do_out(state, from, from_end, from_next, to, to_lim, to_next)
</pre>
<p>would return <tt>ok</tt>, where <tt>from != from_end</tt>, then </p>
<hr>
<h3><a name="78"></a>78. Typo: event_call_back</h3>
-<p><b>Section:</b> 27.4.2 [ios.base] <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> 1998-09-29</p>
+<p><b>Section:</b> 27.5.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>typo: event_call_back should be event_callback </p>
<p><b>Proposed resolution:</b></p>
-<p>In the 27.4.2 [ios.base] synopsis change
+<p>In the 27.5.2 [ios.base] synopsis change
"event_call_back" to "event_callback". </p>
<hr>
<h3><a name="79"></a>79. Inconsistent declaration of polar()</h3>
-<p><b>Section:</b> 26.3.1 [complex.synopsis], 26.3.7 [complex.value.ops] <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> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.synopsis">issues</a> in [complex.synopsis].</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>Section:</b> 26.4.1 [complex.syn], 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2009-03-21</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.syn">issues</a> in [complex.syn].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In 26.3.1 [complex.synopsis] polar is declared as follows:</p>
+<p>In 26.4.1 [complex.syn] polar is declared as follows:</p>
<pre> template<class T> complex<T> polar(const T&, const T&); </pre>
-<p>In 26.3.7 [complex.value.ops] it is declared as follows:</p>
+<p>In 26.4.7 [complex.value.ops] it is declared as follows:</p>
<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
<p>Thus whether the second parameter is optional is not clear. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 26.3.1 [complex.synopsis] change:</p>
+<p>In 26.4.1 [complex.syn] change:</p>
<pre> template<class T> complex<T> polar(const T&, const T&);</pre>
<p>to:</p>
<hr>
<h3><a name="80"></a>80. Global Operators of complex declared twice</h3>
-<p><b>Section:</b> 26.3.1 [complex.synopsis], 26.3.2 [complex] <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> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.synopsis">issues</a> in [complex.synopsis].</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>Section:</b> 26.4.1 [complex.syn], 26.4.2 [complex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2009-03-21</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.syn">issues</a> in [complex.syn].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
class complex. This redundancy should be removed.</p>
<hr>
<h3><a name="83"></a>83. String::npos vs. string::max_size()</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#TC">TC</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#89">89</a></p>
<p><b>Discussion:</b></p>
<p>Many string member functions throw if size is getting or exceeding
<p><b>Proposed resolution:</b></p>
-<p>After 21.3 [basic.string] paragraph 4 ("The functions
+<p>After 21.4 [basic.string] paragraph 4 ("The functions
described in this clause...") add a new paragraph:</p>
<blockquote>
<hr>
<h3><a name="86"></a>86. String constructors don't describe exceptions</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#TC">TC</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.require">active issues</a> in [string.require].</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The constructor from a range:</p>
<p><b>Proposed resolution:</b></p>
-<p>In 21.3.1 [string.require], Strike throws paragraphs for
+<p>In 21.4.1 [string.require], Strike throws paragraphs for
constructors which say "Throws: length_error if n ==
npos."</p>
<hr>
<h3><a name="90"></a>90. Incorrect description of operator >> for strings</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#TC">TC</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The effect of operator >> for strings contain the following item:</p>
<p><b>Proposed resolution:</b></p>
-<p>In 21.3.8.9 [string.io] paragraph 1 Effects clause replace:</p>
+<p>In 21.4.8.9 [string.io] paragraph 1 Effects clause replace:</p>
<blockquote>
<p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
<hr>
<h3><a name="91"></a>91. Description of operator>> and getline() for string<> might cause endless loop</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> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Operator >> and getline() for strings read until eof()
in the input stream is true. However, this might never happen, if the
<p><b>Proposed resolution:</b></p>
-<p>In 21.3.8.9 [string.io], paragraph 1, replace:</p>
+<p>In 21.4.8.9 [string.io], paragraph 1, replace:</p>
<blockquote><p>
Effects: Begins by constructing a sentry object k as if k were
constructed by typename basic_istream<charT,traits>::sentry k( is). If
</p></blockquote>
<p>with:</p>
<blockquote><p>
-Effects: Behaves as a formatted input function (27.6.1.2.1
+Effects: Behaves as a formatted input function (27.7.1.2.1
[istream.formatted.reqmts]). After constructing a sentry object, if the
sentry converts to true, calls str.erase() and then extracts
characters from is and appends them to str as if by calling
following occurs:
</p></blockquote>
-<p>In 21.3.8.9 [string.io], paragraph 6, replace</p>
+<p>In 21.4.8.9 [string.io], paragraph 6, replace</p>
<blockquote><p>
Effects: Begins by constructing a sentry object k as if by typename
basic_istream<charT,traits>::sentry k( is, true). If bool( k) is true,
</p></blockquote>
<p>with:</p>
<blockquote><p>Effects: Behaves as an unformatted input function
-(27.6.1.3 [istream.unformatted]), except that it does not affect the
+(27.7.1.3 [istream.unformatted]), except that it does not affect the
value returned
by subsequent calls to basic_istream<>::gcount(). After
constructing a sentry object, if the sentry converts to true, calls
<hr>
<h3><a name="92"></a>92. Incomplete Algorithm Requirements</h3>
-<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
+<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The standard does not state, how often a function object is copied,
called, or the order of calls inside an algorithm. This may lead to
<hr>
<h3><a name="98"></a>98. Input iterator requirements are badly written</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#WP">WP</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
+<p><b>Section:</b> 24.2.2 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>Table 72 in 24.1.1 [input.iterators] specifies semantics for
+<p>Table 72 in 24.2.2 [input.iterators] specifies semantics for
<tt>*r++</tt> of:</p>
<p> <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
<p><b>Proposed resolution:</b></p>
-<p>In Table 72 in 24.1.1 [input.iterators], change the return type
+<p>In Table 72 in 24.2.2 [input.iterators], change the return type
for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</p>
<hr>
<h3><a name="103"></a>103. set::iterator is required to be modifiable, but this allows modification of keys</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Set::iterator is described as implementation-defined with a
reference to the container requirement; the container requirement says
<p><tt>typedef implementation defined iterator;<br>
// See _lib.container.requirements_</tt></p>
-<p>23.1 [container.requirements] actually requires that iterator type pointing
+<p>23.2 [container.requirements] actually requires that iterator type pointing
to T (table 65). Disallowing user modification of keys by changing the
standard to require an iterator for associative container to be the
same as const_iterator would be overkill since that will unnecessarily
<p><b>Other Options Evaluated:</b> </p>
-<p>Option A. In 23.1.4 [associative.reqmts], paragraph 2, after
+<p>Option A. In 23.2.4 [associative.reqmts], paragraph 2, after
first sentence, and before "In addition,...", add one line:
</p>
<p>Modification of keys shall not change their strict weak ordering. </p>
</blockquote>
-<p>Option B. Add three new sentences to 23.1.4 [associative.reqmts]:</p>
+<p>Option B. Add three new sentences to 23.2.4 [associative.reqmts]:</p>
<blockquote>
<p>At the end of paragraph 5: "Keys in an associative container
type."</p>
</blockquote>
-<p>Option C. To 23.1.4 [associative.reqmts], paragraph 3, which
+<p>Option C. To 23.2.4 [associative.reqmts], paragraph 3, which
currently reads:</p>
<blockquote>
<p><b>Proposed resolution:</b></p>
-<p>Add the following to 23.1.4 [associative.reqmts] at
+<p>Add the following to 23.2.4 [associative.reqmts] at
the indicated location:</p>
<blockquote>
<hr>
<h3><a name="106"></a>106. Numeric library private members are implementation defined</h3>
-<p><b>Section:</b> 26.5.5 [template.slice.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
+<p><b>Section:</b> 26.6.5 [template.slice.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.slice.array">issues</a> in [template.slice.array].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>This is the only place in the whole standard where the implementation has to document
something private.</p>
</p>
<ul>
- <li>26.5.5 [template.slice.array]</li>
- <li>26.5.7 [template.gslice.array]</li>
- <li>26.5.8 [template.mask.array]</li>
- <li>26.5.9 [template.indirect.array]</li>
+ <li>26.6.5 [template.slice.array]</li>
+ <li>26.6.7 [template.gslice.array]</li>
+ <li>26.6.8 [template.mask.array]</li>
+ <li>26.6.9 [template.indirect.array]</li>
</ul>
<hr>
<h3><a name="108"></a>108. Lifetime of exception::what() return unspecified</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#TC">TC</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
+<p><b>Section:</b> 18.7.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
exception::what() is left unspecified. This issue has implications
<p><b>Proposed resolution:</b></p>
-<p>Add to 18.6.1 [type.info] paragraph 9 (exception::what notes
+<p>Add to 18.7.1 [type.info] paragraph 9 (exception::what notes
clause) the sentence:</p>
<blockquote>
<hr>
<h3><a name="109"></a>109. Missing binders for non-const sequence elements</h3>
-<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Bjarne Stroustrup <b>Date:</b> 1998-10-07</p>
+<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#CD1">CD1</a>
+ <b>Submitter:</b> Bjarne Stroustrup <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>There are no versions of binders that apply to non-const elements
<hr>
<h3><a name="110"></a>110. istreambuf_iterator::equal not const</h3>
-<p><b>Section:</b> 24.5.3 [istreambuf.iterator], 24.5.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-10-15</p>
+<p><b>Section:</b> 24.6.3 [istreambuf.iterator], 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-10-15 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Member istreambuf_iterator<>::equal is not declared
-"const", yet 24.5.3.6 [istreambuf.iterator::op==] says that operator==,
+"const", yet 24.6.3.6 [istreambuf.iterator::op==] says that operator==,
which is const, calls it. This is contradictory. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 24.5.3 [istreambuf.iterator] and also in 24.5.3.5 [istreambuf.iterator::equal],
+<p>In 24.6.3 [istreambuf.iterator] and also in 24.6.3.5 [istreambuf.iterator::equal],
replace:</p>
<blockquote>
<hr>
<h3><a name="112"></a>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3>
-<p><b>Section:</b> 24.5.4.1 [ostreambuf.iter.cons] <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-10-20</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>Section:</b> 24.6.4.1 [ostreambuf.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-10-20 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
<p><b>Proposed resolution:</b></p>
-<p>In 24.5.4.1 [ostreambuf.iter.cons]:</p>
+<p>In 24.6.4.1 [ostreambuf.iter.cons]:</p>
<p>Move the current paragraph 1, which reads "Requires: s is not
null.", from the first constructor to the second constructor.</p>
<hr>
<h3><a name="114"></a>114. Placement forms example in error twice</h3>
-<p><b>Section:</b> 18.5.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-10-28</p>
+<p><b>Section:</b> 18.6.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-10-28 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a></p>
<p><b>Discussion:</b></p>
<p>Section 18.5.1.3 contains the following example: </p>
<p><b>Proposed resolution:</b></p>
<p>Replace the first line of code in the example in
-18.5.1.3 [new.delete.placement] with:
+18.6.1.3 [new.delete.placement] with:
</p>
<blockquote>
<hr>
<h3><a name="115"></a>115. Typo in strstream constructors</h3>
-<p><b>Section:</b> D.7.4.1 [depr.strstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-11-02</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>Section:</b> D.7.4.1 [depr.strstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-11-02 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>D.7.4.1 strstream constructors paragraph 2 says: </p>
<hr>
<h3><a name="117"></a>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</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> Matt Austern <b>Date:</b> 1998-11-20</p>
+<p><b>Section:</b> 27.7.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-11-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The <b>effects</b> clause for numeric inserters says that
insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
<hr>
<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>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-11-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
<tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
use_facet< numget >(loc).get(*this, 0, *this, err, val);
setstate(err);</pre>
-<p>According to section 22.2.2.1.1 [facet.num.get.members], however,
+<p>According to section 22.4.2.1.1 [facet.num.get.members], however,
<tt>num_get<>::get()</tt> is only overloaded for the types
<tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the
+<p>In 27.7.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the
two lines (1st and 3rd) which read:</p>
<blockquote>
<pre>operator>>(short& val);
<hr>
<h3><a name="119"></a>119. Should virtual functions be allowed to strengthen the exception specification?</h3>
-<p><b>Section:</b> 17.4.4.9 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
+<p><b>Section:</b> 17.6.4.10 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>Section 17.4.4.9 [res.on.exception.handling] states: </p>
+<p>Section 17.6.4.10 [res.on.exception.handling] states: </p>
<p>"An implementation may strengthen the exception-specification
for a function by removing listed exceptions." </p>
<p><b>Proposed resolution:</b></p>
-<p>Change Section 17.4.4.9 [res.on.exception.handling] from:</p>
+<p>Change Section 17.6.4.10 [res.on.exception.handling] from:</p>
<p> "may strengthen the
exception-specification for a function"</p>
<hr>
<h3><a name="120"></a>120. Can an implementor add specializations?</h3>
-<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>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The original issue asked whether a library implementor could
<p><b>Proposed resolution:</b></p>
- <p>Append to 17.4.3.2 [reserved.names] paragraph 1: </p>
+ <p>Append to 17.6.3.3 [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
<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.2 [reserved.names] paragraph 1:</p>
+ note to the end of 17.6.3.3 [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
<hr>
<h3><a name="122"></a>122. streambuf/wstreambuf description should not say they are specializations</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#TC">TC</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
+<p><b>Section:</b> 27.6.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Section 27.5.2 describes the streambuf classes this way: </p>
<p><b>Proposed resolution:</b></p>
-<p>Remove 27.5.2 [streambuf] paragraphs 2 and 3 (the above two
+<p>Remove 27.6.2 [streambuf] paragraphs 2 and 3 (the above two
sentences). </p>
<hr>
<h3><a name="123"></a>123. Should valarray helper arrays fill functions be const?</h3>
-<p><b>Section:</b> 26.5.5.3 [slice.arr.fill], 26.5.7.3 [gslice.array.fill], 26.5.8.3 [mask.array.fill], 26.5.9.3 [indirect.array.fill] <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 issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 26.6.5.3 [slice.arr.fill], 26.6.7.3 [gslice.array.fill], 26.6.8.3 [mask.array.fill], 26.6.9.3 [indirect.array.fill] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>One of the operator= in the valarray helper arrays is const and one
is not. For example, look at slice_array. This operator= in Section
-26.5.5.1 [slice.arr.assign] is const: </p>
+26.6.5.1 [slice.arr.assign] is const: </p>
<p> <tt>void operator=(const valarray<T>&) const;</tt> </p>
-<p>but this one in Section 26.5.5.3 [slice.arr.fill] is not: </p>
+<p>but this one in Section 26.6.5.3 [slice.arr.fill] is not: </p>
<p> <tt>void operator=(const T&); </tt></p>
<p><b>Proposed resolution:</b></p>
-<p>26.5.5 [template.slice.array] Template class slice_array</p>
+<p>26.6.5 [template.slice.array] Template class slice_array</p>
<blockquote>
<p>In the class template definition for slice_array, replace the member
</pre>
</blockquote>
-<p>26.5.5.3 [slice.arr.fill] slice_array fill function</p>
+<p>26.6.5.3 [slice.arr.fill] slice_array fill function</p>
<blockquote>
<p>Change the function declaration</p>
</pre>
</blockquote>
-<p>26.5.7 [template.gslice.array] Template class gslice_array</p>
+<p>26.6.7 [template.gslice.array] Template class gslice_array</p>
<blockquote>
<p>In the class template definition for gslice_array, replace the member
</pre>
</blockquote>
-<p>26.5.7.3 [gslice.array.fill] gslice_array fill function</p>
+<p>26.6.7.3 [gslice.array.fill] gslice_array fill function</p>
<blockquote>
<p>Change the function declaration</p>
</pre>
</blockquote>
-<p>26.5.8 [template.mask.array] Template class mask_array</p>
+<p>26.6.8 [template.mask.array] Template class mask_array</p>
<blockquote>
<p>In the class template definition for mask_array, replace the member
</pre>
</blockquote>
-<p>26.5.8.3 [mask.array.fill] mask_array fill function</p>
+<p>26.6.8.3 [mask.array.fill] mask_array fill function</p>
<blockquote>
<p>Change the function declaration</p>
</pre>
</blockquote>
-<p>26.5.9 [template.indirect.array] Template class indirect_array</p>
+<p>26.6.9 [template.indirect.array] Template class indirect_array</p>
<blockquote>
<p>In the class template definition for indirect_array, replace the member
</pre>
</blockquote>
-<p>26.5.9.3 [indirect.array.fill] indirect_array fill function</p>
+<p>26.6.9.3 [indirect.array.fill] indirect_array fill function</p>
<blockquote>
<p>Change the function declaration</p>
<hr>
<h3><a name="124"></a>124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*</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#TC">TC</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
+<p><b>Section:</b> 22.4.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In Section 22.2.1.2 [locale.ctype.byname]
+<p>In Section 22.4.1.2 [locale.ctype.byname]
ctype_byname<charT>::do_scan_is() and do_scan_not() are declared
to return a const char* not a const charT*. </p>
<p><b>Proposed resolution:</b></p>
-<p>Change Section 22.2.1.2 [locale.ctype.byname] <tt>do_scan_is()</tt> and
+<p>Change Section 22.4.1.2 [locale.ctype.byname] <tt>do_scan_is()</tt> and
<tt>do_scan_not()</tt> to return a <tt> const
charT*</tt>. </p>
<hr>
<h3><a name="125"></a>125. valarray<T>::operator!() return type is inconsistent</h3>
-<p><b>Section:</b> 26.5.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
+<p><b>Section:</b> 26.6.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.valarray">issues</a> in [template.valarray].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In Section 26.5.2 [template.valarray] valarray<T>::operator!()
+<p>In Section 26.6.2 [template.valarray] valarray<T>::operator!()
is
-declared to return a valarray<T>, but in Section 26.5.2.5
+declared to return a valarray<T>, but in Section 26.6.2.5
[valarray.unary] it is declared to return a valarray<bool>. The
latter appears to be correct. </p>
<p><b>Proposed resolution:</b></p>
-<p>Change in Section 26.5.2 [template.valarray] the declaration of
+<p>Change in Section 26.6.2 [template.valarray] the declaration of
<tt>operator!()</tt> so that the return type is
<tt>valarray<bool></tt>. </p>
<hr>
<h3><a name="126"></a>126. typos in Effects clause of ctype::do_narrow()</h3>
-<p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
+<p><b>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p><p>Typos in 22.2.1.1.2 need to be fixed.</p>
<p><b>Proposed resolution:</b></p>
-<p>In Section 22.2.1.1.2 [locale.ctype.virtuals] change: </p>
+<p>In Section 22.4.1.1.2 [locale.ctype.virtuals] change: </p>
<pre> do_widen(do_narrow(c),0) == c</pre>
<hr>
<h3><a name="127"></a>127. auto_ptr<> conversion 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#TC">TC</a>
- <b>Submitter:</b> Greg Colvin <b>Date:</b> 1999-02-17</p>
+<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#TC1">TC1</a>
+ <b>Submitter:</b> Greg Colvin <b>Opened:</b> 1999-02-17 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#auto.ptr">active issues</a> in [auto.ptr].</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>There are two problems with the current <tt>auto_ptr</tt> wording
in the standard: </p>
<p>Tokyo: The LWG removed the following from the proposed resolution:</p>
- <p>In 20.5.4 [meta.unary], paragraph 2, and 20.5.4.3 [meta.unary.prop],
+ <p>In 20.6.4 [meta.unary], paragraph 2, and 20.6.4.3 [meta.unary.prop],
paragraph 2, make the conversion to auto_ptr_ref const:</p>
<blockquote>
<pre>template<class Y> operator auto_ptr_ref<Y>() const throw();</pre>
<p><b>Proposed resolution:</b></p>
-<p>In 20.5.4 [meta.unary], paragraph 2, move
+<p>In 20.6.4 [meta.unary], paragraph 2, move
the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
-<p>In 20.5.4 [meta.unary], paragraph 2, add
+<p>In 20.6.4 [meta.unary], paragraph 2, add
a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
<blockquote>
<pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</pre>
</blockquote>
-<p>Also add the assignment operator to 20.5.4.3 [meta.unary.prop]: </p>
+<p>Also add the assignment operator to 20.6.4.3 [meta.unary.prop]: </p>
<blockquote>
<pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw()</pre>
<hr>
<h3><a name="129"></a>129. Need error indication from seekp() and seekg()</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted], 27.6.2.5 [ostream.seeks] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
+<p><b>Section:</b> 27.7.1.3 [istream.unformatted], 27.7.2.5 [ostream.seeks] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-02-22 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Currently, the standard does not specify how seekg() and seekp()
indicate failure. They are not required to set failbit, and they can't
<p><b>Proposed resolution:</b></p>
<p>Add to the Effects: clause of seekg() in
-27.6.1.3 [istream.unformatted] and to the Effects: clause of seekp() in
-27.6.2.5 [ostream.seeks]: </p>
+27.7.1.3 [istream.unformatted] and to the Effects: clause of seekp() in
+27.7.2.5 [ostream.seeks]: </p>
<blockquote>
<p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
<hr>
<h3><a name="130"></a>130. Return type of container::erase(iterator) differs for associative containers</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts], 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-02</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts], 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-03-02 <b>Last modified:</b> 2009-05-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#451">451</a></p>
<p><b>Discussion:</b></p>
<p>Table 67 (23.1.1) says that container::erase(iterator) returns an
<p><b>Proposed resolution:</b></p>
<p>
-In 23.1.4 [associative.reqmts], in Table 69 Associative container
+In 23.2.4 [associative.reqmts], in Table 69 Associative container
requirements, change the return type of <tt>a.erase(q)</tt> from
<tt>void</tt> to <tt>iterator</tt>. Change the
assertion/not/pre/post-condition from "erases the element pointed to
</p>
<p>
-In 23.1.4 [associative.reqmts], in Table 69 Associative container
+In 23.2.4 [associative.reqmts], in Table 69 Associative container
requirements, change the return type of <tt>a.erase(q1, q2)</tt>
from <tt>void</tt> to <tt>iterator</tt>. Change the
assertion/not/pre/post-condition from "erases the elements in the
</p>
<p>
-In 23.3.1 [map], in the <tt>map</tt> class synopsis; and
-in 23.3.2 [multimap], in the <tt>multimap</tt> class synopsis; and
-in 23.3.3 [set], in the <tt>set</tt> class synopsis; and
-in 23.3.4 [multiset], in the <tt>multiset</tt> class synopsis:
+In 23.4.1 [map], in the <tt>map</tt> class synopsis; and
+in 23.4.2 [multimap], in the <tt>multimap</tt> class synopsis; and
+in 23.4.3 [set], in the <tt>set</tt> class synopsis; and
+in 23.4.4 [multiset], in the <tt>multiset</tt> class synopsis:
change the signature of the first <tt>erase</tt> overload to
</p>
<pre> iterator erase(iterator position);
<hr>
<h3><a name="132"></a>132. list::resize description uses random access iterators</h3>
-<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>Section:</b> 23.3.4.2 [list.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The description reads:</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 23.2.4.2 [list.capacity] paragraph 1 to:</p>
+<p>Change 23.3.4.2 [list.capacity] paragraph 1 to:</p>
<p>Effects:</p>
<hr>
<h3><a name="133"></a>133. map missing get_allocator()</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#TC">TC</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
+<p><b>Section:</b> 23.4.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p><p>The title says it all.</p>
<p><b>Proposed resolution:</b></p>
-<p>Insert in 23.3.1 [map], paragraph 2,
+<p>Insert in 23.4.1 [map], paragraph 2,
after operator= in the map declaration:</p>
<pre> allocator_type get_allocator() const;</pre>
<hr>
<h3><a name="134"></a>134. vector constructors over specified</h3>
-<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>Section:</b> 23.3.6.1 [vector.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The complexity description says: "It does at most 2N calls to the copy constructor
of T and logN reallocations if they are just input iterators ...".</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 23.2.6.1 [vector.cons], paragraph 1 to:</p>
+<p>Change 23.3.6.1 [vector.cons], paragraph 1 to:</p>
<p>-1- Complexity: The constructor template <class
InputIterator> vector(InputIterator first, InputIterator last)
<hr>
<h3><a name="136"></a>136. seekp, seekg setting wrong streams?</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> Howard Hinnant <b>Date:</b> 1999-03-06</p>
+<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>I may be misunderstanding the intent, but should not seekg set only
the input stream and seekp set only the output stream? The description
<hr>
<h3><a name="137"></a>137. Do use_facet and has_facet look in the global locale?</h3>
-<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-03-17</p>
+<p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-03-17 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>Section 22.1.1 [locale] says:</p>
+<p>Section 22.3.1 [locale] says:</p>
<p>-4- In the call to use_facet<Facet>(loc), the type argument
chooses a facet, making available all members of the named type. If
function has_facet<Facet>(). </p>
<p>This contradicts the specification given in section
-22.1.2 [locale.global.templates]:
+22.3.2 [locale.global.templates]:
<br><br>
template <class Facet> const Facet& use_facet(const
locale& loc); <br>
<hr>
<h3><a name="139"></a>139. Optional sequence operation table description unclear</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-30</p>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-03-30 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The sentence introducing the Optional sequence operation table
(23.1.1 paragraph 12) has two problems:</p>
<hr>
<h3><a name="141"></a>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3>
-<p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Arch Robison <b>Date:</b> 1999-04-28</p>
+<p><b>Section:</b> 21.4.6.4 [string::insert], 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Arch Robison <b>Opened:</b> 1999-04-28 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
say:<br>
<hr>
<h3><a name="142"></a>142. lexicographical_compare complexity wrong</h3>
-<p><b>Section:</b> 25.3.8 [alg.lex.comparison] <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-06-20</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>Section:</b> 25.5.8 [alg.lex.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-06-20 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The lexicographical_compare complexity is specified as:<br>
<br>
<p><b>Proposed resolution:</b></p>
-<p>Change 25.3.8 [alg.lex.comparison] complexity to:</p>
+<p>Change 25.5.8 [alg.lex.comparison] complexity to:</p>
<blockquote><p>
At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
applications of the corresponding comparison.
<hr>
<h3><a name="144"></a>144. Deque constructor complexity wrong </h3>
-<p><b>Section:</b> 23.2.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Herb Sutter <b>Date:</b> 1999-05-09</p>
+<p><b>Section:</b> 23.3.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Herb Sutter <b>Opened:</b> 1999-05-09 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.cons">issues</a> in [deque.cons].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In 23.2.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears
+<p>In 23.3.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears
to have complexity requirements which are incorrect, and which contradict the
complexity requirements for insert(). I suspect that the text in question,
below, was taken from vector:</p>
<p><b>Proposed resolution:</b></p>
-<p>In 23.2.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the
+<p>In 23.3.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the
footnote, with the following text (which also corrects the "abd"
typo):</p>
<blockquote>
<hr>
<h3><a name="146"></a>146. complex<T> Inserter and Extractor need sentries</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#TC">TC</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-05-12</p>
+<p><b>Section:</b> 26.4.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-05-12 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The extractor for complex numbers is specified as: </p>
<p><b>Proposed resolution:</b></p>
-<p>After 26.3.6 [complex.ops] paragraph 14 (operator>>), add a
+<p>After 26.4.6 [complex.ops] paragraph 14 (operator>>), add a
Notes clause:</p>
<blockquote>
<hr>
<h3><a name="147"></a>147. Library Intro refers to global functions that aren't global</h3>
-<p><b>Section:</b> 17.4.4.3 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 1999-06-04</p>
+<p><b>Section:</b> 17.6.4.4 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Lois Goldthwaite <b>Opened:</b> 1999-06-04 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#global.functions">issues</a> in [global.functions].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The library had many global functions until 17.4.1.1 [lib.contents]
paragraph 2 was added: </p>
<hr>
<h3><a name="148"></a>148. Functions in the example facet BoolNames should be const</h3>
-<p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Jeremy Siek <b>Date:</b> 1999-06-03</p>
+<p><b>Section:</b> 22.4.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Jeremy Siek <b>Opened:</b> 1999-06-03 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In 22.2.8 [facets.examples] paragraph 13, the do_truename() and
+<p>In 22.4.8 [facets.examples] paragraph 13, the do_truename() and
do_falsename() functions in the example facet BoolNames should be
const. The functions they are overriding in
numpunct_byname<char> are const. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.8 [facets.examples] paragraph 13, insert "const" in
+<p>In 22.4.8 [facets.examples] paragraph 13, insert "const" in
two places:</p>
<blockquote>
<p><tt>string do_truename() const { return "Oui Oui!"; }<br>
<hr>
<h3><a name="150"></a>150. Find_first_of says integer instead of iterator </h3>
-<p><b>Section:</b> 25.1.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt McClure <b>Date:</b> 1999-06-30</p>
+<p><b>Section:</b> 25.3.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt McClure <b>Opened:</b> 1999-06-30 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Proposed resolution:</b></p>
-<p>Change 25.1.7 [alg.find.first.of] paragraph 2 from:</p>
+<p>Change 25.3.7 [alg.find.first.of] paragraph 2 from:</p>
<blockquote>
<p>Returns: The first iterator i in the range [first1, last1) such
<hr>
<h3><a name="151"></a>151. Can't currently clear() empty container</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-21</p>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Ed Brey <b>Opened:</b> 1999-06-21 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>For both sequences and associative containers, a.clear() has the
semantics of erase(a.begin(),a.end()), which is undefined for an empty
<hr>
<h3><a name="152"></a>152. Typo in <tt>scan_is()</tt> semantics</h3>
-<p><b>Section:</b> 22.2.1.1.2 [locale.ctype.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>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
because there is no function <tt>is()</tt> which only takes a character as
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns
+<p>In 22.4.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns
clause from:</p>
<blockquote>
<p>"... such that <tt>is(*p)</tt>
<hr>
<h3><a name="153"></a>153. Typo in <tt>narrow()</tt> semantics</h3>
-<p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.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> 1999-07-20</p>
+<p><b>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a></p>
<p><b>Discussion:</b></p>
<p>The description of the array version of <tt>narrow()</tt> (in
<p><b>Proposed resolution:</b></p>
-<p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members]
+<p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members]
paragraph 10 from:</p>
<p> Returns: do_widen(low, high, to).</p>
<p> Returns: do_widen(c) or do_widen(low, high, to),
respectively.</p>
-<p>Change 22.2.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:</p>
+<p>Change 22.4.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:</p>
<pre> char narrow(char c, char /*dfault*/) const;
const char* narrow(const char* low, const char* high,
char /*dfault*/, char* to) const;</pre>
<hr>
<h3><a name="154"></a>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt></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#TC">TC</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
+<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The table in paragraph 7 for the length modifier does not list the length
modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length
+<p>In 22.4.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length
Modifier table to say that for <tt>double</tt> a length modifier
<tt>l</tt> is to be used.</p>
<hr>
<h3><a name="155"></a>155. Typo in naming the class defining the class <tt>Init</tt></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#TC">TC</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
+<p><b>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>There are conflicting statements about where the class
-<tt>Init</tt> is defined. According to 27.3 [iostream.objects] paragraph 2
-it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 [ios.base] it is defined as <tt>ios_base::Init</tt>.</p>
+<tt>Init</tt> is defined. According to 27.4 [iostream.objects] paragraph 2
+it is defined as <tt>basic_ios::Init</tt>, according to 27.5.2 [ios.base] it is defined as <tt>ios_base::Init</tt>.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 27.3 [iostream.objects] paragraph 2 from
+<p>Change 27.4 [iostream.objects] paragraph 2 from
"<tt>basic_ios::Init"</tt> to
"<tt>ios_base::Init"</tt>.</p>
<hr>
<h3><a name="156"></a>156. Typo in <tt>imbue()</tt> description</h3>
-<p><b>Section:</b> 27.4.2.3 [ios.base.locales] <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>Section:</b> 27.5.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.locales">issues</a> in [ios.base.locales].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>There is a small discrepancy between the declarations of
-<tt>imbue()</tt>: in 27.4.2 [ios.base] the argument is passed as
-<tt>locale const&</tt> (correct), in 27.4.2.3 [ios.base.locales] it
+<tt>imbue()</tt>: in 27.5.2 [ios.base] the argument is passed as
+<tt>locale const&</tt> (correct), in 27.5.2.3 [ios.base.locales] it
is passed as <tt>locale const</tt> (wrong).</p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.4.2.3 [ios.base.locales] change the <tt>imbue</tt> argument
+<p>In 27.5.2.3 [ios.base.locales] change the <tt>imbue</tt> argument
from "<tt>locale const" to "locale
const&".</tt></p>
<hr>
<h3><a name="158"></a>158. Underspecified semantics for <tt>setbuf()</tt></h3>
-<p><b>Section:</b> 27.5.2.4.2 [streambuf.virt.buffer] <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>Section:</b> 27.6.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.virt.buffer">issues</a> in [streambuf.virt.buffer].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The default behavior of <tt>setbuf()</tt> is described only for the
situation that <tt>gptr() != 0 && gptr() != egptr()</tt>:
<p><b>Proposed resolution:</b></p>
-<p>Change 27.5.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior,
+<p>Change 27.6.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior,
to: "Default behavior: Does nothing. Returns this."</p>
<hr>
<h3><a name="159"></a>159. Strange use of <tt>underflow()</tt></h3>
-<p><b>Section:</b> 27.5.2.4.3 [streambuf.virt.get] <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 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>Section:</b> 27.6.2.4.3 [streambuf.virt.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The description of the meaning of the result of
<tt>showmanyc()</tt> seems to be rather strange: It uses calls to
<p><b>Proposed resolution:</b></p>
-<p>Change 27.5.2.4.3 [streambuf.virt.get] paragraph 1,
+<p>Change 27.6.2.4.3 [streambuf.virt.get] paragraph 1,
<tt>showmanyc()</tt>returns clause, by replacing the word
"supplied" with the words "extracted from the
stream".</p>
<hr>
<h3><a name="160"></a>160. Typo: Use of non-existing function <tt>exception()</tt></h3>
-<p><b>Section:</b> 27.6.1.1 [istream] <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>Section:</b> 27.7.1.1 [istream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream">issues</a> in [istream].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The paragraph 4 refers to the function <tt>exception()</tt> which
is not defined. Probably, the referred function is
<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted], paragraph 1,
-27.6.2.1 [ostream], paragraph 3, and 27.6.2.6.1 [ostream.formatted.reqmts],
+<p>In 27.7.1.1 [istream], 27.7.1.3 [istream.unformatted], paragraph 1,
+27.7.2.1 [ostream], paragraph 3, and 27.7.2.6.1 [ostream.formatted.reqmts],
paragraph 1, change "<tt>exception()" to
"exceptions()"</tt>.</p>
<hr>
<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>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The note in the second paragraph pretends that the first argument
is an object of type <tt>istream_iterator</tt>. This is wrong: It is
<p><b>Proposed resolution:</b></p>
-<p>Change 27.6.1.2.2 [istream.formatted.arithmetic] from:</p>
+<p>Change 27.7.1.2.2 [istream.formatted.arithmetic] from:</p>
<blockquote>
<p>The first argument provides an object of the istream_iterator class...</p>
</blockquote>
<hr>
<h3><a name="164"></a>164. do_put() has apparently unused fill argument</h3>
-<p><b>Section:</b> 22.2.5.3.2 [locale.time.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-07-23</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>Section:</b> 22.4.5.3.2 [locale.time.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In 22.2.5.3.2 [locale.time.put.virtuals] the do_put() function is specified
+<p>In 22.4.5.3.2 [locale.time.put.virtuals] the do_put() function is specified
as taking a fill character as an argument, but the description of the
function does not say whether the character is used at all and, if so,
in which way. The same holds for any format control parameters that
<p><b>Proposed resolution:</b></p>
-<p>Add the following note after 22.2.5.3.2 [locale.time.put.virtuals]
+<p>Add the following note after 22.4.5.3.2 [locale.time.put.virtuals]
paragraph 2:</p>
<blockquote>
<p> [Note: the <tt>fill</tt> argument may be used in the implementation-defined formats, or by derivations. A space character is a reasonable default
<hr>
<h3><a name="165"></a>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3>
-<p><b>Section:</b> 27.6.2.1 [ostream] <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> 1999-07-20</p>
+<p><b>Section:</b> 27.7.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream">issues</a> in [ostream].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
functions falling into one of the groups "formatted output functions"
<hr>
<h3><a name="167"></a>167. Improper use of <tt>traits_type::length()</tt></h3>
-<p><b>Section:</b> 27.6.2.6.4 [ostream.inserters.character] <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> 1999-07-20</p>
+<p><b>Section:</b> 27.7.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.character">issues</a> in [ostream.inserters.character].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 4 states that the length is determined using
<tt>traits::length(s)</tt>. Unfortunately, this function is not
<p><b>Proposed resolution:</b></p>
-<p>Change 27.6.2.6.4 [ostream.inserters.character] paragraph 4 from:</p>
+<p>Change 27.7.2.6.4 [ostream.inserters.character] paragraph 4 from:</p>
<blockquote>
<p>Effects: Behaves like an formatted inserter (as described in
lib.ostream.formatted.reqmts) of out. After a sentry object is
<hr>
<h3><a name="168"></a>168. Typo: formatted vs. unformatted</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#TC">TC</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
+<p><b>Section:</b> 27.7.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The first paragraph begins with a descriptions what has to be done
in <i>formatted</i> output functions. Probably this is a typo and the
<p><b>Proposed resolution:</b></p>
-<p>In 27.6.2.7 [ostream.unformatted] paragraph 1, the first and last
+<p>In 27.7.2.7 [ostream.unformatted] paragraph 1, the first and last
sentences, change the word "formatted" to
"unformatted":</p>
<blockquote>
<hr>
<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>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 8, Notes, of this section seems to mandate an extremely
inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
especially in view of the restriction that <tt>basic_ostream</tt>
-member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 [ostream]): For each character to be inserted, a new buffer
+member functions are not allowed to use <tt>xsputn()</tt> (see 27.7.2.1 [ostream]): For each character to be inserted, a new buffer
is to be created.</p>
<p>Of course, the resolution below requires some handling of
simultaneous input and output since it is no longer possible to update
<p><b>Proposed resolution:</b></p>
-<p>In 27.7.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words
+<p>In 27.8.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words
"at least" as in the following:</p>
<blockquote>
<p>To make a write position available, the function reallocates (or initially
<hr>
<h3><a name="170"></a>170. Inconsistent definition of <tt>traits_type</tt></h3>
-<p><b>Section:</b> 27.7.4 [stringstream] <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 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>Section:</b> 27.8.4 [stringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>The classes <tt>basic_stringstream</tt> (27.7.4 [stringstream]),
-<tt>basic_istringstream</tt> (27.7.2 [istringstream]), and
-<tt>basic_ostringstream</tt> (27.7.3 [ostringstream]) are inconsistent
+<p>The classes <tt>basic_stringstream</tt> (27.8.4 [stringstream]),
+<tt>basic_istringstream</tt> (27.8.2 [istringstream]), and
+<tt>basic_ostringstream</tt> (27.8.3 [ostringstream]) are inconsistent
in their definition of the type <tt>traits_type</tt>: For
<tt>istringstream</tt>, this type is defined, for the other two it is
not. This should be consistent.</p>
<p><b>Proposed resolution:</b></p>
<p><b>Proposed resolution:</b></p> <p>To the declarations of
-<tt>basic_ostringstream</tt> (27.7.3 [ostringstream]) and
-<tt>basic_stringstream</tt> (27.7.4 [stringstream]) add:</p>
+<tt>basic_ostringstream</tt> (27.8.3 [ostringstream]) and
+<tt>basic_stringstream</tt> (27.8.4 [stringstream]) add:</p>
<blockquote>
<pre>typedef traits traits_type;</pre>
</blockquote>
<hr>
<h3><a name="171"></a>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3>
-<p><b>Section:</b> 27.8.1.5 [filebuf.virtuals] <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> 1999-07-20</p>
+<p><b>Section:</b> 27.9.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 [filebuf] paragraph 3, it is stated that a joint input and
+<p>Overridden virtual functions, seekpos()</p> <p>In 27.9.1.1 [filebuf] paragraph 3, it is stated that a joint input and
output position is maintained by <tt>basic_filebuf</tt>. Still, the
description of <tt>seekpos()</tt> seems to talk about different file
positions. In particular, it is unclear (at least to me) what is
<hr>
<h3><a name="172"></a>172. Inconsistent types for <tt>basic_istream::ignore()</tt></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#TC">TC</a>
- <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 1999-07-23</p>
+<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In 27.6.1.1 [istream] the function
+<p>In 27.7.1.1 [istream] the function
<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
-argument. However, in 27.6.1.3 [istream.unformatted]
+argument. However, in 27.7.1.3 [istream.unformatted]
paragraph 23 the first argument is of type <tt>int.</tt></p>
<p>As far as I can see this is not really a contradiction because
<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.3 [istream.unformatted] paragraph 23 and 24, change both uses
+<p>In 27.7.1.3 [istream.unformatted] paragraph 23 and 24, change both uses
of <tt>int</tt> in the description of <tt>ignore()</tt> to
<tt>streamsize</tt>.</p>
<hr>
<h3><a name="173"></a>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt></h3>
-<p><b>Section:</b> 27.8.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 1999-07-23</p>
+<p><b>Section:</b> 27.9.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In 27.8.1.1 [filebuf] the function <tt>setbuf()</tt> gets an
+In 27.9.1.1 [filebuf] the function <tt>setbuf()</tt> gets an
object of type <tt>streamsize</tt> as second argument. However, in
-27.8.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type
+27.9.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type
<tt>int</tt>.
</p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.8.1.5 [filebuf.virtuals] paragraph 9, change all uses of
+<p>In 27.9.1.5 [filebuf.virtuals] paragraph 9, change all uses of
<tt>int</tt> in the description of <tt>setbuf()</tt> to
<tt>streamsize</tt>.</p>
<hr>
<h3><a name="174"></a>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt></h3>
-<p><b>Section:</b> D.6 [depr.ios.members] <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-23</p>
+<p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>According to paragraph 1 of this section, <tt>streampos</tt> is the
type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
<hr>
<h3><a name="175"></a>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3>
-<p><b>Section:</b> D.6 [depr.ios.members] <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-23</p>
+<p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>According to paragraph 8 of this section, the methods
<tt>basic_streambuf::pubseekpos()</tt>,
<hr>
<h3><a name="176"></a>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3>
-<p><b>Section:</b> D.6 [depr.ios.members] <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-23</p>
+<p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The "overload" for the function <tt>exceptions()</tt> in
paragraph 8 gives the impression that there is another function of
<hr>
<h3><a name="179"></a>179. Comparison of const_iterators to iterators doesn't work</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> Judy Ward <b>Date:</b> 1998-07-02</p>
+<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-07-02 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Currently the following will not compile on two well-known standard
library implementations:</p>
<p><b>Proposed resolution:</b></p>
-<p>Insert this paragraph after 23.1 [container.requirements] paragraph 7:</p>
+<p>Insert this paragraph after 23.2 [container.requirements] paragraph 7:</p>
<blockquote>
<p>In the expressions</p>
<pre> i == j
<hr>
+<h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3>
+<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 1999-07-01 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+This was a fix that was intended for all standard library containers,
+and has been done for other containers, but string was missed.
+</p>
+<p>
+The wording updated.
+</p>
+<p>
+We did not make the change in <tt>replace</tt>, because this change would affect
+the implementation because the string may be written into. This is an
+issue that should be taken up by concepts.
+</p>
+<p>
+We note that the supplied wording addresses the initializer list provided in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2679.pdf">N2679</a>.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Update the following signature in the <tt>basic_string</tt> class template definition in
+21.4 [basic.string], p5:
+</p>
+<blockquote><pre>namespace std {
+ template<class charT, class traits = char_traits<charT>,
+ class Allocator = allocator<charT> >
+ class basic_string {
+
+ ...
+
+ iterator insert(<ins>const_</ins>iterator p, charT c);
+ void insert(<ins>const_</ins>iterator p, size_type n, charT c);
+ template<class InputIterator>
+ void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
+ void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list<charT>);
+
+ ...
+
+ iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
+ iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
+
+ ...
+
+ };
+}
+</pre></blockquote>
+
+<p>
+Update the following signatures in 21.4.6.4 [string::insert]:
+</p>
+
+<blockquote><pre>iterator insert(<ins>const_</ins>iterator p, charT c);
+void insert(<ins>const_</ins>iterator p, size_type n, charT c);
+template<class InputIterator>
+ void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
+void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list<charT>);
+</pre></blockquote>
+
+<p>
+Update the following signatures in 21.4.6.5 [string::erase]:
+</p>
+
+<blockquote><pre>iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
+iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
+</pre></blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>The issue was discussed at length. It was generally agreed that 1)
+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="181"></a>181. make_pair() unintended behavior</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#TC">TC</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-03</p>
+<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-03 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The claim has surfaced in Usenet that expressions such as<br>
<br>
<p><b>Proposed resolution:</b></p>
-<p>In 20.2 [utility], paragraph 1 change the following
+<p>In 20.3 [utility], paragraph 1 change the following
declaration of make_pair():</p>
<blockquote>
<pre>template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);</pre>
<blockquote>
<pre>template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);</pre>
</blockquote>
-<p> In 20.2.3 [pairs] paragraph 7 and the line before, change:</p>
+<p> In 20.3.3 [pairs] paragraph 7 and the line before, change:</p>
<blockquote>
<pre>template <class T1, class T2>
pair<T1, T2> make_pair(const T1& x, const T2& y);</pre>
<hr>
<h3><a name="182"></a>182. Ambiguous references to size_t</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Al Stevens <b>Date:</b> 1999-08-15</p>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Al Stevens <b>Opened:</b> 1999-08-15 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</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.5 [replacement.functions] paragraph 2:</p>
+example, 17.6.3.6 [replacement.functions] paragraph 2:</p>
<blockquote>
<pre> operator new(size_t)
operator new(size_t, const std::nothrow_t&)
<p><b>Proposed resolution:</b></p>
-<p> In 17.4.3.5 [replacement.functions] paragraph 2: replace:</p>
+<p> In 17.6.3.6 [replacement.functions] paragraph 2: replace:</p>
<blockquote>
<p><tt> - operator new(size_t)<br>
- operator new(size_t, const std::nothrow_t&)<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.2.4 [extern.types],</p>
+ptrdiff_t meant anyway because, according to 17.6.3.3.4 [extern.types],</p>
<blockquote><p>
For each type T from the Standard C library, the types ::T and std::T
<hr>
<h3><a name="183"></a>183. I/O stream manipulators don't work for wide character streams</h3>
-<p><b>Section:</b> 27.6.3 [std.manip] <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> 1999-07-07</p>
+<p><b>Section:</b> 27.7.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 1999-07-07 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#std.manip">issues</a> in [std.manip].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>27.6.3 [std.manip] paragraph 3 says (clause numbering added for
+<p>27.7.3 [std.manip] paragraph 3 says (clause numbering added for
exposition):</p>
<blockquote>
<p>Returns: An object s of unspecified type such that if [1] out is an (instance
<p><b>Proposed resolution:</b></p>
-<p>Replace section 27.6.3 [std.manip] except paragraph 1 with the
+<p>Replace section 27.7.3 [std.manip] except paragraph 1 with the
following:</p>
<blockquote>
<p>2- The type designated smanip in each of the following function
<hr>
<h3><a name="184"></a>184. numeric_limits<bool> wording problems</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> Gabriel Dos Reis <b>Date:</b> 1999-07-21</p>
+<p><b>Section:</b> 18.3.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 1999-07-21 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>bools are defined by the standard to be of integer types, as per
3.9.1 [basic.fundamental] paragraph 7. However "integer types"
<p><b>Proposed resolution:</b></p>
-<p>Append to the end of 18.2.1.5 [numeric.special]:</p>
+<p>Append to the end of 18.3.1.5 [numeric.special]:</p>
<blockquote>
<p>The specialization for bool shall be provided as follows:</p>
<pre> namespace std {
<hr>
<h3><a name="185"></a>185. Questionable use of term "inline"</h3>
-<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> UK Panel <b>Date:</b> 1999-07-26</p>
+<p><b>Section:</b> 20.7 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> UK Panel <b>Opened:</b> 1999-07-26 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>Paragraph 4 of 20.6 [function.objects] says:</p>
+<p>Paragraph 4 of 20.7 [function.objects] says:</p>
<blockquote>
<p> [Example: To negate every element of a: transform(a.begin(), a.end(),
a.begin(), negate<double>()); The corresponding functions will inline
<p><b>Proposed resolution:</b></p>
-<p>In 20.6 [function.objects] paragraph 1, remove the sentence:</p>
+<p>In 20.7 [function.objects] paragraph 1, remove the sentence:</p>
<blockquote>
<p>They are important for the effective use of the library.</p>
</blockquote>
-<p>Remove 20.6 [function.objects] paragraph 2, which reads:</p>
+<p>Remove 20.7 [function.objects] paragraph 2, which reads:</p>
<blockquote>
<p> Using function objects together with function templates
increases the expressive power of the library as well as making the
resulting code much more efficient.</p>
</blockquote>
-<p>In 20.6 [function.objects] paragraph 4, remove the sentence:</p>
+<p>In 20.7 [function.objects] paragraph 4, remove the sentence:</p>
<blockquote>
<p>The corresponding functions will inline the addition and the
negation.</p>
<hr>
<h3><a name="186"></a>186. bitset::set() second parameter should be bool</h3>
-<p><b>Section:</b> 23.3.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Darin Adler <b>Date:</b> 1999-08-13</p>
+<p><b>Section:</b> 20.3.6.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Darin Adler <b>Opened:</b> 1999-08-13 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In section 23.3.5.2 [bitset.members], paragraph 13 defines the
+<p>In section 20.3.6.2 [bitset.members], paragraph 13 defines the
bitset::set operation to take a second parameter of type int. The
function tests whether this value is non-zero to determine whether to
set the bit to true or false. The type of this second parameter should
<p><b>Proposed resolution:</b></p>
-<p>In 23.3.5 [template.bitset] Para 1 Replace:</p>
+<p>In 20.3.6 [template.bitset] Para 1 Replace:</p>
<blockquote>
<pre>bitset<N>& set(size_t pos, int val = true ); </pre>
</blockquote>
<blockquote>
<pre>bitset<N>& set(size_t pos, bool val = true );</pre>
</blockquote>
-<p>In 23.3.5.2 [bitset.members] Para 12(.5) Replace:</p>
+<p>In 20.3.6.2 [bitset.members] Para 12(.5) Replace:</p>
<blockquote>
<pre>bitset<N>& set(size_t pos, int val = 1 );</pre>
</blockquote>
<hr>
<h3><a name="187"></a>187. iter_swap underspecified</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#WP">WP</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-14</p>
+<p><b>Section:</b> 25.4.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-14 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The description of iter_swap in 25.2.2 paragraph 7,says that it
``exchanges the values'' of the objects to which two iterators
<hr>
<h3><a name="189"></a>189. setprecision() not specified correctly</h3>
-<p><b>Section:</b> 27.4.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-25</p>
+<p><b>Section:</b> 27.5.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-25 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fmtflags.state">issues</a> in [fmtflags.state].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
and includes a parenthetical note saying that it is the number of
<p><b>Proposed resolution:</b></p>
-<p>Remove from 27.4.2.2 [fmtflags.state], paragraph 9, the text
+<p>Remove from 27.5.2.2 [fmtflags.state], paragraph 9, the text
"(number of digits after the decimal point)".</p>
<hr>
<h3><a name="193"></a>193. Heap operations description incorrect</h3>
-<p><b>Section:</b> 25.3.6 [alg.heap.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Markus Mauhart <b>Date:</b> 1999-09-24</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>Section:</b> 25.5.6 [alg.heap.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 1999-09-24 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a></p>
<p><b>Discussion:</b></p>
<p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
<p><b>Proposed resolution:</b></p>
-<p>Change 25.3.6 [alg.heap.operations] property (1) from:</p>
+<p>Change 25.5.6 [alg.heap.operations] property (1) from:</p>
<blockquote>
<p>(1) *a is the largest element</p>
</blockquote>
<hr>
<h3><a name="195"></a>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3>
-<p><b>Section:</b> 27.6.1.1.3 [istream::sentry] <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> 1999-10-13</p>
+<p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-10-13 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Suppose that <tt>is.flags() & ios_base::skipws</tt> is nonzero.
What should <tt>basic_istream<>::sentry</tt>'s constructor do if it
should set failbit. Should it set eofbit as well? The standard
doesn't seem to answer that question.</p>
-<p>On the one hand, nothing in 27.6.1.1.3 [istream::sentry] says that
+<p>On the one hand, nothing in 27.7.1.1.3 [istream::sentry] says that
<tt>basic_istream<>::sentry</tt> should ever set eofbit. On the
-other hand, 27.6.1.1 [istream] paragraph 4 says that if
+other hand, 27.7.1.1 [istream] paragraph 4 says that if
extraction from a <tt>streambuf</tt> "returns
<tt>traits::eof()</tt>, then the input function, except as explicitly
noted otherwise, completes its actions and does
<hr>
<h3><a name="198"></a>198. Validity of pointers and references unspecified after iterator destruction</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#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 1999-11-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1999-11-03 <b>Last modified:</b> 2008-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Is a pointer or reference obtained from an iterator still valid after
<p>The standard itself assumes that pointers and references obtained
from an iterator are still valid after iterator destruction or
-change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 [reverse.iter.conv], which returns a reference, defines
+change. The definition of reverse_iterator::operator*(), 24.5.1.2.3 [reverse.iter.conv], which returns a reference, defines
effects:</p>
<blockquote>
<pre>Iterator tmp = current;
return *--tmp;</pre>
</blockquote>
-<p>The definition of reverse_iterator::operator->(), 24.4.1.3.4
+<p>The definition of reverse_iterator::operator->(), 24.5.1.2.4
[reverse.iter.op.star], which returns a pointer, defines effects:</p>
<blockquote>
<pre>return &(operator*());</pre>
<p><b>Proposed resolution:</b></p>
-<p>Add a new paragraph to 24.1 [iterator.requirements]:</p>
+<p>Add a new paragraph to 24.2 [iterator.concepts]:</p>
<blockquote><p>
Destruction of an iterator may invalidate pointers and references
previously obtained from that iterator.
</p></blockquote>
-<p>Replace paragraph 1 of 24.4.1.3.3 [reverse.iter.conv] with:</p>
+<p>Replace paragraph 1 of 24.5.1.2.3 [reverse.iter.conv] with:</p>
<blockquote>
<p><b>Effects:</b></p>
[<i>Note:</i> This operation must use an auxiliary member variable,
rather than a temporary variable, to avoid returning a reference that
persists beyond the lifetime of its associated iterator. (See
-24.1 [iterator.requirements].) The name of this member variable is shown for
+24.2 [iterator.concepts].) The name of this member variable is shown for
exposition only. <i>--end note</i>]
</p>
</blockquote>
assumes its underlying iterator has persistent pointers and
references. Andy Koenig pointed out that it is possible to rewrite
reverse_iterator so that it no longer makes such an assupmption.
-However, this issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>. If we
+However, this issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>. If we
decide it is intentional that <tt>p[n]</tt> may return by value
instead of reference when <tt>p</tt> is a Random Access Iterator,
other changes in reverse_iterator will be necessary.]</i></p>
<hr>
<h3><a name="199"></a>199. What does <tt>allocate(0)</tt> return?</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#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-11-19</p>
+<p><b>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-11-19 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Suppose that <tt>A</tt> is a class that conforms to the
<hr>
<h3><a name="200"></a>200. Forward iterator requirements don't allow constant iterators</h3>
-<p><b>Section:</b> 24.1.3 [forward.iterators] <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> 1999-11-19</p>
+<p><b>Section:</b> 24.2.4 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-11-19 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In table 74, the return type of the expression <tt>*a</tt> is given
<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. Note
-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 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a> has already been declared NAD Future for
that very reason.]</i></p>
<hr>
<h3><a name="201"></a>201. Numeric limits terminology wrong</h3>
-<p><b>Section:</b> 18.2.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Stephen Cleary <b>Date:</b> 1999-12-21</p>
+<p><b>Section:</b> 18.3.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Stephen Cleary <b>Opened:</b> 1999-12-21 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In some places in this section, the terms "fundamental types" and
<p><b>Proposed resolution:</b></p>
<p>
-Change 18.2 [support.limits] to:
+Change 18.3 [support.limits] to:
</p>
<blockquote>
</blockquote>
<p>
-Change 18.2.1 [limits] to:
+Change 18.3.1 [limits] to:
</p>
<blockquote>
</blockquote>
<p>
-Change 18.2.1.1 [numeric.limits] to:
+Change 18.3.1.1 [numeric.limits] to:
</p>
<blockquote>
<hr>
<h3><a name="202"></a>202. unique() effects unclear when predicate not an equivalence relation</h3>
-<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-01-13</p>
+<p><b>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-01-13 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
What should unique() do if you give it a predicate that is not an
<p><b>Proposed resolution:</b></p>
-<p>Change 25.2.9 [alg.unique] paragraph 1 to:</p>
+<p>Change 25.4.9 [alg.unique] paragraph 1 to:</p>
<blockquote><p>
For a nonempty range, eliminates all but the first element from every
consecutive group of equivalent elements referred to by the iterator
<p><b>Rationale:</b></p>
<p>The LWG also considered an alternative resolution: change
-25.2.9 [alg.unique] paragraph 1 to:</p>
+25.4.9 [alg.unique] paragraph 1 to:</p>
<blockquote><p>
For a nonempty range, eliminates all but the first element from every
<hr>
<h3><a name="206"></a>206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced</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#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-08-29</p>
+<p><b>Section:</b> 18.6.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-08-29 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>As specified, the implementation of the nothrow version of operator
new does not necessarily call the ordinary operator new, but may
<hr>
<h3><a name="208"></a>208. Unnecessary restriction on past-the-end iterators</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#TC">TC</a>
- <b>Submitter:</b> Stephen Cleary <b>Date:</b> 2000-02-02</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#TC">TC</a> status.</p>
+<p><b>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Stephen Cleary <b>Opened:</b> 2000-02-02 <b>Last modified:</b> 2008-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
past-the-end values are always non-singular."</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 24.1 [iterator.requirements] paragraph 5, the last sentence, from:</p>
+<p>Change 24.2 [iterator.concepts] paragraph 5, the last sentence, from:</p>
<blockquote>
<p>Dereferenceable and past-the-end values are always non-singular.</p>
</blockquote>
<hr>
<h3><a name="209"></a>209. basic_string declarations 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#TC">TC</a>
- <b>Submitter:</b> Igor Stauder <b>Date:</b> 2000-02-11</p>
+<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Igor Stauder <b>Opened:</b> 2000-02-11 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In Section 21.3 [basic.string] the basic_string member function
+<p>In Section 21.4 [basic.string] the basic_string member function
declarations use a consistent style except for the following functions:</p>
<blockquote>
<pre>void push_back(const charT);
<p><b>Proposed resolution:</b></p>
-<p>In Section 21.3 [basic.string] change the basic_string member
+<p>In Section 21.4 [basic.string] change the basic_string member
function declarations push_back, assign, and swap to:</p>
<blockquote>
<pre>void push_back(charT c);
<hr>
<h3><a name="210"></a>210. distance first and last confused</h3>
-<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-02-15</p>
+<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Lisa Lippincott <b>Opened:</b> 2000-02-15 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In paragraph 9 of section 25 [algorithms], it is written:</p>
<blockquote>
<hr>
<h3><a name="211"></a>211. operator>>(istream&, string&) doesn't set failbit</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#TC">TC</a>
- <b>Submitter:</b> Scott Snyder <b>Date:</b> 2000-02-04</p>
+<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Scott Snyder <b>Opened:</b> 2000-02-04 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The description of the stream extraction operator for std::string (section
21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
</blockquote>
<p>(which tests failbit) is not required to terminate at EOF.</p>
<p>Furthermore, this is inconsistent with other extraction operators,
-which do include this requirement. (See sections 27.6.1.2 [istream.formatted] and 27.6.1.3 [istream.unformatted]), where this
+which do include this requirement. (See sections 27.7.1.2 [istream.formatted] and 27.7.1.3 [istream.unformatted]), where this
requirement is present, either explicitly or implicitly, for the
extraction operators. It is also present explicitly in the description
-of getline (istream&, string&, charT) in section 21.3.8.9 [string.io] paragraph 8.)</p>
+of getline (istream&, string&, charT) in section 21.4.8.9 [string.io] paragraph 8.)</p>
<p><b>Proposed resolution:</b></p>
-<p>Insert new paragraph after paragraph 2 in section 21.3.8.9 [string.io]:</p>
+<p>Insert new paragraph after paragraph 2 in section 21.4.8.9 [string.io]:</p>
<blockquote>
<p>If the function extracts no characters, it calls
<hr>
<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>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 2000-02-26 <b>Last modified:</b> 2008-09-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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The standard doesn't specify what min_element() and max_element() shall
return if the range is empty (first equals last). The usual implementations
<p><b>Proposed resolution:</b></p>
-<p>In 25.3.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and
+<p>In 25.5.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and
9, append: Returns last if first==last.</p>
<hr>
<h3><a name="214"></a>214. set::find() missing const overload</h3>
-<p><b>Section:</b> 23.3.3 [set], 23.3.4 [multiset] <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> 2000-02-28</p>
+<p><b>Section:</b> 23.4.3 [set], 23.4.4 [multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-02-28 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#set">issues</a> in [set].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#450">450</a></p>
<p><b>Discussion:</b></p>
<p>The specification for the associative container requirements in
<p><b>Proposed resolution:</b></p>
<p>Change the prototypes for find(), lower_bound(), upper_bound(), and
-equal_range() in section 23.3.3 [set] and section 23.3.4 [multiset] to each have two overloads:</p>
+equal_range() in section 23.4.3 [set] and section 23.4.4 [multiset] to each have two overloads:</p>
<blockquote>
<pre>iterator find(const key_type & x);
const_iterator find(const key_type & x) const;</pre>
<hr>
<h3><a name="217"></a>217. Facets example (Classifying Japanese characters) contains errors</h3>
-<p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-02-29</p>
+<p><b>Section:</b> 22.4.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-02-29 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
<p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
<hr>
<h3><a name="220"></a>220. ~ios_base() usage valid?</h3>
-<p><b>Section:</b> 27.4.2.7 [ios.base.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 2000-03-13</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>Section:</b> 27.5.2.7 [ios.base.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Opened:</b> 2000-03-13 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
paragraph 2:</p>
<hr>
<h3><a name="221"></a>221. num_get<>::do_get stage 2 processing broken</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#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-03-14</p>
+<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-03-14 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Stage 2 processing of numeric conversion is broken.</p>
<hr>
<h3><a name="222"></a>222. Are throw clauses necessary if a throw is already implied by the effects clause?</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#TC">TC</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-03-17</p>
+<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-03-17 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
<blockquote>
</blockquote>
<p>and the constructor that's implicitly called by the above is
defined to throw an out-of-range exception if pos > str.size(). See
-section 21.3.1 [string.require] paragraph 4.</p>
+section 21.4.1 [string.require] paragraph 4.</p>
<p>On the other hand, the compare function descriptions themselves don't have
"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
<p><b>Proposed resolution:</b></p>
-<p>In 17.3.1.3 [structure.specifications] paragraph 3, the footnote 148 attached to
+<p>In 17.5.1.4 [structure.specifications] paragraph 3, the footnote 148 attached to
the sentence "Descriptions of function semantics contain the
following elements (as appropriate):", insert the word
"further" so that the foot note reads:</p>
<hr>
<h3><a name="223"></a>223. reverse algorithm should use iter_swap rather than swap</h3>
-<p><b>Section:</b> 25.2.10 [alg.reverse] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-03-21</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>Section:</b> 25.4.10 [alg.reverse] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-03-21 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
<p><b>Proposed resolution:</b></p>
-<p>In 25.2.10 [alg.reverse], replace:</p>
+<p>In 25.4.10 [alg.reverse], replace:</p>
<blockquote><p>
Effects: For each non-negative integer i <= (last - first)/2,
applies swap to all pairs of iterators first + i, (last - i) - 1.
<hr>
<h3><a name="224"></a>224. clear() complexity for associative containers refers to undefined N</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Ed Brey <b>Date:</b> 2000-03-23</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Ed Brey <b>Opened:</b> 2000-03-23 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In the associative container requirements table in 23.1.2 paragraph 7,
a.clear() has complexity "log(size()) + N". However, the meaning of N
<hr>
<h3><a name="225"></a>225. std:: algorithms use of other unqualified algorithms</h3>
-<p><b>Section:</b> 17.4.4.3 [global.functions] <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>Section:</b> 17.6.4.4 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-01 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#global.functions">issues</a> in [global.functions].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
user namespaces might be found through Koenig lookup?</p>
<p><b>Proposed resolution:</b></p>
<p>Add a paragraph and a note at the end of
-17.4.4.3 [global.functions]:</p>
+17.6.4.4 [global.functions]:</p>
<blockquote>
<p>Unless otherwise specified, no global or non-member function in the
<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.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>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-01 <b>Last modified:</b> 2008-09-26</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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The issues are: </p>
<p>1. How can a 3rd party library implementor (lib1) write a version of a standard
(such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
to that concept. The Swappable concept will make it clear that
these algorithms use unqualified lookup for the calls
- to <tt>swap</tt>. Also, in 26.5.3.3 [valarray.transcend] paragraph 1,
+ to <tt>swap</tt>. Also, in 26.6.3.3 [valarray.transcend] paragraph 1,
state that the valarray transcendentals use unqualified lookup.</p>
<hr>
<h3><a name="227"></a>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</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#TC">TC</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-09</p>
+<p><b>Section:</b> 25.4.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-09 <b>Last modified:</b> 2008-09-26</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#TC">TC</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>25.2.2 reads:</p>
<blockquote>
<hr>
<h3><a name="228"></a>228. Incorrect specification of "..._byname" facets</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#WP">WP</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-20</p>
+<p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-20 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>The sections 22.2.1.2 [locale.ctype.byname], 22.2.1.5
+<p>The sections 22.4.1.2 [locale.ctype.byname], 22.4.1.5
[locale.codecvt.byname],
-sref ref="22.2.1.6", 22.2.3.2 [locale.numpunct.byname], 22.2.4.2
-[locale.collate.byname], 22.2.5.4 [locale.time.put.byname], 22.2.6.4
-[locale.moneypunct.byname], and 22.2.7.2 [locale.messages.byname]
+sref ref="22.2.1.6", 22.4.3.2 [locale.numpunct.byname], 22.4.4.2
+[locale.collate.byname], 22.4.5.4 [locale.time.put.byname], 22.4.6.4
+[locale.moneypunct.byname], and 22.4.7.2 [locale.messages.byname]
overspecify the
definitions of the "..._byname" classes by listing a bunch
of virtual functions. At the same time, no semantics of these
~messages_byname(); // virtual
};
}</pre>
-<p>Remove section 22.2.1.4 [locale.codecvt] completely (because in
+<p>Remove section 22.4.1.4 [locale.codecvt] completely (because in
this case only those members are defined to be virtual which are
defined to be virtual in 'ctype<cT>'.)</p>
<p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
-the LWG to solve the underlying problems raised by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>.]</i></p>
+the LWG to solve the underlying problems raised by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#138">138</a>.]</i></p>
<p><i>[Copenhagen: proposed resolution was revised slightly, to remove
<hr>
<h3><a name="229"></a>229. Unqualified references of other library entities</h3>
-<p><b>Section:</b> 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 2000-04-19</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>Section:</b> 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2000-04-19 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#contents">active issues</a> in [contents].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#contents">issues</a> in [contents].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Throughout the library chapters, the descriptions of library entities refer
to other library entities without necessarily qualifying the names.</p>
<hr>
<h3><a name="230"></a>230. Assignable specified without also specifying CopyConstructible</h3>
-<p><b>Section:</b> 17 [library] <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> 2000-04-26</p>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2000-04-26 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> identified an instance (std::swap) where
Assignable was specified without also specifying
<p>There are a number of places (see proposed resolution below) where
Assignable is specified without also specifying
CopyConstructible. There are also several cases where both are
-specified. For example, 26.4.1 [rand.req].</p>
+specified. For example, X [rand.req].</p>
<p><b>Proposed resolution:</b></p>
-<p>In 23.1 [container.requirements] table 65 for value_type:
+<p>In 23.2 [container.requirements] table 65 for value_type:
change "T is Assignable" to "T is CopyConstructible and
Assignable"
</p>
-<p>In 23.1.4 [associative.reqmts] table 69 X::key_type; change
+<p>In 23.2.4 [associative.reqmts] table 69 X::key_type; change
"Key is Assignable" to "Key is
CopyConstructible and Assignable"<br>
</p>
-<p>In 24.1.2 [output.iterators] paragraph 1, change:
+<p>In 24.2.3 [output.iterators] paragraph 1, change:
</p>
<blockquote>
<p> A class or a built-in type X satisfies the requirements of an
</blockquote>
<p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
-the LWG. He asks that the 25.2.5 [alg.replace] and 25.2.6 [alg.fill] changes be studied carefully, as it is not clear that
+the LWG. He asks that the 25.4.5 [alg.replace] and 25.4.6 [alg.fill] changes be studied carefully, as it is not clear that
CopyConstructible is really a requirement and may be
overspecification.]</i></p>
<hr>
<h3><a name="231"></a>231. Precision in iostream?</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#WP">WP</a>
- <b>Submitter:</b> James Kanze, Stephen Clamage <b>Date:</b> 2000-04-25</p>
+<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> James Kanze, Stephen Clamage <b>Opened:</b> 2000-04-25 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>What is the following program supposed to output?</p>
<pre>#include <iostream>
<p><b>Proposed resolution:</b></p>
<p>
-Replace 22.2.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following
+Replace 22.4.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following
sentence:
</p>
<blockquote><p>
<hr>
<h3><a name="232"></a>232. "depends" poorly defined in 17.4.3.1</h3>
-<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>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2000-04-18 <b>Last modified:</b> 2008-09-26</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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
specializations of standard templates to those that "depend on a
<hr>
<h3><a name="233"></a>233. Insertion hints in associative containers</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-04-30</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-04-30 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#192">192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#246">246</a></p>
<p><b>Discussion:</b></p>
<p>
<p>
Change the indicated rows of the "Associative container requirements" Table in
-23.1.4 [associative.reqmts] to:
+23.2.4 [associative.reqmts] to:
</p>
<p></p><center>
<hr>
<h3><a name="234"></a>234. Typos in allocator definition</h3>
-<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
+<p><b>Section:</b> 20.8.6.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
<tt>destruct()</tt> are described as returns but the functions actually
<hr>
<h3><a name="235"></a>235. No specification of default ctor for reverse_iterator</h3>
-<p><b>Section:</b> 24.4.1.1 [reverse.iterator] <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 issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 24.5.1.1 [reverse.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The declaration of <tt>reverse_iterator</tt> lists a default
constructor. However, no specification is given what this constructor
<p><b>Proposed resolution:</b></p>
- <p>In section 24.4.1.3.1 [reverse.iter.cons] add the following
+ <p>In section 24.5.1.2.1 [reverse.iter.cons] add the following
paragraph:</p>
<blockquote>
<p><tt>reverse_iterator()</tt></p>
<hr>
<h3><a name="237"></a>237. Undefined expression in complexity specification</h3>
-<p><b>Section:</b> 23.2.2.1 [deque.cons] <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>Section:</b> 23.3.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.cons">issues</a> in [deque.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The complexity specification in paragraph 6 says that the complexity
is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
<hr>
<h3><a name="238"></a>238. Contradictory results of stringbuf initialization.</h3>
-<p><b>Section:</b> 27.7.1.1 [stringbuf.cons] <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-05-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>Section:</b> 27.8.1.1 [stringbuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-05-11 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
<hr>
<h3><a name="239"></a>239. Complexity of unique() and/or unique_copy incorrect</h3>
-<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
+<p><b>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The complexity of unique and unique_copy are inconsistent with each
other and inconsistent with the implementations. The standard
<p><b>Proposed resolution:</b></p>
-<p>Change both complexity sections in 25.2.9 [alg.unique] to:</p>
+<p>Change both complexity sections in 25.4.9 [alg.unique] to:</p>
<blockquote><p>Complexity: For nonempty ranges, exactly last - first - 1
applications of the corresponding predicate.</p></blockquote>
<hr>
<h3><a name="240"></a>240. Complexity of adjacent_find() is meaningless</h3>
-<p><b>Section:</b> 25.1.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 25.3.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.adjacent.find">issues</a> in [alg.adjacent.find].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The complexity section of adjacent_find is defective:</p>
<p><b>Proposed resolution:</b></p>
-<p>Change the complexity section in 25.1.8 [alg.adjacent.find] to:</p>
+<p>Change the complexity section in 25.3.8 [alg.adjacent.find] to:</p>
<blockquote><p>
For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
(<i>last</i> - <i>first</i>) - 1)</tt> applications of the
<hr>
<h3><a name="241"></a>241. Does unique_copy() require CopyConstructible and Assignable?</h3>
-<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
+<p><b>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Some popular implementations of unique_copy() create temporary
specify any additional requirements that they impose on any of the
types used by the algorithm. An example of an algorithm that creates
temporary copies and correctly specifies the additional requirements
-is accumulate(), 26.4.1 [rand.req].</p>
+is accumulate(), X [rand.req].</p>
<p>Since the specifications of unique() and unique_copy() do not
require CopyConstructible and Assignable of the InputIterator's value
<hr>
<h3><a name="242"></a>242. Side effects of function objects</h3>
-<p><b>Section:</b> 25.2.4 [alg.transform], 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> Angelika Langer <b>Date:</b> 2000-05-15</p>
+<p><b>Section:</b> 25.4.4 [alg.transform], 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.transform">issues</a> in [alg.transform].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The algorithms transform(), accumulate(), inner_product(),
partial_sum(), and adjacent_difference() require that the function
<hr>
<h3><a name="243"></a>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</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> 2000-05-15</p>
+<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>basic_istream<>::get(), and basic_istream<>::getline(),
are unclear with respect to the behavior and side-effects of the named
<hr>
<h3><a name="247"></a>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3>
-<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>Section:</b> 23.3.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Lisa Lippincott <b>Opened:</b> 2000-06-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>Paragraph 2 of 23.2.6.4 [vector.modifiers] describes the complexity
+<p>Paragraph 2 of 23.3.6.4 [vector.modifiers] describes the complexity
of <tt>vector::insert</tt>:</p>
<blockquote><p>
<p>I looked to see if <tt>deque</tt> had a similar problem, and was
surprised to find that <tt>deque</tt> places no requirement on the
-complexity of inserting multiple elements (23.2.2.3 [deque.modifiers],
+complexity of inserting multiple elements (23.3.2.3 [deque.modifiers],
paragraph 3):</p>
<blockquote><p>
<p><b>Proposed resolution:</b></p>
-<p>Change Paragraph 2 of 23.2.6.4 [vector.modifiers] to</p>
+<p>Change Paragraph 2 of 23.3.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.
<tt>rotate</tt>.]</i></p>
-<p>Change 23.2.2.3 [deque.modifiers], paragraph 3, to:</p>
+<p>Change 23.3.2.3 [deque.modifiers], paragraph 3, to:</p>
<blockquote><p>
Complexity: The complexity is linear in the number of elements
<hr>
<h3><a name="248"></a>248. time_get fails to set eofbit</h3>
-<p><b>Section:</b> 22.2.5 [category.time] <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-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>Section:</b> 22.4.5 [category.time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-06-22 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>There is no requirement that any of time_get member functions set
ios::eofbit when they reach the end iterator while parsing their input.
<hr>
<h3><a name="250"></a>250. splicing invalidates iterators</h3>
-<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>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Brian Parker <b>Opened:</b> 2000-07-14 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Section 23.2.4.4 [list.ops] states that
+Section 23.3.4.4 [list.ops] states that
</p>
<pre> void splice(iterator position, list<T, Allocator>& x);
</pre>
<p><b>Proposed resolution:</b></p>
-<p>Add a footnote to 23.2.4.4 [list.ops], paragraph 1:</p>
+<p>Add a footnote to 23.3.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.4.4 [list.ops], replace paragraph 4 with:</p>
+<p>In 23.3.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
behave as iterators into *this, not into x.
</p></blockquote>
-<p>In 23.2.4.4 [list.ops], replace paragraph 7 with:</p>
+<p>In 23.3.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
behave as iterators into *this, not into x.
</p></blockquote>
-<p>In 23.2.4.4 [list.ops], replace paragraph 12 with:</p>
+<p>In 23.3.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).
<hr>
<h3><a name="251"></a>251. basic_stringbuf missing allocator_type</h3>
-<p><b>Section:</b> 27.7.1 [stringbuf] <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-07-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 27.8.1 [stringbuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-07-28 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The synopsis for the template class <tt>basic_stringbuf</tt>
doesn't list a typedef for the template parameter
<hr>
<h3><a name="252"></a>252. missing casts/C-style casts used in iostreams</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> 2000-07-28</p>
+<p><b>Section:</b> 27.8 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-07-28 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
const_cast<> in the Returns clause for basic_istringstream<>::rdbuf().
<hr>
<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>Section:</b> 26.6.2.1 [valarray.cons], 26.6.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2000-07-31 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>This discussion is adapted from message c++std-lib-7056 posted
November 11, 1999. I don't think that anyone can reasonably claim
<p>slice_array:</p>
<ul>
<li> Make the copy constructor and copy-assignment operator declarations
- public in the slice_array class template definition in 26.5.5 [template.slice.array] </li>
-<li> remove paragraph 3 of 26.5.5 [template.slice.array]</li>
+ public in the slice_array class template definition in 26.6.5 [template.slice.array] </li>
+<li> remove paragraph 3 of 26.6.5 [template.slice.array]</li>
<li> remove the copy constructor declaration from [cons.slice.arr]</li>
<li> change paragraph 1 of [cons.slice.arr] to read "This constructor is declared
to be private. This constructor need not be defined."</li>
-<li> remove the first sentence of paragraph 1 of 26.5.5.1 [slice.arr.assign]</li>
+<li> remove the first sentence of paragraph 1 of 26.6.5.1 [slice.arr.assign]</li>
<li> Change the first three words of the second sentence of paragraph 1 of
- 26.5.5.1 [slice.arr.assign] to "These assignment operators have"</li>
+ 26.6.5.1 [slice.arr.assign] to "These assignment operators have"</li>
</ul>
<p>gslice_array:</p>
<ul>
<li> Make the copy constructor and copy-assignment operator declarations
- public in the gslice_array class template definition in 26.5.7 [template.gslice.array] </li>
-<li> remove the note in paragraph 3 of 26.5.7 [template.gslice.array]</li>
+ public in the gslice_array class template definition in 26.6.7 [template.gslice.array] </li>
+<li> remove the note in paragraph 3 of 26.6.7 [template.gslice.array]</li>
<li> remove the copy constructor declaration from [gslice.array.cons]</li>
<li> change paragraph 1 of [gslice.array.cons] to read "This constructor is declared
to be private. This constructor need not be defined."</li>
-<li> remove the first sentence of paragraph 1 of 26.5.7.1 [gslice.array.assign]</li>
+<li> remove the first sentence of paragraph 1 of 26.6.7.1 [gslice.array.assign]</li>
<li> Change the first three words of the second sentence of paragraph 1 of
- 26.5.7.1 [gslice.array.assign] to "These assignment operators have"</li>
+ 26.6.7.1 [gslice.array.assign] to "These assignment operators have"</li>
</ul>
<p>mask_array:</p>
<ul>
<li> Make the copy constructor and copy-assignment operator declarations
- public in the mask_array class template definition in 26.5.8 [template.mask.array] </li>
-<li> remove the note in paragraph 2 of 26.5.8 [template.mask.array]</li>
+ public in the mask_array class template definition in 26.6.8 [template.mask.array] </li>
+<li> remove the note in paragraph 2 of 26.6.8 [template.mask.array]</li>
<li> remove the copy constructor declaration from [mask.array.cons]</li>
<li> change paragraph 1 of [mask.array.cons] to read "This constructor is declared
to be private. This constructor need not be defined."</li>
-<li> remove the first sentence of paragraph 1 of 26.5.8.1 [mask.array.assign]</li>
+<li> remove the first sentence of paragraph 1 of 26.6.8.1 [mask.array.assign]</li>
<li> Change the first three words of the second sentence of paragraph 1 of
- 26.5.8.1 [mask.array.assign] to "These assignment operators have"</li>
+ 26.6.8.1 [mask.array.assign] to "These assignment operators have"</li>
</ul>
<p>indirect_array:</p>
<ul>
<li>Make the copy constructor and copy-assignment operator declarations
- public in the indirect_array class definition in 26.5.9 [template.indirect.array]</li>
-<li> remove the note in paragraph 2 of 26.5.9 [template.indirect.array]</li>
+ public in the indirect_array class definition in 26.6.9 [template.indirect.array]</li>
+<li> remove the note in paragraph 2 of 26.6.9 [template.indirect.array]</li>
<li> remove the copy constructor declaration from [indirect.array.cons]</li>
<li> change the descriptive text in [indirect.array.cons] to read "This constructor is
declared to be private. This constructor need not be defined."</li>
-<li> remove the first sentence of paragraph 1 of 26.5.9.1 [indirect.array.assign]</li>
+<li> remove the first sentence of paragraph 1 of 26.6.9.1 [indirect.array.assign]</li>
<li> Change the first three words of the second sentence of paragraph 1 of
- 26.5.9.1 [indirect.array.assign] to "These assignment operators have"</li>
+ 26.6.9.1 [indirect.array.assign] to "These assignment operators have"</li>
</ul>
<p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
copy constructor and copy assignment operators public, instead of
<hr>
<h3><a name="254"></a>254. Exception types in clause 19 are constructed from <tt>std::string</tt></h3>
-<p><b>Section:</b> 19.1 [std.exceptions], 27.4.2.1.1 [ios::failure] <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-08-01</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 19.2 [std.exceptions], 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-08-01 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Many of the standard exception types which implementations are
<ul>
<li>Limit the size of a string that exception objects are required to
-throw: change the postconditions of 19.1.2 [domain.error] paragraph 3
-and 19.1.6 [runtime.error] paragraph 3 to something like this:
+throw: change the postconditions of 19.2.2 [domain.error] paragraph 3
+and 19.2.6 [runtime.error] paragraph 3 to something like this:
"strncmp(what(), what_arg._str(), N) == 0, where N is an
implementation defined constant no smaller than 256".</li>
<li>Allow the const string& constructor to throw, but not the
<p><b>Proposed resolution:</b></p>
<p>
-Change 19.1.1 [logic.error]
+Change 19.2.1 [logic.error]
</p>
<blockquote>
</blockquote>
<p>
-Change 19.1.2 [domain.error]
+Change 19.2.2 [domain.error]
</p>
<blockquote>
</blockquote>
<p>
-Change 19.1.3 [invalid.argument]
+Change 19.2.3 [invalid.argument]
</p>
<blockquote>
</blockquote>
<p>
-Change 19.1.4 [length.error]
+Change 19.2.4 [length.error]
</p>
<blockquote>
</blockquote>
<p>
-Change 19.1.5 [out.of.range]
+Change 19.2.5 [out.of.range]
</p>
<blockquote>
</blockquote>
<p>
-Change 19.1.6 [runtime.error]
+Change 19.2.6 [runtime.error]
</p>
<blockquote>
</blockquote>
<p>
-Change 19.1.7 [range.error]
+Change 19.2.7 [range.error]
</p>
<blockquote>
</blockquote>
<p>
-Change 19.1.8 [overflow.error]
+Change 19.2.8 [overflow.error]
</p>
<blockquote>
</blockquote>
<p>
-Change 19.1.9 [underflow.error]
+Change 19.2.9 [underflow.error]
</p>
<blockquote>
</blockquote>
<p>
-Change 27.4.2.1.1 [ios::failure]
+Change 27.5.2.1.1 [ios::failure]
</p>
<blockquote>
<hr>
<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>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-21 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
27.4.4.2, p17 says
<hr>
<h3><a name="258"></a>258. Missing allocator 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#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-08-22</p>
+<p><b>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-08-22 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
From lib-7752:
<hr>
<h3><a name="259"></a>259. <tt>basic_string::operator[]</tt> and const correctness</h3>
-<p><b>Section:</b> 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Chris Newton <b>Date:</b> 2000-08-27</p>
+<p><b>Section:</b> 21.4.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Chris Newton <b>Opened:</b> 2000-08-27 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.capacity">issues</a> in [string.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
<hr>
<h3><a name="260"></a>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt></h3>
-<p><b>Section:</b> 24.5.1.2 [istream.iterator.ops] <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-27</p>
+<p><b>Section:</b> 24.6.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-27 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.ops">issues</a> in [istream.iterator.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
it as returning the iterator by value. 24.5.1.2, p5 shows the same
<hr>
<h3><a name="261"></a>261. Missing description of <tt>istream_iterator::operator!=</tt></h3>
-<p><b>Section:</b> 24.5.1.2 [istream.iterator.ops] <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-27</p>
+<p><b>Section:</b> 24.6.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-27 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.ops">issues</a> in [istream.iterator.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
24.5.1, p3 lists the synopsis for
<hr>
<h3><a name="262"></a>262. Bitmask operator ~ specified incorrectly</h3>
-<p><b>Section:</b> 17.3.2.1.2 [bitmask.types] <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> 2000-09-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>Section:</b> 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2000-09-03 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The ~ operation should be applied after the cast to int_type.
<hr>
<h3><a name="263"></a>263. Severe restriction on <tt>basic_string</tt> reference counting</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>
- <b>Submitter:</b> Kevlin Henney <b>Date:</b> 2000-09-04</p>
+<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Kevlin Henney <b>Opened:</b> 2000-09-04 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The note in paragraph 6 suggests that the invalidation rules for
<hr>
<h3><a name="264"></a>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> John Potter <b>Date:</b> 2000-09-07</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> John Potter <b>Opened:</b> 2000-09-07 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="265"></a>265. std::pair::pair() effects overly restrictive</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> Martin Sebor <b>Date:</b> 2000-09-11</p>
+<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-09-11 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I don't see any requirements on the types of the elements of the
<hr>
<h3><a name="266"></a>266. bad_exception::~bad_exception() missing Effects clause</h3>
-<p><b>Section:</b> 18.7.2.1 [bad.exception] <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-09-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>Section:</b> 18.8.2.1 [bad.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-09-24 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The synopsis for std::bad_exception lists the function ~bad_exception()
<p><b>Proposed resolution:</b></p>
<p>
Remove the destructor from the class synopses of
-<tt>bad_alloc</tt> (18.5.2.1 [bad.alloc]),
-<tt>bad_cast</tt> (18.6.2 [bad.cast]),
-<tt>bad_typeid</tt> (18.6.3 [bad.typeid]),
-and <tt>bad_exception</tt> (18.7.2.1 [bad.exception]).
+<tt>bad_alloc</tt> (18.6.2.1 [bad.alloc]),
+<tt>bad_cast</tt> (18.7.3 [bad.cast]),
+<tt>bad_typeid</tt> (18.7.4 [bad.typeid]),
+and <tt>bad_exception</tt> (18.8.2.1 [bad.exception]).
</p>
<hr>
<h3><a name="268"></a>268. Typo in locale synopsis</h3>
-<p><b>Section:</b> 22.1.1 [locale] <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-10-05</p>
+<p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-10-05 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The synopsis of the class std::locale in 22.1.1 contains two typos:
the semicolons after the declarations of the default ctor
<hr>
<h3><a name="270"></a>270. Binary search requirements overly strict</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#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-10-18</p>
+<p><b>Section:</b> 25.5.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-10-18 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.binary.search">issues</a> in [alg.binary.search].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#472">472</a></p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="271"></a>271. basic_iostream missing typedefs</h3>
-<p><b>Section:</b> 27.6.1.5 [iostreamclass] <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-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>Section:</b> 27.7.1.5 [iostreamclass] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Class template basic_iostream has no typedefs. The typedefs it
<p><b>Proposed resolution:</b></p>
<p>Add the following to basic_iostream's class synopsis in
-27.6.1.5 [iostreamclass], immediately after <tt>public</tt>:</p>
+27.7.1.5 [iostreamclass], immediately after <tt>public</tt>:</p>
<pre> // types:
typedef charT char_type;
<hr>
<h3><a name="272"></a>272. Missing parentheses around subexpression</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#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
+<p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a></p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="273"></a>273. Missing ios_base qualification on members of a dependent class</h3>
-<p><b>Section:</b> 27 [input.output] <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-11-02</p>
+<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
<hr>
<h3><a name="274"></a>274. a missing/impossible allocator 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#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
+<p><b>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of
<hr>
<h3><a name="275"></a>275. Wrong type in num_get::get() overloads</h3>
-<p><b>Section:</b> 22.2.2.1.1 [facet.num.get.members] <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> 2000-11-02</p>
+<p><b>Section:</b> 22.4.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.members">issues</a> in [facet.num.get.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 22.2.2.1.1, we have a list of overloads for num_get<>::get().
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.1.1 [facet.num.get.members], change</p>
+<p>In 22.4.2.1.1 [facet.num.get.members], change</p>
<pre> iter_type get(iter_type in, iter_type end, ios_base& str,
ios_base::iostate& err, short& val) const;
</pre>
<hr>
<h3><a name="276"></a>276. Assignable 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#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2000-11-07</p>
+<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2000-11-07 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.1/3 states that the objects stored in a container must be
-Assignable. 23.3.1 [map], paragraph 2,
+Assignable. 23.4.1 [map], paragraph 2,
states that map satisfies all requirements for a container, while in
the same time defining value_type as pair<const Key, T> - a type
that is not Assignable.
<hr>
<h3><a name="278"></a>278. What does iterator validity mean?</h3>
-<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>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2000-11-27 <b>Last modified:</b> 2008-09-30</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Section 23.2.4.4 [list.ops] states that
+Section 23.3.4.4 [list.ops] states that
</p>
<pre> void splice(iterator position, list<T, Allocator>& x);
</pre>
<p><b>Proposed resolution:</b></p>
-<p>Add the following text to the end of section 24.1 [iterator.requirements],
+<p>Add the following text to the end of section 24.2 [iterator.concepts],
after paragraph 5:</p>
<blockquote><p>
An <i>invalid</i> iterator is an iterator that may be
<hr>
<h3><a name="280"></a>280. Comparison of reverse_iterator to const reverse_iterator</h3>
-<p><b>Section:</b> 24.4.1 [reverse.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-11-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>Section:</b> 24.5.1 [reverse.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-11-27 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This came from an email from Steve Cleary to Fergus in reference to
<p><b>Proposed resolution:</b></p>
<p>
-<b>Section:</b> 24.4.1.1 [reverse.iterator]
+<b>Section:</b> 24.5.1.1 [reverse.iterator]
add/change the following declarations:</p>
<pre> A) Add a templated assignment operator, after the same manner
as the templated copy constructor, i.e.:
</pre>
<p>
Also make the addition/changes for these signatures in
-24.4.1.3 [reverse.iter.ops].
+24.5.1.2 [reverse.iter.ops].
</p>
<p><i>[
<hr>
<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>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-02 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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>
<p><b>Discussion:</b></p>
<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
requirements of <tt>LessThanComparable</tt> ( [lessthancomparable])
-and <tt>CopyConstructible</tt> (20.1.1 [utility.arg.requirements]).
+and <tt>CopyConstructible</tt> (X [utility.arg.requirements]).
Since the functions take and return their arguments and result by
const reference, I believe the <tt>CopyConstructible</tt> requirement
is unnecessary.
<hr>
<h3><a name="282"></a>282. What types does numpunct grouping refer to?</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#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2000-12-05</p>
+<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2000-12-05 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Paragraph 16 mistakenly singles out integral types for inserting
<blockquote><p>
For integral types, punct.thousands_sep() characters are inserted into
the sequence as determined by the value returned by punct.do_grouping()
-using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
+using the method described in 22.4.3.1.2 [facet.numpunct.virtuals].
</p></blockquote>
<p>To:</p>
<blockquote><p>
For arithmetic types, punct.thousands_sep() characters are inserted into
the sequence as determined by the value returned by punct.do_grouping()
-using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
+using the method described in 22.4.3.1.2 [facet.numpunct.virtuals].
</p></blockquote>
<p><i>[
<hr>
<h3><a name="283"></a>283. std::replace() requirement incorrect/insufficient</h3>
-<p><b>Section:</b> 25.2.5 [alg.replace] <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-15</p>
+<p><b>Section:</b> 25.4.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-15 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.replace">active issues</a> in [alg.replace].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#483">483</a></p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="284"></a>284. unportable example in 20.3.7, p6</h3>
-<p><b>Section:</b> 20.6.7 [comparisons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-26</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 20.7.8 [comparisons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-26 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>The example in 20.6.7 [comparisons], p6 shows how to use the C
+<p>The example in 20.7.8 [comparisons], p6 shows how to use the C
library function <tt>strcmp()</tt> with the function pointer adapter
<tt>ptr_fun()</tt>. But since it's unspecified whether the C library
functions have <tt>extern "C"</tt> or <tt>extern
-"C++"</tt> linkage [17.4.2.2 [using.linkage]], and since
+"C++"</tt> linkage [17.6.2.3 [using.linkage]], and since
function pointers with different the language linkage specifications
(7.5 [dcl.link]) are incompatible, whether this example is
well-formed is unspecified.
<p><b>Proposed resolution:</b></p>
-<p>Change 20.6.7 [comparisons] paragraph 6 from:</p>
+<p>Change 20.7.8 [comparisons] paragraph 6 from:</p>
<blockquote>
<p>[<i>Example:</i></p>
<pre> replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
<hr>
<h3><a name="285"></a>285. minor editorial errors in fstream ctors</h3>
-<p><b>Section:</b> 27.8.1.7 [ifstream.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> 2000-12-31</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>Section:</b> 27.9.1.7 [ifstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-31 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>27.8.1.7 [ifstream.cons], p2, 27.8.1.11 [ofstream.cons], p2, and
-27.8.1.15 [fstream.cons], p2 say about the effects of each constructor:
+<p>27.9.1.7 [ifstream.cons], p2, 27.9.1.11 [ofstream.cons], p2, and
+27.9.1.15 [fstream.cons], p2 say about the effects of each constructor:
</p>
<p>... If that function returns a null pointer, calls
</p>
<p>The parenthetical note doesn't apply since the ctors cannot throw an
-exception due to the requirement in 27.4.4.1 [basic.ios.cons], p3
+exception due to the requirement in 27.5.4.1 [basic.ios.cons], p3
that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
</p>
<hr>
<h3><a name="286"></a>286. <cstdlib> requirements missing size_t typedef</h3>
-<p><b>Section:</b> 25.4 [alg.c.library] <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> 2000-12-30</p>
+<p><b>Section:</b> 25.6 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <cstdlib> header file contains prototypes for bsearch and
<hr>
<h3><a name="288"></a>288. <cerrno> requirements missing macro EILSEQ</h3>
-<p><b>Section:</b> 19.3 [errno] <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> 2000-12-30</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>Section:</b> 19.4 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
<hr>
<h3><a name="291"></a>291. Underspecification of set algorithms</h3>
-<p><b>Section:</b> 25.3.5 [alg.set.operations] <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> 2001-01-03</p>
+<p><b>Section:</b> 25.5.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-01-03 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.set.operations">issues</a> in [alg.set.operations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The standard library contains four algorithms that compute set
<p><b>Proposed resolution:</b></p>
-<p>Add the following to the end of 25.3.5.2 [set.union] paragraph 5:</p>
+<p>Add the following to the end of 25.5.5.2 [set.union] paragraph 5:</p>
<blockquote><p>
If [first1, last1) contains <i>m</i> elements that are equivalent to
each other and [first2, last2) contains <i>n</i> elements that are
[first2, last2), in that order.
</p></blockquote>
-<p>Add the following to the end of 25.3.5.3 [set.intersection] paragraph 5:</p>
+<p>Add the following to the end of 25.5.5.3 [set.intersection] paragraph 5:</p>
<blockquote><p>
If [first1, last1) contains <i>m</i> elements that are equivalent to each
other and [first2, last2) contains <i>n</i> elements that are
elements from [first1, last1) are copied to the output range.
</p></blockquote>
-<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 [set.difference]
+<p>Add a new paragraph, <b>Notes</b>, after 25.5.5.4 [set.difference]
paragraph 4:</p>
<blockquote><p>
If [first1, last1) contains <i>m</i> elements that are equivalent to each
[first1, last1) are copied to the output range.
</p></blockquote>
-<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 [set.symmetric.difference]
+<p>Add a new paragraph, <b>Notes</b>, after 25.5.5.5 [set.symmetric.difference]
paragraph 4:</p>
<blockquote><p>
If [first1, last1) contains <i>m</i> elements that are equivalent to
<hr>
<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>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-05 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The Effects clause of the member function <tt>copyfmt()</tt> in
27.4.4.2, p15 doesn't consider the case where the left-hand side
<hr>
<h3><a name="294"></a>294. User defined macros and standard headers</h3>
-<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>Section:</b> 17.6.3.3.1 [macro.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> James Kanze <b>Opened:</b> 2001-01-11 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>Paragraph 2 of 17.4.3.2.1 [macro.names] reads: "A
+<p>Paragraph 2 of 17.6.3.3.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>
<p>I think that this phrase was probably formulated before it was
decided that a standard header may freely include other standard
headers. The phrase would be perfectly appropriate for C, for
-example. In light of 17.4.4.1 [res.on.headers] paragraph 1, however,
+example. In light of 17.6.4.2 [res.on.headers] paragraph 1, however,
it isn't stringent enough.</p>
<p><b>Proposed resolution:</b></p>
-<p>For 17.4.3.2.1 [macro.names], replace the current wording, which reads:</p>
+<p>For 17.6.3.3.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
<hr>
<h3><a name="295"></a>295. Is abs defined in <cmath>?</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2001-01-12</p>
+<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2001-01-12 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 80 lists the contents of the <cmath> header. It does not
<p><b>Proposed resolution:</b></p>
<p>
Add <tt>abs</tt> to Table 80. Also, remove the parenthetical list
-of functions "(abs(), div(), rand(), srand())" from 26.5 [numarray],
+of functions "(abs(), div(), rand(), srand())" from 26.6 [numarray],
paragraph 1.
</p>
<hr>
<h3><a name="297"></a>297. const_mem_fun_t<>::argument_type should be const T*</h3>
-<p><b>Section:</b> 20.6.8 [logical.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 20.7.9 [logical.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The class templates <tt>const_mem_fun_t</tt> in 20.5.8, p8 and
<tt>const_mem_fun1_t</tt>
<hr>
<h3><a name="298"></a>298. ::operator delete[] requirement incorrect/insufficient</h3>
-<p><b>Section:</b> 18.5.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> John A. Pedretti <b>Date:</b> 2001-01-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 18.6.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> John A. Pedretti <b>Opened:</b> 2001-01-10 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 -
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.8 [res.on.arguments]).
+call to <tt>operator delete[](void*)</tt> (17.6.3.9 [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>.
<hr>
<h3><a name="300"></a>300. list::merge() specification incomplete</h3>
-<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>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> John Pedretti <b>Opened:</b> 2001-01-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The "Effects" clause for list::merge() (23.2.4.4 [list.ops], p23)
+The "Effects" clause for list::merge() (23.3.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 == &x). The requirement in the
note in p24 (below) is that x be empty after the merge which is surely
<p><b>Proposed resolution:</b></p>
-<p>In 23.2.4.4 [list.ops], replace paragraps 23-25 with:</p>
+<p>In 23.3.4.4 [list.ops], replace paragraps 23-25 with:</p>
<blockquote>
<p>
23 Effects: if (&x == this) does nothing; otherwise, merges the two
</blockquote>
<p><i>[Copenhagen: The original proposed resolution did not fix all of
-the problems in 23.2.4.4 [list.ops], p22-25. Three different
+the problems in 23.3.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
<hr>
<h3><a name="301"></a>301. basic_string template ctor effects clause omits allocator argument</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#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-27</p>
+<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-27 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.require">active issues</a> in [string.require].</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The effects clause for the basic_string template ctor in 21.3.1, p15
<hr>
<h3><a name="303"></a>303. Bitset input operator underspecified</h3>
-<p><b>Section:</b> 23.3.5.3 [bitset.operators] <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> 2001-02-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>Section:</b> 20.3.6.3 [bitset.operators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-02-05 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
<hr>
<h3><a name="305"></a>305. Default behavior of codecvt<wchar_t, char, mbstate_t>::length()</h3>
-<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <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-01-24</p>
+<p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-01-24 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>22.2.1.5/3 introduces codecvt in part with:</p>
<hr>
<h3><a name="306"></a>306. offsetof macro and non-POD types</h3>
-<p><b>Section:</b> 18.1 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 2001-02-21</p>
+<p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2001-02-21 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
<hr>
<h3><a name="307"></a>307. Lack of reference typedefs in container adaptors</h3>
-<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>Section:</b> 23.3.4 [list] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-03-13 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>From reflector message c++std-lib-8330. See also lib-8317.</p>
<p>
-The standard is currently inconsistent in 23.2.4.2 [list.capacity]
-paragraph 1 and 23.2.4.3 [list.modifiers] paragraph 1.
+The standard is currently inconsistent in 23.3.4.2 [list.capacity]
+paragraph 1 and 23.3.4.3 [list.modifiers] paragraph 1.
23.2.3.3/1, for example, says:
</p>
<hr>
<h3><a name="308"></a>308. Table 82 mentions unrelated headers</h3>
-<p><b>Section:</b> 27 [input.output] <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-03-15</p>
+<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-15 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 82 in section 27 mentions the header <cstdlib> for String
-streams (27.7 [string.streams]) and the headers <cstdio> and
-<cwchar> for File streams (27.8 [file.streams]). It's not clear
+streams (27.8 [string.streams]) and the headers <cstdio> and
+<cwchar> for File streams (27.9 [file.streams]). It's not clear
why these headers are mentioned in this context since they do not
define any of the library entities described by the
-subclauses. According to 17.4.1.1 [contents], only such headers
+subclauses. According to 17.6.1.1 [contents], only such headers
are to be listed in the summary.
</p>
<p><i>[Copenhagen: changed the proposed resolution slightly. The
original proposed resolution also said to remove <cstdio> from
Table 82. However, <cstdio> is mentioned several times within
-section 27.8 [file.streams], including 27.8.2 [c.files].]</i></p>
+section 27.9 [file.streams], including 27.9.2 [c.files].]</i></p>
<hr>
<h3><a name="310"></a>310. Is errno a macro?</h3>
-<p><b>Section:</b> 17.4.1.2 [headers], 19.3 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 2001-03-21</p>
+<p><b>Section:</b> 17.6.1.2 [headers], 19.4 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2001-03-21 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Exactly how should errno be declared in a conforming C++ header?
<hr>
<h3><a name="311"></a>311. Incorrect wording in basic_ostream class synopsis</h3>
-<p><b>Section:</b> 27.6.2.1 [ostream] <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-03-21</p>
+<p><b>Section:</b> 27.7.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-03-21 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream">issues</a> in [ostream].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In 27.6.2.1 [ostream], the synopsis of class basic_ostream says:</p>
+<p>In 27.7.2.1 [ostream], the synopsis of class basic_ostream says:</p>
<pre> // partial specializationss
template<class traits>
<p><b>Proposed resolution:</b></p>
-<p>In the synopsis in 27.6.2.1 [ostream], remove the
+<p>In the synopsis in 27.7.2.1 [ostream], remove the
<i>// partial specializationss</i> comment. Also remove the same
comment (correctly spelled, but still incorrect) from the synopsis in
-27.6.2.6.4 [ostream.inserters.character].
+27.7.2.6.4 [ostream.inserters.character].
</p>
<p><i>[
-Pre-Redmond: added 27.6.2.6.4 [ostream.inserters.character] because of Martin's
+Pre-Redmond: added 27.7.2.6.4 [ostream.inserters.character] because of Martin's
comment in c++std-lib-8939.
]</i></p>
<hr>
<h3><a name="312"></a>312. Table 27 is missing headers</h3>
-<p><b>Section:</b> 20 [utilities] <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-03-29</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>Section:</b> 20 [utilities] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-29 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utilities">issues</a> in [utilities].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Table 27 in section 20 lists the header <memory> (only) for
Memory (lib.memory) but neglects to mention the headers
-<cstdlib> and <cstring> that are discussed in 20.5.5 [meta.rel].</p>
+<cstdlib> and <cstring> that are discussed in 20.6.5 [meta.rel].</p>
<p><b>Proposed resolution:</b></p>
<hr>
<h3><a name="315"></a>315. Bad "range" in list::unique complexity</h3>
-<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>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-05-01 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-23.2.4.4 [list.ops], Para 21 describes the complexity of
+23.3.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)".
<hr>
<h3><a name="316"></a>316. Vague text in Table 69</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-04 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Table 69 says this about a_uniq.insert(t):</p>
<hr>
<h3><a name="317"></a>317. Instantiation vs. specialization of facets</h3>
-<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</p>
+<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-04 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The localization section of the standard refers to specializations of
<hr>
<h3><a name="318"></a>318. Misleading comment in definition of numpunct_byname</h3>
-<p><b>Section:</b> 22.2.3.2 [locale.numpunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-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>Section:</b> 22.4.3.2 [locale.numpunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-12 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The definition of the numpunct_byname template contains the following
comment:</p>
<hr>
<h3><a name="319"></a>319. Storage allocation wording confuses "Required behavior", "Requires"</h3>
-<p><b>Section:</b> 18.5.1.1 [new.delete.single], 18.5.1.2 [new.delete.array] <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> 2001-05-15</p>
+<p><b>Section:</b> 18.6.1.1 [new.delete.single], 18.6.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2001-05-15 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>The standard specifies 17.3.1.3 [structure.specifications] that "Required
+<p>The standard specifies 17.5.1.4 [structure.specifications] that "Required
behavior" elements describe "the semantics of a function definition
provided by either the implementation or a C++ program."</p>
-<p>The standard specifies 17.3.1.3 [structure.specifications] that "Requires"
+<p>The standard specifies 17.5.1.4 [structure.specifications] that "Requires"
elements describe "the preconditions for calling the function."</p>
<p>In the sections noted below, the current wording specifies
<p><b>Proposed resolution:</b></p>
-<p>In 18.5.1.1 [new.delete.single] Para 12 Change:</p>
+<p>In 18.6.1.1 [new.delete.single] Para 12 Change:</p>
<blockquote>
<p>Required behavior: accept a value of ptr that is null or that was
returned by an earlier call ...</p>
earlier call ...</p>
</blockquote>
-<p>In 18.5.1.2 [new.delete.array] Para 11 Change:</p>
+<p>In 18.6.1.2 [new.delete.array] Para 11 Change:</p>
<blockquote>
<p>Required behavior: accept a value of ptr that is null or that was
returned by an earlier call ...</p>
<hr>
<h3><a name="320"></a>320. list::assign overspecified</h3>
-<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>Section:</b> 23.3.4.1 [list.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-05-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Section 23.2.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
+Section 23.3.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>
<p><b>Proposed resolution:</b></p>
-<p>Change 23.2.4.1 [list.cons]/7 from:</p>
+<p>Change 23.3.4.1 [list.cons]/7 from:</p>
<blockquote>
<p>Effects:</p>
<p>Effects: Replaces the contents of the list with the range [first, last).</p>
</blockquote>
-<p>In 23.1.3 [sequence.reqmts], in Table 67 (sequence requirements),
+<p>In 23.2.3 [sequence.reqmts], in Table 67 (sequence requirements),
add two new rows:</p>
<pre> a.assign(i,j) void pre: i,j are not iterators into a.
Replaces elements in a with a copy
of t.
</pre>
-<p>Change 23.2.4.1 [list.cons]/8 from:</p>
+<p>Change 23.3.4.1 [list.cons]/8 from:</p>
<blockquote>
<p>Effects:</p>
<hr>
<h3><a name="321"></a>321. Typo in num_get</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#WP">WP</a>
- <b>Submitter:</b> Kevin Djang <b>Date:</b> 2001-05-17</p>
+<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Kevin Djang <b>Opened:</b> 2001-05-17 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 22.2.2.1.2 at p7 states that "A length specifier is added to
<hr>
<h3><a name="322"></a>322. iterator and const_iterator should have the same value type</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> Matt Austern <b>Date:</b> 2001-05-17</p>
+<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-05-17 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It's widely assumed that, if X is a container,
<hr>
<h3><a name="324"></a>324. Do output iterators have value types?</h3>
-<p><b>Section:</b> 24.1.2 [output.iterators] <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> 2001-06-07</p>
+<p><b>Section:</b> 24.2.3 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2001-06-07 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Table 73 suggests that output iterators have value types. It
<hr>
<h3><a name="325"></a>325. Misleading text in moneypunct<>::do_grouping</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> Martin Sebor <b>Date:</b> 2001-07-02</p>
+<p><b>Section:</b> 22.4.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-02 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The Returns clause in 22.2.6.3.2, p3 says about
moneypunct<charT>::do_grouping()
<hr>
<h3><a name="327"></a>327. Typo in time_get facet in table 52</h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Tiki Wan <b>Date:</b> 2001-07-06</p>
+<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Tiki Wan <b>Opened:</b> 2001-07-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#447">447</a></p>
<p><b>Discussion:</b></p>
<p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
<p><b>Proposed resolution:</b></p>
<p>
In table 52, required instantiations, in
-22.1.1.1.1 [locale.category], change</p>
+22.3.1.1.1 [locale.category], change</p>
<pre> time_get<wchar_t, OutputIterator>
time_get_byname<wchar_t, OutputIterator>
</pre>
<hr>
<h3><a name="328"></a>328. Bad sprintf format modifier in money_put<>::do_put()</h3>
-<p><b>Section:</b> 22.2.6.2.2 [locale.money.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> Martin Sebor <b>Date:</b> 2001-07-07</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>Section:</b> 22.4.6.2.2 [locale.money.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-07 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The sprintf format string , "%.01f" (that's the digit one), in the
description of the do_put() member functions of the money_put facet in
<hr>
<h3><a name="329"></a>329. vector capacity, reserve and reallocation</h3>
-<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>Section:</b> 23.3.6.2 [vector.capacity], 23.3.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2001-07-13 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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.6.2 [vector.capacity] and
-section 23.2.6.4 [vector.modifiers].
+a reallocation of a vector in Section 23.3.6.2 [vector.capacity] and
+section 23.3.6.4 [vector.modifiers].
</p>
-<p>23.2.6.2 [vector.capacity],p5 says:</p>
+<p>23.3.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
<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.6.2 [vector.capacity], p1-2) state:</p>
+<p>However, the previous paragraphs (23.3.6.2 [vector.capacity], p1-2) state:</p>
<blockquote>
<p>
(capacity) Returns: The total number of elements the vector
<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.6.4 [vector.modifiers], p1:
+up by 23.3.6.4 [vector.modifiers], p1:
</p>
<blockquote><p>
(insert) Notes: Causes reallocation if the new size is greater than the old
<p><b>Proposed resolution:</b></p>
-<p>Change the wording of 23.2.6.2 [vector.capacity] paragraph 5 to:</p>
+<p>Change the wording of 23.3.6.2 [vector.capacity] paragraph 5 to:</p>
<blockquote><p>
Notes: Reallocation invalidates all the references, pointers, and
<hr>
<h3><a name="331"></a>331. bad declaration of destructor for ios_base::failure</h3>
-<p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-23</p>
+<p><b>Section:</b> 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-23 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-With the change in 17.4.4.9 [res.on.exception.handling] to state
+With the change in 17.6.4.10 [res.on.exception.handling] to state
"An implementation may strengthen the exception-specification for a
non-virtual function by removing listed exceptions."
(issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
};
}
</pre>
-<p>the class failure cannot be implemented since in 18.6.1 [type.info] the destructor of class exception has an empty
+<p>the class failure cannot be implemented since in 18.7.1 [type.info] the destructor of class exception has an empty
exception specification:</p>
<pre> namespace std {
class exception {
<hr>
<h3><a name="333"></a>333. does endl imply synchronization with the device?</h3>
-<p><b>Section:</b> 27.6.2.8 [ostream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-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>Section:</b> 27.7.2.8 [ostream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-27 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>A footnote in 27.6.2.8 [ostream.manip] states:</p>
+<p>A footnote in 27.7.2.8 [ostream.manip] states:</p>
<blockquote><p>
[Footnote: The effect of executing cout << endl is to insert a
newline character in the output sequence controlled by cout, then
<p><b>Proposed resolution:</b></p>
-<p>Remove footnote 300 from section 27.6.2.8 [ostream.manip].</p>
+<p>Remove footnote 300 from section 27.7.2.8 [ostream.manip].</p>
<p><b>Rationale:</b></p>
<hr>
<h3><a name="334"></a>334. map::operator[] specification forces inefficient implementation</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> Andrea Griffini <b>Date:</b> 2001-09-02</p>
+<p><b>Section:</b> 23.4.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Andrea Griffini <b>Opened:</b> 2001-09-02 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current standard describes map::operator[] using a
<p><b>Proposed resolution:</b></p>
<p>
-Replace 23.3.1.2 [map.access] paragraph 1 with
+Replace 23.4.1.2 [map.access] paragraph 1 with
</p>
<blockquote>
<p>
<hr>
<h3><a name="335"></a>335. minor issue with char_traits, table 37</h3>
-<p><b>Section:</b> 21.1.1 [char.traits.require] <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-09-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 21.2.1 [char.traits.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-09-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Table 37, in 21.1.1 [char.traits.require], descibes char_traits::assign
+Table 37, in 21.2.1 [char.traits.require], descibes char_traits::assign
as:
</p>
<pre> X::assign(c,d) assigns c = d.
<hr>
<h3><a name="336"></a>336. Clause 17 lack of references to deprecated headers</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-09-05</p>
+<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-09-05 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>From c++std-edit-873:</p>
-<p>17.4.1.2 [headers], Table 11. In this table, the header
+<p>17.6.1.2 [headers], Table 11. In this table, the header
<strstream> is missing.</p>
<p>This shows a general problem: The whole clause 17 refers quite
<p><b>Proposed resolution:</b></p>
-<p>To 17.4.1.2 [headers] Table 11, C++ Library Headers, add
+<p>To 17.6.1.2 [headers] Table 11, C++ Library Headers, add
"<strstream>".</p>
<p>In the following places, change "clauses 17 through 27" to "clauses
<li>1.2 [intro.refs] Normative references/1/footnote 1</li>
<li>1.3 [intro.defs] Definitions/1</li>
<li>7 [dcl.dcl] Library introduction/9</li>
-<li>17.3 [description] Method of description (Informative)/1</li>
-<li>17.3.2.1.3 [character.seq] Character sequences/1/bullet 2</li>
-<li>17.3.2.2 [functions.within.classes] Functions within classes/1</li>
-<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.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.7 [protection.within.classes] Protection within classes/1</li>
+<li>17.5 [description] Method of description (Informative)/1</li>
+<li>17.5.2.1.4 [character.seq] Character sequences/1/bullet 2</li>
+<li>17.5.2.2 [functions.within.classes] Functions within classes/1</li>
+<li>17.5.2.3 [objects.within.classes] Private members/1/(2 places)</li>
+<li>17.6 [requirements] Library-wide requirements/1</li>
+<li>17.6.1.2 [headers] Headers/4</li>
+<li>17.6.3.6 [replacement.functions] Replacement functions/1</li>
+<li>17.6.4.4 [global.functions] Global or non-member functions/2</li>
+<li>17.6.4.8 [protection.within.classes] Protection within classes/1</li>
</ul>
<hr>
<h3><a name="337"></a>337. replace_copy_if's template parameter should be InputIterator</h3>
-<p><b>Section:</b> 25.2.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-09-07</p>
+<p><b>Section:</b> 25.4.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-09-07 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.replace">active issues</a> in [alg.replace].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>From c++std-edit-876:</p>
<p>
-In section 25.2.5 [alg.replace] before p4: The name of the first
+In section 25.4.5 [alg.replace] before p4: The name of the first
parameter of template replace_copy_if should be "InputIterator"
-instead of "Iterator". According to 17.3.2.1 [type.descriptions] p1 the
+instead of "Iterator". According to 17.5.2.1 [type.descriptions] p1 the
parameter name conveys real normative meaning.
</p>
<hr>
<h3><a name="338"></a>338. is whitespace allowed between `-' and a digit?</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#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-17</p>
+<p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-17 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-From Stage 2 processing in 22.2.2.1.2 [facet.num.get.virtuals], p8 and 9 (the
+From Stage 2 processing in 22.4.2.1.2 [facet.num.get.virtuals], p8 and 9 (the
original text or the text corrected by the proposed resolution of
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
-within a number, but 22.2.3.1 [locale.numpunct], p2, which gives the
+within a number, but 22.4.3.1 [locale.numpunct], p2, which gives the
format for integer and floating point values, says that whitespace is
optional between a plusminus and a sign.
</p>
disallow whitespace between a plusminus and a sign. It might be
worthwhile to consider the fact that the C library stdio facility does
not permit whitespace embedded in numbers and neither does the C or
-C++ core language (the syntax of integer-literals is given in 2.13.1
-[lex.icon], that of floating-point-literals in 2.13.3 [lex.fcon] of the
+C++ core language (the syntax of integer-literals is given in 2.14.2
+[lex.icon], that of floating-point-literals in 2.14.4 [lex.fcon] of the
C++ standard).
</p>
<p><b>Proposed resolution:</b></p>
-<p>Change the first part of 22.2.3.1 [locale.numpunct] paragraph 2 from:</p>
+<p>Change the first part of 22.4.3.1 [locale.numpunct] paragraph 2 from:</p>
<blockquote>
<p>
The syntax for number formats is as follows, where <tt>digit</tt>
<p><b>Rationale:</b></p>
-<p>It's not clear whether the format described in 22.2.3.1 [locale.numpunct] paragraph 2 has any normative weight: nothing in the
+<p>It's not clear whether the format described in 22.4.3.1 [locale.numpunct] paragraph 2 has any normative weight: nothing in the
standard says how, or whether, it's used. However, there's no reason
for it to differ gratuitously from the very specific description of
-numeric processing in 22.2.2.1.2 [facet.num.get.virtuals]. The proposed
+numeric processing in 22.4.2.1.2 [facet.num.get.virtuals]. The proposed
resolution removes all mention of "whitespace" from that format.</p>
<hr>
<h3><a name="339"></a>339. definition of bitmask type restricted to clause 27</h3>
-<p><b>Section:</b> 22.2.1 [category.ctype], 17.3.2.1.2 [bitmask.types] <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-09-17</p>
+<p><b>Section:</b> 22.4.1 [category.ctype], 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-17 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#category.ctype">issues</a> in [category.ctype].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>The ctype_category::mask type is declared to be an enum in 22.2.1
+<p>The ctype_category::mask type is declared to be an enum in 22.4.1
[category.ctype] with p1 then stating that it is a bitmask type, most
-likely referring to the definition of bitmask type in 17.3.2.1.2
+likely referring to the definition of bitmask type in 17.5.2.1.3
[bitmask.types], p1. However, the said definition only applies to
clause 27, making the reference in 22.2.1 somewhat dubious.
</p>
<blockquote><p>
Several types defined in clause 27 are bitmask types. Each bitmask type
can be implemented as an enumerated type that overloads certain operators,
- as an integer type, or as a bitset (23.3.5 [template.bitset]).
+ as an integer type, or as a bitset (20.3.6 [template.bitset]).
</p></blockquote>
<p>to read</p>
<blockquote><p>
}
</pre>
-<p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 [bitmask.types]).</p>
+<p>The type <tt>mask</tt> is a bitmask type (17.5.2.1.3 [bitmask.types]).</p>
</blockquote>
<p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
<hr>
<h3><a name="340"></a>340. interpretation of <tt>has_facet<Facet>(loc)</tt></h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <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-09-18</p>
+<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-18 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It's unclear whether 22.1.1.1.1, p3 says that
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1.1.1 [locale.category], paragraph 3, change
+<p>In 22.3.1.1.1 [locale.category], paragraph 3, change
"that is a member of a standard category" to "shown in Table 51".</p>
<hr>
<h3><a name="341"></a>341. Vector reallocation and swap</h3>
-<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>Section:</b> 23.3.6.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2001-09-27 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>It is a common idiom to reduce the capacity of a vector by swapping it with
an empty one:</p>
// vec is now empty, with minimal capacity
</pre>
-<p>However, the wording of 23.2.6.2 [vector.capacity]paragraph 5 prevents
+<p>However, the wording of 23.3.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
operation.</p>
<p>However, the container requirements state that swap must have constant
-complexity (23.1 [container.requirements] note to table 65).</p>
+complexity (23.2 [container.requirements] note to table 65).</p>
<p>This is an important issue, as reallocation affects the validity of
references and iterators.</p>
<p><b>Proposed resolution:</b></p>
-<p>Add a new paragraph after 23.2.6.2 [vector.capacity] paragraph 5:</p>
+<p>Add a new paragraph after 23.3.6.2 [vector.capacity] paragraph 5:</p>
<blockquote>
<pre> void swap(vector<T,Allocator>& x);
</pre>
<hr>
<h3><a name="345"></a>345. type tm in <cwchar></h3>
-<p><b>Section:</b> 21.5 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Clark Nelson <b>Date:</b> 2001-10-19</p>
+<p><b>Section:</b> 21.6 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2001-10-19 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>C99, and presumably amendment 1 to C90, specify that <wchar.h>
-declares struct tm as an incomplete type. However, table 48 in 21.5
+declares struct tm as an incomplete type. However, table 48 in 21.6
[c.strings] does not mention the type tm as being declared in
<cwchar>. Is this omission intentional or accidental?
</p>
<p><b>Proposed resolution:</b></p>
-<p>In section 21.5 [c.strings], add "tm" to table 48.</p>
+<p>In section 21.6 [c.strings], add "tm" to table 48.</p>
<hr>
<h3><a name="346"></a>346. Some iterator member functions should be const</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#WP">WP</a>
- <b>Submitter:</b> Jeremy Siek <b>Date:</b> 2001-10-20</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#WP">WP</a> status.</p>
+<p><b>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Jeremy Siek <b>Opened:</b> 2001-10-20 <b>Last modified:</b> 2008-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Iterator member functions and operators that do not change the state
of the iterator should be defined as const member functions or as
<p><b>Proposed resolution:</b></p>
-<p>In 24.1 [iterator.requirements] Change the first section of p9 from
+<p>In 24.2 [iterator.concepts] Change the first section of p9 from
"In the following sections, a and b denote values of X..." to
"In the following sections, a and b denote values of type const X...".</p>
<hr>
<h3><a name="347"></a>347. locale::category and bitmask requirements</h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <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, Nathan Myers <b>Date:</b> 2001-10-23</p>
+<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Opened:</b> 2001-10-23 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In 22.1.1.1.1 [locale.category] paragraph 1, the category members
+In 22.3.1.1.1 [locale.category] paragraph 1, the category members
are described as bitmask elements. In fact, the bitmask requirements
-in 17.3.2.1.2 [bitmask.types] don't seem quite right: <tt>none</tt>
+in 17.5.2.1.3 [bitmask.types] don't seem quite right: <tt>none</tt>
and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
<p>In particular, the requirements for <tt>none</tt> interact poorly
<p><b>Proposed resolution:</b></p>
-<p>Replace the first two paragraphs of 22.1.1.1 [locale.types] with:</p>
+<p>Replace the first two paragraphs of 22.3.1.1 [locale.types] with:</p>
<blockquote>
<pre> typedef int category;
</pre>
<blockquote>
<p><b>Option 2:</b> <br>
-Replace the first paragraph of 22.1.1.1 [locale.types] with:</p>
+Replace the first paragraph of 22.3.1.1 [locale.types] with:</p>
<blockquote>
<p>
Valid category values include the enumerated values. In addition, the
<hr>
<h3><a name="349"></a>349. Minor typographical error in ostream_iterator</h3>
-<p><b>Section:</b> 24.5.2 [ostream.iterator] <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-10-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>Section:</b> 24.6.2 [ostream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-10-24 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>24.5.2 [lib.ostream.iterator] states:</p>
<pre> [...]
<p><b>Proposed resolution:</b></p>
<p>
-In 24.5.2 [ostream.iterator], replace <tt>const char* delim</tt> with
+In 24.6.2 [ostream.iterator], replace <tt>const char* delim</tt> with
<tt>const charT* delim</tt>.
</p>
<hr>
<h3><a name="352"></a>352. missing fpos requirements</h3>
-<p><b>Section:</b> 21.1.2 [char.traits.typedefs] <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-12-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>Section:</b> 21.2.2 [char.traits.typedefs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-12-02 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<i>(1)</i>
<hr>
<h3><a name="354"></a>354. Associative container lower/upper bound requirements</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Hans Aberg <b>Date:</b> 2001-12-17</p>
+<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Hans Aberg <b>Opened:</b> 2001-12-17 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Discussions in the thread "Associative container lower/upper bound
<p><b>Proposed resolution:</b></p>
-<p>Change Table 69 of section 23.1.4 [associative.reqmts] indicated entries
+<p>Change Table 69 of section 23.2.4 [associative.reqmts] indicated entries
to:</p>
<blockquote>
<hr>
<h3><a name="355"></a>355. Operational semantics for a.back()</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Yaroslav Mironov <b>Date:</b> 2002-01-23</p>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Yaroslav Mironov <b>Opened:</b> 2002-01-23 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Table 68 "Optional Sequence Operations" in 23.1.1/12
<hr>
<h3><a name="358"></a>358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt></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#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
+<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I don't think <tt>thousands_sep</tt> is being treated correctly after
<hr>
<h3><a name="359"></a>359. num_put<>::do_put (..., bool) undocumented</h3>
-<p><b>Section:</b> 22.2.2.2.1 [facet.num.put.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> 2002-03-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>Section:</b> 22.4.2.2.1 [facet.num.put.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>22.2.2.2.1, p1:</p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove
+<p>In 22.4.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove
the <tt>bool</tt> overload.</p>
<p>
-In 22.2.2.2.2 [facet.num.put.virtuals], p23, make the following changes
+In 22.4.2.2.2 [facet.num.put.virtuals], p23, make the following changes
</p>
<blockquote><p>
<hr>
<h3><a name="360"></a>360. locale mandates inefficient implementation</h3>
-<p><b>Section:</b> 22.1.1 [locale] <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> 2002-03-12</p>
+<p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
22.1.1, p7 (copied below) allows iostream formatters and extractors
<hr>
<h3><a name="362"></a>362. bind1st/bind2nd type safety</h3>
-<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andrew Demkin <b>Date:</b> 2002-04-26</p>
+<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#CD1">CD1</a>
+ <b>Submitter:</b> Andrew Demkin <b>Opened:</b> 2002-04-26 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The definition of bind1st() (D.8 [depr.lib.binders]) can result in
<hr>
<h3><a name="363"></a>363. Missing exception specification in 27.4.2.1.1</h3>
-<p><b>Section:</b> 27.4.2.1.1 [ios::failure] <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 and Marc Paterno <b>Date:</b> 2002-05-20</p>
+<p><b>Section:</b> 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Walter Brown and Marc Paterno <b>Opened:</b> 2002-05-20 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The destructor of ios_base::failure should have an empty throw
<hr>
<h3><a name="364"></a>364. Inconsistent wording in 27.5.2.4.2</h3>
-<p><b>Section:</b> 27.5.2.4.2 [streambuf.virt.buffer] <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, Marc Paterno <b>Date:</b> 2002-05-10</p>
+<p><b>Section:</b> 27.6.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.virt.buffer">issues</a> in [streambuf.virt.buffer].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-27.5.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects
+27.6.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects
clause for seekoff.
</p>
<hr>
<h3><a name="365"></a>365. Lack of const-qualification in clause 27</h3>
-<p><b>Section:</b> 27 [input.output] <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, Marc Paterno <b>Date:</b> 2002-05-10</p>
+<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Some stream and streambuf member functions are declared non-const,
<hr>
<h3><a name="369"></a>369. io stream objects and static ctors</h3>
-<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 2002-07-08</p>
+<p><b>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Ruslan Abdikeev <b>Opened:</b> 2002-07-08 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Is it safe to use standard iostream objects from constructors of
<p><b>Proposed resolution:</b></p>
-<p>Add to 27.3 [iostream.objects], p2, immediately before the last sentence
+<p>Add to 27.4 [iostream.objects], p2, immediately before the last sentence
of the paragraph, the following two sentences:</p>
<blockquote><p>
<hr>
<h3><a name="370"></a>370. Minor error in basic_istream::get</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> Ray Lischner <b>Date:</b> 2002-07-15</p>
+<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-07-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Defect report for description of basic_istream::get (section
-27.6.1.3 [istream.unformatted]), paragraph 15. The description for the
+27.7.1.3 [istream.unformatted]), paragraph 15. The description for the
get function
with the following signature:</p>
<hr>
<h3><a name="371"></a>371. Stability of multiset and multimap member functions</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> Frank Compagner <b>Date:</b> 2002-07-20</p>
+<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Frank Compagner <b>Opened:</b> 2002-07-20 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The requirements for multiset and multimap containers (23.1
<p><b>Proposed resolution:</b></p>
-<p>Add the following to the end of 23.1.4 [associative.reqmts] paragraph 4:
+<p>Add the following to the end of 23.2.4 [associative.reqmts] paragraph 4:
"For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
are <i>stable</i>: they preserve the relative ordering of equivalent
elements.</p>
<hr>
<h3><a name="373"></a>373. Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ?</h3>
-<p><b>Section:</b> 27.6.1.2.1 [istream.formatted.reqmts], 27.6.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Keith Baker <b>Date:</b> 2002-07-23</p>
+<p><b>Section:</b> 27.7.1.2.1 [istream.formatted.reqmts], 27.7.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Keith Baker <b>Opened:</b> 2002-07-23 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts]
+In 27.7.1.2.1 [istream.formatted.reqmts] and 27.7.2.6.1 [ostream.formatted.reqmts]
(exception()&badbit) != 0 is used in testing for rethrow, yet
-exception() is the constructor to class std::exception in 18.6.1 [type.info] that has no return type. Should member function
-exceptions() found in 27.4.4 [ios] be used instead?
+exception() is the constructor to class std::exception in 18.7.1 [type.info] that has no return type. Should member function
+exceptions() found in 27.5.4 [ios] be used instead?
</p>
<p><b>Proposed resolution:</b></p>
<p>
-In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts], change
+In 27.7.1.2.1 [istream.formatted.reqmts] and 27.7.2.6.1 [ostream.formatted.reqmts], change
"(exception()&badbit) != 0" to "(exceptions()&badbit) != 0".
</p>
<hr>
<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>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-14 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In Section 27.7.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph
+In Section 27.8.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph
14 all contain references to "basic_ios::" which should be
"ios_base::".
</p>
<hr>
<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>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-14 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In Section 27.7.1.4 [stringbuf.virtuals], Table 90, the implication is that
+In Section 27.8.1.4 [stringbuf.virtuals], Table 90, the implication is that
the four conditions should be mutually exclusive, but they are not.
The first two cases, as written, are subcases of the third.</p>
<hr>
<h3><a name="379"></a>379. nonsensical ctype::do_widen() requirement</h3>
-<p><b>Section:</b> 22.2.1.1.2 [locale.ctype.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> 2002-09-06</p>
+<p><b>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
<p><b>Proposed resolution:</b></p>
<p>
-Replace the last sentence of 22.2.1.1.2 [locale.ctype.virtuals], p11 with the
+Replace the last sentence of 22.4.1.1.2 [locale.ctype.virtuals], p11 with the
following text:
</p>
<pre> For any named ctype category with a ctype<char> facet ctc
<hr>
<h3><a name="380"></a>380. typos in codecvt tables 53 and 54</h3>
-<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <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> 2002-09-06</p>
+<p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Tables 53 and 54 in 22.2.1.5 [locale.codecvt.byname] are both titled "convert
+Tables 53 and 54 in 22.4.1.5 [locale.codecvt.byname] are both titled "convert
result values," when surely "do_in/do_out result values" must have
been intended for Table 53 and "do_unshift result values" for Table
54.
<hr>
<h3><a name="381"></a>381. detection of invalid mbstate_t in codecvt</h3>
-<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <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> 2002-09-06</p>
+<p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
All but one codecvt member functions that take a state_type argument
<hr>
<h3><a name="383"></a>383. Bidirectional iterator assertion typo</h3>
-<p><b>Section:</b> 24.1.4 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> ysapir (submitted via comp.std.c++) <b>Date:</b> 2002-10-17</p>
+<p><b>Section:</b> 24.2.5 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> ysapir (submitted via comp.std.c++) <b>Opened:</b> 2002-10-17 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Following a discussion on the boost list regarding end iterators and
I have checked this newsgroup, as well as attempted a search of the
Active/Defect/Closed Issues List on the site for the words "s is
derefer" so I believe this has not been proposed before. Furthermore,
-the "Lists by Index" mentions only DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> on section
-24.1.4, and DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> is not related to this issue.
+the "Lists by Index" mentions only DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a> on section
+24.1.4, and DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a> is not related to this issue.
</p>
<p>
<hr>
<h3><a name="384"></a>384. equal_range has unimplementable runtime complexity</h3>
-<p><b>Section:</b> 25.3.3.3 [equal.range] <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> 2002-10-18</p>
+<p><b>Section:</b> 25.5.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Hans Bos <b>Opened:</b> 2002-10-18 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#equal.range">issues</a> in [equal.range].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Section 25.3.3.3 [equal.range]
+Section 25.5.3.3 [equal.range]
states that at most 2 * log(last - first) + 1
comparisons are allowed for equal_range.
</p>
<p><b>Proposed resolution:</b></p>
-<p>In 25.3.3.1 [lower.bound]/4, change <tt>log(last - first) + 1</tt>
+<p>In 25.5.3.1 [lower.bound]/4, change <tt>log(last - first) + 1</tt>
to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
-<p>In 25.3.3.2 [upper.bound]/4, change <tt>log(last - first) + 1</tt>
+<p>In 25.5.3.2 [upper.bound]/4, change <tt>log(last - first) + 1</tt>
to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
-<p>In 25.3.3.3 [equal.range]/4, change <tt>2*log(last - first) + 1</tt>
+<p>In 25.5.3.3 [equal.range]/4, change <tt>2*log(last - first) + 1</tt>
to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
<p><i>[Matt provided wording]</i></p>
<hr>
<h3><a name="386"></a>386. Reverse iterator's operator[] has impossible return type</h3>
-<p><b>Section:</b> 24.4.1.3.11 [reverse.iter.op-=] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-10-23</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>Section:</b> 24.5.1.2.11 [reverse.iter.op-=] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-10-23 <b>Last modified:</b> 2009-05-01</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>In 24.4.1.3.11 [reverse.iter.op-=], <tt>reverse_iterator<>::operator[]</tt>
+<p>In 24.5.1.2.11 [reverse.iter.op-=], <tt>reverse_iterator<>::operator[]</tt>
is specified as having a return type of <tt>reverse_iterator::reference</tt>,
which is the same as <tt>iterator_traits<Iterator>::reference</tt>.
(Where <tt>Iterator</tt> is the underlying iterator type.)</p>
to <tt>Iterator</tt>'s value type. The return type specified for
reverse_iterator's operator[] would thus appear to be impossible.</p>
-<p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, the type of
+<p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, the type of
<tt>a[n]</tt> will continue to be required (for random access
iterators) to be convertible to the value type, and also <tt>a[n] =
t</tt> will be a valid expression. Implementations of
<p><b>Proposed resolution:</b></p>
-<p>In 24.4.1.2 [reverse.iter.requirements] change:</p>
+<p>In [reverse.iter.requirements] change:</p>
<blockquote>
<pre>reference operator[](difference_type n) const;
<p>to:</p>
<blockquote>
-<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see 24.1.5 [random.access.iterators]
+<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see 24.2.6 [random.access.iterators]
</pre>
</blockquote>
<hr>
+<h3><a name="387"></a>387. std::complex over-encapsulated</h3>
+<p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The absence of explicit description of std::complex<T> layout
+makes it imposible to reuse existing software developed in traditional
+languages like Fortran or C with unambigous and commonly accepted
+layout assumptions. There ought to be a way for practitioners to
+predict with confidence the layout of std::complex<T> whenever T
+is a numerical datatype. The absence of ways to access individual
+parts of a std::complex<T> object as lvalues unduly promotes
+severe pessimizations. For example, the only way to change,
+independently, the real and imaginary parts is to write something like
+</p>
+
+<pre>complex<T> z;
+// ...
+// set the real part to r
+z = complex<T>(r, z.imag());
+// ...
+// set the imaginary part to i
+z = complex<T>(z.real(), i);
+</pre>
+
+<p>
+At this point, it seems appropriate to recall that a complex number
+is, in effect, just a pair of numbers with no particular invariant to
+maintain. Existing practice in numerical computations has it that a
+complex number datatype is usually represented by Cartesian
+coordinates. Therefore the over-encapsulation put in the specification
+of std::complex<> is not justified.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>Add the following requirements to 26.4 [complex.numbers] as 26.3/4:</p>
+<blockquote>
+<p>If z is an lvalue expression of type cv std::complex<T> then</p>
+
+<ul>
+<li>the expression reinterpret_cast<cv T(&)[2]>(z)
+is well-formed; and</li>
+<li>reinterpret_cast<cv T(&)[2]>(z)[0]designates the
+real part of z; and</li>
+<li>reinterpret_cast<cv T(&)[2]>(z)[1]designates the
+imaginary part of z.</li>
+</ul>
+
+<p>
+Moreover, if a is an expression of pointer type cv complex<T>*
+and the expression a[i] is well-defined for an integer expression
+i then:
+</p>
+
+<ul>
+<li>reinterpret_cast<cv T*>(a)[2*i] designates the real
+part of a[i]; and</li>
+<li>reinterpret_cast<cv T*>(a)[2*i+1] designates the
+imaginary part of a[i].</li>
+</ul>
+</blockquote>
+
+<p>
+In 26.4.2 [complex] and 26.4.3 [complex.special] add the following member functions
+(changing <tt>T</tt> to concrete types as appropriate for the specializations).
+</p>
+
+<blockquote><pre>void real(T);
+void imag(T);
+</pre></blockquote>
+
+<p>
+Add to 26.4.4 [complex.members]
+</p>
+
+<blockquote>
+<pre>T real() const;
+</pre>
+<blockquote>
+<i>Returns:</i> the value of the real component
+</blockquote>
+<pre>void real(T val);
+</pre>
+<blockquote>
+Assigns val to the real component.
+</blockquote>
+<pre>T imag() const;
+</pre>
+<blockquote>
+<i>Returns:</i> the value of the imaginary component
+</blockquote>
+<pre>void imag(T val);
+</pre>
+<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
+ of this proposal: retrieving elements of the complex number as
+ lvalues. An alternative: continue to have real() and imag() return
+ rvalues, but add set_real() and set_imag(). Straw poll: return
+ lvalues - 2, add setter functions - 5. Related issue: do we want
+ reinterpret_cast as the interface for converting a complex to an
+ array of two reals, or do we want to provide a more explicit way of
+ doing it? Howard will try to resolve this issue for the next
+ meeting.]</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><i>[
+Pre-Sophia Antipolis, Howard adds:
+]</i></p>
+
+
+<blockquote>
+Added the members to 26.4.3 [complex.special] and changed from Ready to Review.
+</blockquote>
+
+<p><i>[
+Post-Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Moved from WP back to Ready so that the "and 26.4.3 [complex.special]" in the proposed
+resolution can be officially applied.
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>The LWG believes that C99 compatibility would be enough
+justification for this change even without other considerations. All
+existing implementations already have the layout proposed here.</p>
+
+
+
+
+
+<hr>
<h3><a name="389"></a>389. Const overload of valarray::operator[] returns by value</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#WP">WP</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
+<p><b>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a></p>
<p><b>Discussion:</b></p>
<p>Consider the following program:</p>
<p><b>Proposed resolution:</b></p>
-<p>In the class synopsis in 26.5.2 [template.valarray], and in
-26.5.2.3 [valarray.access] just above paragraph 1, change</p>
+<p>In the class synopsis in 26.6.2 [template.valarray], and in
+26.6.2.3 [valarray.access] just above paragraph 1, change</p>
<pre> T operator[](size_t const);
</pre>
<p>to</p>
<hr>
<h3><a name="391"></a>391. non-member functions specified as const</h3>
-<p><b>Section:</b> 22.1.3.2 [conversions] <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> 2002-12-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 22.3.3.2 [conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> James Kanze <b>Opened:</b> 2002-12-10 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The specifications of toupper and tolower both specify the functions as
const, althought they are not member functions, and are not specified as
-const in the header file synopsis in section 22.1 [locales].
+const in the header file synopsis in section 22.3 [locales].
</p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.3.2 [conversions], remove <tt>const</tt> from the function
+<p>In 22.3.3.2 [conversions], remove <tt>const</tt> from the function
declarations of std::toupper and std::tolower</p>
<hr>
<h3><a name="395"></a>395. inconsistencies in the definitions of rand() and random_shuffle()</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> James Kanze <b>Date:</b> 2003-01-03</p>
+<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> James Kanze <b>Opened:</b> 2003-01-03 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In 26.7 [c.math], the C++ standard refers to the C standard for the
+In 26.8 [c.math], the C++ standard refers to the C standard for the
definition of rand(); in the C standard, it is written that "The
implementation shall behave as if no library function calls the rand
function."
</p>
<p>
-In 25.2.12 [alg.random.shuffle], there is no specification as to
+In 25.4.12 [alg.random.shuffle], there is no specification as to
how the two parameter version of the function generates its random
value. I believe that all current implementations in fact call rand()
(in contradiction with the requirement avove); if an implementation does
<hr>
+<h3><a name="396"></a>396. what are characters zero and one</h3>
+<p><b>Section:</b> 20.3.6.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+ <p>
+23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
+having the value of 0 or 1 but there is no definition of what
+that means for charT other than char and wchar_t. And even for
+those two types, the values 0 and 1 are not actually what is
+intended -- the values '0' and '1' are. This, along with the
+converse problem in the description of to_string() in 23.3.5.2,
+p33, looks like a defect remotely related to DR 303.
+ </p>
+ <p>
+http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
+ </p>
+ <pre>23.3.5.1:
+ -6- An element of the constructed string has value zero if the
+ corresponding character in str, beginning at position pos,
+ is 0. Otherwise, the element has the value one.
+ </pre>
+ <pre>23.3.5.2:
+ -33- Effects: Constructs a string object of the appropriate
+ type and initializes it to a string of length N characters.
+ Each character is determined by the value of its
+ corresponding bit position in *this. Character position N
+ ?- 1 corresponds to bit position zero. Subsequent decreasing
+ character positions correspond to increasing bit positions.
+ Bit value zero becomes the character 0, bit value one becomes
+ the character 1.
+ </pre>
+ <p>
+Also note the typo in 23.3.5.1, p6: the object under construction
+is a bitset, not a string.
+ </p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+We note that <tt>bitset</tt> has been moved from section 23 to section 20, by
+another issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>) previously resolved at this meeting.
+</p>
+<p>
+Disposition: move to ready.
+</p>
+<p>
+We request that Howard submit a separate issue regarding the three to_string overloads.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>Change the constructor's function declaration immediately before
+20.3.6.1 [bitset.cons] p3 to:</p>
+<pre> template <class charT, class traits, class Allocator>
+ explicit
+ bitset(const basic_string<charT, traits, Allocator>& str,
+ typename basic_string<charT, traits, Allocator>::size_type pos = 0,
+ typename basic_string<charT, traits, Allocator>::size_type n =
+ basic_string<charT, traits, Allocator>::npos,
+ charT zero = charT('0'), charT one = charT('1'))
+</pre>
+<p>Change the first two sentences of 20.3.6.1 [bitset.cons] p6 to: "An
+element of the constructed string has value 0 if the corresponding
+character in <i>str</i>, beginning at position <i>pos</i>,
+is <i>zero</i>. Otherwise, the element has the value 1.</p>
+
+<p>Change the text of the second sentence in 23.3.5.1, p5 to read:
+ "The function then throws invalid_argument if any of the rlen
+ characters in str beginning at position pos is other than <i>zero</i>
+ or <i>one</i>. The function uses traits::eq() to compare the character
+ values."
+</p>
+
+<p>Change the declaration of the <tt>to_string</tt> member function
+ immediately before 20.3.6.2 [bitset.members] p33 to:</p>
+<pre> template <class charT, class traits, class Allocator>
+ basic_string<charT, traits, Allocator>
+ to_string(charT zero = charT('0'), charT one = charT('1')) const;
+</pre>
+<p>Change the last sentence of 20.3.6.2 [bitset.members] p33 to: "Bit
+ value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
+ character <tt><i>one</i></tt>.</p>
+<p>Change 20.3.6.3 [bitset.operators] p8 to:</p>
+<p><b>Returns</b>:</p>
+<pre> os << x.template to_string<charT,traits,allocator<charT> >(
+ use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('0'),
+ use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('1'));
+</pre>
+
+
+<p><b>Rationale:</b></p>
+<p>There is a real problem here: we need the character values of '0'
+ and '1', and we have no way to get them since strings don't have
+ imbued locales. In principle the "right" solution would be to
+ provide an extra object, either a ctype facet or a full locale,
+ which would be used to widen '0' and '1'. However, there was some
+ discomfort about using such a heavyweight mechanism. The proposed
+ resolution allows those users who care about this issue to get it
+ right.</p>
+<p>We fix the inserter to use the new arguments. Note that we already
+ fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>.</p>
+
+
+
+<p><i>[
+post Bellevue:
+]</i></p>
+
+
+<blockquote>
+We are happy with the resolution as proposed, and we move this to Ready.
+</blockquote>
+
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+The proposed wording neglects the 3 newer to_string overloads.
+</blockquote>
+
+
+
+
+<hr>
<h3><a name="400"></a>400. redundant type cast in lib.allocator.members</h3>
-<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
+<p><b>Section:</b> 20.8.6.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-20.7.5.1 [allocator.members] allocator members, contains
+20.8.6.1 [allocator.members] allocator members, contains
the following 3 lines:
</p>
<hr>
<h3><a name="401"></a>401. incorrect type casts in table 32 in lib.allocator.requirements</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#WP">WP</a>
- <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
+<p><b>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I think that in par2 of [default.con.req] the last two
<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.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
+<p><b>Section:</b> X [allocator.requirements], 20.8.6.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This applies to the new expression that is contained in both par12 of
-20.7.5.1 [allocator.members] and in par2 (table 32) of [default.con.req].
+20.8.6.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.7.5.1 [allocator.members] contains the following 3 lines:</p>
+<p>20.8.6.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);
<hr>
<h3><a name="403"></a>403. basic_string::swap should not throw exceptions</h3>
-<p><b>Section:</b> 21.3.6.8 [string::swap] <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> 2003-03-25</p>
+<p><b>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2003-03-25 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-std::basic_string, 21.3 [basic.string] paragraph 2 says that
+std::basic_string, 21.4 [basic.string] paragraph 2 says that
basic_string "conforms to the requirements of a Sequence, as specified
in (23.1.1)." The sequence requirements specified in (23.1.1) to not
include any prohibition on swap members throwing exceptions.
</p>
<p>
-Section 23.1 [container.requirements] paragraph 10 does limit conditions under
+Section 23.2 [container.requirements] paragraph 10 does limit conditions under
which exceptions may be thrown, but applies only to "all container
types defined in this clause" and so excludes basic_string::swap
because it is defined elsewhere.
</p>
<p>
-Eric Niebler points out that 21.3 [basic.string] paragraph 5 explicitly
+Eric Niebler points out that 21.4 [basic.string] paragraph 5 explicitly
permits basic_string::swap to invalidates iterators, which is
-disallowed by 23.1 [container.requirements] paragraph 10. Thus the standard would
+disallowed by 23.2 [container.requirements] paragraph 10. Thus the standard would
be contradictory if it were read or extended to read as having
-basic_string meet 23.1 [container.requirements] paragraph 10 requirements.
+basic_string meet 23.2 [container.requirements] paragraph 10 requirements.
</p>
<p>
Yet several LWG members have expressed the belief that the original
intent was that basic_string::swap should not throw exceptions as
-specified by 23.1 [container.requirements] paragraph 10, and that the standard is
+specified by 23.2 [container.requirements] paragraph 10, and that the standard is
unclear on this issue. The complexity of basic_string::swap is
specified as "constant time", indicating the intent was to avoid
copying (which could cause a bad_alloc or other exception). An
<p>
Note: There remains long standing concern over whether or not it is
-possible to reasonably meet the 23.1 [container.requirements] paragraph 10 swap
+possible to reasonably meet the 23.2 [container.requirements] paragraph 10 swap
requirements when allocators are unequal. The specification of
basic_string::swap exception requirements is in no way intended to
address, prejudice, or otherwise impact that concern.
<p><b>Proposed resolution:</b></p>
<p>
-In 21.3.6.8 [string::swap], add a throws clause:
+In 21.4.6.8 [string::swap], add a throws clause:
</p>
<p>
<hr>
<h3><a name="404"></a>404. May a replacement allocation function be declared inline?</h3>
-<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>Section:</b> 17.6.3.6 [replacement.functions], 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-04-24 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The eight basic dynamic memory allocation functions (single-object
<p>
Three different parts of the standard mention requirements on
-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].
+replacement functions: 17.6.3.6 [replacement.functions], 18.6.1.1 [new.delete.single]
+and 18.6.1.2 [new.delete.array], and 3.7.3 [basic.stc.auto].
</p>
<p>None of these three places say whether a replacement function may
- be declared inline. 18.5.1.1 [new.delete.single] paragraph 2 specifies a
+ be declared inline. 18.6.1.1 [new.delete.single] paragraph 2 specifies a
signature for the replacement function, but that's not enough:
the <tt>inline</tt> specifier is not part of a function's signature.
One might also reason from 7.1.2 [dcl.fct.spec] paragraph 2, which
<p><b>Proposed resolution:</b></p>
<p>
-Add a new sentence to the end of 17.4.3.5 [replacement.functions] paragraph 3:
+Add a new sentence to the end of 17.6.3.6 [replacement.functions] paragraph 3:
"The program's definitions shall not be specified as <tt>inline</tt>.
No diagnostic is required."
</p>
<hr>
<h3><a name="405"></a>405. qsort and POD</h3>
-<p><b>Section:</b> 25.4 [alg.c.library] <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> 2003-04-08</p>
+<p><b>Section:</b> 25.6 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2003-04-08 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Section 25.4 [alg.c.library] describes bsearch and qsort, from the C
+Section 25.6 [alg.c.library] describes bsearch and qsort, from the C
standard library. Paragraph 4 does not list any restrictions on qsort,
but it should limit the base parameter to point to POD. Presumably,
qsort sorts the array by copying bytes, which requires POD.
<p><b>Proposed resolution:</b></p>
<p>
-In 25.4 [alg.c.library] paragraph 4, just after the declarations and
+In 25.6 [alg.c.library] paragraph 4, just after the declarations and
before the nonnormative note, add these words: "both of which have the
same behavior as the original declaration. The behavior is undefined
unless the objects in the array pointed to by <i>base</i> are of POD
<hr>
<h3><a name="406"></a>406. vector::insert(s) exception safety</h3>
-<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>Section:</b> 23.3.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2003-04-27 <b>Last modified:</b> 2009-05-01</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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There is a possible defect in the standard: the standard text was
<p><b>Proposed resolution:</b></p>
-<p>Replace 23.2.6.4 [vector.modifiers] paragraph 1 with:</p>
+<p>Replace 23.3.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
<hr>
<h3><a name="407"></a>407. Can singular iterators be destroyed?</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#WP">WP</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03 <b>Last modified:</b> 2008-09-30</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Clause 24.1 [iterator.requirements], paragraph 5, says that the only expression
+Clause 24.2 [iterator.concepts], paragraph 5, says that the only expression
that is defined for a singular iterator is "an assignment of a
non-singular value to an iterator that holds a singular value". This
means that destroying a singular iterator (e.g. letting an automatic
<hr>
<h3><a name="409"></a>409. Closing an fstream should clear error state</h3>
-<p><b>Section:</b> 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
+<p><b>Section:</b> 27.9.1.9 [ifstream.members], 27.9.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03 <b>Last modified:</b> 2009-05-01</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-A strict reading of 27.8.1 [fstreams] shows that opening or
+A strict reading of 27.9.1 [fstreams] shows that opening or
closing a basic_[io]fstream does not affect the error bits. This
means, for example, that if you read through a file up to EOF, and
then close the stream and reopen it at the beginning of the file,
<p><b>Proposed resolution:</b></p>
-<p>Change 27.8.1.9 [ifstream.members], para. 3 from:</p>
+<p>Change 27.9.1.9 [ifstream.members], para. 3 from:</p>
<blockquote><p>
Calls rdbuf()->open(s,mode|in). If that function returns a null
ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
</p></blockquote>
-<p>Change 27.8.1.13 [ofstream.members], para. 3 from:</p>
+<p>Change 27.9.1.13 [ofstream.members], para. 3 from:</p>
<blockquote><p>Calls rdbuf()->open(s,mode|out). If that function
returns a null pointer, calls setstate(failbit) (which may throw
ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
</p></blockquote>
-<p>Change 27.8.1.17 [fstream.members], para. 3 from:</p>
+<p>Change 27.9.1.17 [fstream.members], para. 3 from:</p>
<blockquote><p>Calls rdbuf()->open(s,mode), If that function returns
a null pointer, calls setstate(failbit), (which may throw
<hr>
<h3><a name="410"></a>410. Missing semantics for stack and queue comparison operators</h3>
-<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>Section:</b> 23.3.4.1 [list.cons], 23.3.4.3 [list.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Hans Bos <b>Opened:</b> 2003-06-07 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Sections 23.2.4.1 [list.cons] and 23.2.4.3 [list.modifiers] list
+Sections 23.3.4.1 [list.cons] and 23.3.4.3 [list.modifiers] list
comparison operators (==, !=, <, <=, >, =>) for queue and
-stack. Only the semantics for queue::operator== (23.2.4.1 [list.cons] par2) and queue::operator< (23.2.4.1 [list.cons]
+stack. Only the semantics for queue::operator== (23.3.4.1 [list.cons] par2) and queue::operator< (23.3.4.1 [list.cons]
par3) are defined.
</p>
<p><b>Proposed resolution:</b></p>
-<p>Add the following new paragraphs after 23.2.4.1 [list.cons]
+<p>Add the following new paragraphs after 23.3.4.1 [list.cons]
paragraph 3:</p>
<blockquote>
</blockquote>
-<p>Add the following paragraphs at the end of 23.2.4.3 [list.modifiers]:</p>
+<p>Add the following paragraphs at the end of 23.3.4.3 [list.modifiers]:</p>
<blockquote>
<hr>
<h3><a name="411"></a>411. Wrong names of set member functions</h3>
-<p><b>Section:</b> 25.3.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Frey <b>Date:</b> 2003-07-09</p>
+<p><b>Section:</b> 25.5.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2003-07-09 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.set.operations">issues</a> in [alg.set.operations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-25.3.5 [alg.set.operations] paragraph 1 reads:
+25.5.5 [alg.set.operations] paragraph 1 reads:
"The semantics of the set operations are generalized to multisets in a
standard way by defining union() to contain the maximum number of
occurrences of every element, intersection() to contain the minimum, and
<hr>
<h3><a name="412"></a>412. Typo in 27.4.4.3</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#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-07-10</p>
+<p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-07-10 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#429">429</a></p>
<p><b>Discussion:</b></p>
<p>
-The Effects clause in 27.4.4.3 [iostate.flags] paragraph 5 says that the
+The Effects clause in 27.5.4.3 [iostate.flags] paragraph 5 says that the
function only throws if the respective bits are already set prior to
the function call. That's obviously not the intent. The typo ought to
be corrected and the text reworded as: "If (<i>state</i> &
<p><b>Proposed resolution:</b></p>
<p>
-In 27.4.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() &
+In 27.5.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() &
exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
& exceptions()) == 0".
</p>
<hr>
<h3><a name="413"></a>413. Proposed resolution to LDR#64 still wrong</h3>
-<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2003-07-13</p>
+<p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Bo Persson <b>Opened:</b> 2003-07-13 <b>Last modified:</b> 2009-05-01</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The second sentence of the proposed resolution says:
<hr>
<h3><a name="414"></a>414. Which iterators are invalidated by v.erase()?</h3>
-<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>Section:</b> 23.3.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-08-19 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider the following code fragment:
<p><b>Proposed resolution:</b></p>
<p>
-In 23.2.6.4 [vector.modifiers] paragraph 3, change "Invalidates all the
+In 23.3.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".
<hr>
<h3><a name="415"></a>415. behavior of std::ws</h3>
-<p><b>Section:</b> 27.6.1.4 [istream.manip] <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>Section:</b> 27.7.1.4 [istream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to 27.6.1.4, the ws() manipulator is not required to construct
<p><b>Proposed resolution:</b></p>
<p>
-Add to 27.6.1.4 [istream.manip], immediately before the first sentence
+Add to 27.7.1.4 [istream.manip], immediately before the first sentence
of paragraph 1, the following text:
</p>
<hr>
<h3><a name="416"></a>416. definitions of XXX_MIN and XXX_MAX macros in climits</h3>
-<p><b>Section:</b> 18.2.2 [c.limits] <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>Section:</b> 18.3.2 [c.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<p><b>Proposed resolution:</b></p>
<p>
-Change 18.2.2 [c.limits], paragraph 2:
+Change 18.3.2 [c.limits], paragraph 2:
</p>
<blockquote><p>
<hr>
<h3><a name="420"></a>420. is std::FILE a complete type?</h3>
-<p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
7.19.1, p2, of C99 requires that the FILE type only be declared in
<p><b>Proposed resolution:</b></p>
-<p>In the first sentence of 27.8.1 [fstreams] paragraph 2, change
+<p>In the first sentence of 27.9.1 [fstreams] paragraph 2, change
"defined" to "declared".</p>
<hr>
<h3><a name="422"></a>422. explicit specializations of member functions of class templates</h3>
-<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>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It has been suggested that 17.4.3.1, p1 may or may not allow programs to
<p><b>Proposed resolution:</b></p>
<p>
- Add the following sentence to 17.4.3.2 [reserved.names], p1:
+ Add the following sentence to 17.6.3.3 [reserved.names], p1:
</p>
<blockquote><p>
<hr>
<h3><a name="425"></a>425. return value of std::get_temporary_buffer</h3>
-<p><b>Section:</b> 20.7.8 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 20.8.9 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The standard is not clear about the requirements on the value returned from
<p><b>Proposed resolution:</b></p>
-<p>Change 20.5.3 [meta.help] paragraph 2 from "...or a pair of 0
+<p>Change 20.6.3 [meta.help] paragraph 2 from "...or a pair of 0
values if no storage can be obtained" to "...or a pair of 0 values if
no storage can be obtained or if <i>n</i> <= 0."</p>
<p><i>[Kona: Matt provided wording]</i></p>
<hr>
<h3><a name="426"></a>426. search_n(), fill_n(), and generate_n() with negative n</h3>
-<p><b>Section:</b> 25.1.12 [alg.search], 25.2.6 [alg.fill], 25.2.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<p><b>Section:</b> 25.3.12 [alg.search], 25.4.6 [alg.fill], 25.4.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The complexity requirements for these function templates are incorrect
<hr>
<h3><a name="428"></a>428. string::erase(iterator) validity</h3>
-<p><b>Section:</b> 21.3.6.5 [string::erase] <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>Section:</b> 21.4.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::erase">issues</a> in [string::erase].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
<p><b>Proposed resolution:</b></p>
-<p>Remove 21.3.6.5 [string::erase] paragraph 5.</p>
+<p>Remove 21.4.6.5 [string::erase] paragraph 5.</p>
<p><b>Rationale:</b></p>
<hr>
<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>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Christian W Brock <b>Opened:</b> 2003-09-24 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.7.1.3 par 8 says:</p>
<blockquote><p>
<blockquote>
<p>
-12- _ If (newoff + off) < 0, or if (newoff + off) refers to an
-uninitialized character (as defined in 27.7.1.3 [stringbuf.members]
+uninitialized character (as defined in 27.8.1.3 [stringbuf.members]
paragraph 1), the positioning operation fails. Otherwise, the function
assigns xbeg + newoff + off to the next pointer xnext .
</p>
<hr>
<h3><a name="434"></a>434. bitset::to_string() hard to use</h3>
-<p><b>Section:</b> 23.3.5.2 [bitset.members] <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> 2003-10-15</p>
+<p><b>Section:</b> 20.3.6.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15 <b>Last modified:</b> 2009-05-01</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It has been pointed out a number of times that the bitset to_string() member
<hr>
<h3><a name="435"></a>435. bug in DR 25</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> 2003-10-15</p>
+<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="436"></a>436. are cv-qualified facet types valid facets?</h3>
-<p><b>Section:</b> 22.1.1.1.2 [locale.facet] <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-10-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 22.3.1.1.2 [locale.facet] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Is "const std::ctype<char>" a valid template argument to has_facet, use_facet,
<hr>
<h3><a name="438"></a>438. Ambiguity in the "do the right thing" clause</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2003-10-20</p>
+<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2003-10-20 <b>Last modified:</b> 2009-05-01</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>Section 23.1.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem
+<p>Section 23.2.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem
noticed with statements like:</p>
<pre>vector<int> v(10, 1);
</pre>
<p><b>Proposed resolution:</b></p>
-<p>Replace 23.1.3 [sequence.reqmts] paragraphs 9 - 11 with:</p>
+<p>Replace 23.2.3 [sequence.reqmts] paragraphs 9 - 11 with:</p>
<p>For every sequence defined in this clause and in clause lib.strings:</p>
<hr>
<h3><a name="441"></a>441. Is fpos::state const?</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#WP">WP</a>
- <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-17</p>
+<p><b>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-17 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In section 27.4.3.1 [fpos.members] fpos<stateT>::state() is declared
-non const, but in section 27.4.3 [fpos] it is declared const.
+In section 27.5.3.1 [fpos.members] fpos<stateT>::state() is declared
+non const, but in section 27.5.3 [fpos] it is declared const.
</p>
<p><b>Proposed resolution:</b></p>
<p>
-In section 27.4.3.1 [fpos.members], change the declaration of
+In section 27.5.3.1 [fpos.members], change the declaration of
<tt>fpos<stateT>::state()</tt> to const.
</p>
<hr>
<h3><a name="442"></a>442. sentry::operator bool() inconsistent signature</h3>
-<p><b>Section:</b> 27.6.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-18</p>
+<p><b>Section:</b> 27.7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-18 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In section 27.6.2.4 [ostream::sentry] paragraph 4, in description part
+In section 27.7.2.4 [ostream::sentry] paragraph 4, in description part
basic_ostream<charT, traits>::sentry::operator bool() is declared
as non const, but in section 27.6.2.3, in synopsis it is declared
const.
<p><b>Proposed resolution:</b></p>
<p>
-In section 27.6.2.4 [ostream::sentry] paragraph 4, change the declaration
+In section 27.7.2.4 [ostream::sentry] paragraph 4, change the declaration
of <tt>sentry::operator bool()</tt> to const.
</p>
<hr>
<h3><a name="443"></a>443. filebuf::close() inconsistent use of EOF</h3>
-<p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</p>
+<p><b>Section:</b> 27.9.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-20 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In section 27.8.1.4 [filebuf.members] par6, in effects description of
+In section 27.9.1.4 [filebuf.members] par6, in effects description of
basic_filebuf<charT, traits>::close(), overflow(EOF) is used twice;
should be overflow(traits::eof()).
</p>
<hr>
<h3><a name="444"></a>444. Bad use of casts in fstream</h3>
-<p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</p>
+<p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-20 <b>Last modified:</b> 2009-05-01</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>27.8.1.9 [ifstream.members] p1, 27.8.1.13 [ofstream.members] p1,
-27.8.1.17 [fstream.members] p1 seems have same problem as exposed in
+<p>27.9.1.9 [ifstream.members] p1, 27.9.1.13 [ofstream.members] p1,
+27.9.1.17 [fstream.members] p1 seems have same problem as exposed in
LWG issue
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
</p>
<hr>
<h3><a name="445"></a>445. iterator_traits::reference unspecified for some iterator categories</h3>
-<p><b>Section:</b> 24.3.1 [iterator.traits] <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-12-09</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>Section:</b> D.10.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2003-12-09 <b>Last modified:</b> 2009-05-01</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.traits">issues</a> in [iterator.traits].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The standard places no restrictions at all on the reference type
<p><b>Proposed resolution:</b></p>
-<p>In 24.3.1 [iterator.traits], after:</p>
+<p>In D.10.1 [iterator.traits], after:</p>
<blockquote><p>
be defined as the iterator's difference type, value type and iterator
respectively.</p>
</blockquote>
-<p>In 24.3.1 [iterator.traits], change:</p>
+<p>In D.10.1 [iterator.traits], change:</p>
<blockquote><p>
In the case of an output iterator, the types</p>
<p>may be defined as <tt>void</tt>.</p>
</blockquote>
-<p>In 24.5.3 [istreambuf.iterator], change:</p>
+<p>In 24.6.3 [istreambuf.iterator], change:</p>
<blockquote>
<pre>typename traits::off_type, charT*, charT&>
</pre>
<hr>
<h3><a name="448"></a>448. Random Access Iterators over abstract classes</h3>
-<p><b>Section:</b> 24.1.5 [random.access.iterators] <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> 2004-01-07</p>
+<p><b>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-01-07 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 76, the random access iterator requirement table, says that the
<hr>
<h3><a name="449"></a>449. Library Issue 306 Goes Too Far</h3>
-<p><b>Section:</b> 18.1 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2004-01-15</p>
+<p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2004-01-15 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Original text:</p>
<blockquote><p>
<hr>
<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>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<pre> pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
ios_base::openmode);
<hr>
<h3><a name="455"></a>455. cerr::tie() and wcerr::tie() are overspecified</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#DR">DR</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
+<p><b>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2009-05-01</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#DR">DR</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Both cerr::tie() and wcerr::tie() are obliged to be null at program
<hr>
<h3><a name="456"></a>456. Traditional C header files are overspecified</h3>
-<p><b>Section:</b> 17.4.1.2 [headers] <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>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The C++ Standard effectively requires that the traditional C headers
<p><b>Proposed resolution:</b></p>
<p>
-Add to 17.4.1.2 [headers], para. 4:
+Add to 17.6.1.2 [headers], para. 4:
</p>
<blockquote><p>
namespace scope<ins>.</ins> <del>of the namespace <tt>std</tt> and is followed
by an explicit <i>using-declaration</i> (7.3.3 [namespace.udecl]).</del>
<ins>It is unspecified whether these names are first declared or defined within
-namespace scope (3.3.5 [basic.scope.namespace]) of the namespace
+namespace scope (3.3.6 [basic.scope.namespace]) of the namespace
<tt>std</tt> and are then injected into the global namespace scope by explicit
using-declarations (7.3.3 [namespace.udecl]).</ins>
</p>
<hr>
<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>Section:</b> 20.3.6.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dag Henriksson <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2009-05-01</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The constructor from unsigned long says it initializes "the first M
<p><b>Proposed resolution:</b></p>
-<p>In 23.3.5.1 [bitset.cons] paragraph 2, change "M is the smaller of
+<p>In 20.3.6.1 [bitset.cons] paragraph 2, change "M is the smaller of
N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
"<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
the value representation (section 3.9 [basic.types]) of <tt>unsigned
<hr>
<h3><a name="460"></a>460. Default modes missing from basic_fstream member specifications</h3>
-<p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Ben Hutchings <b>Date:</b> 2004-04-01</p>
+<p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Ben Hutchings <b>Opened:</b> 2004-04-01 <b>Last modified:</b> 2009-05-01</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The second parameters of the non-default constructor and of the open
<p><b>Proposed resolution:</b></p>
-<p>In 27.8.1.15 [fstream.cons], change</p>
+<p>In 27.9.1.15 [fstream.cons], change</p>
<pre> explicit basic_fstream(const char* s, ios_base::openmode mode);
</pre>
<p>to</p>
<pre> explicit basic_fstream(const char* s,
ios_base::openmode mode = ios_base::in|ios_base::out);
</pre>
-<p>In 27.8.1.17 [fstream.members], change</p>
+<p>In 27.9.1.17 [fstream.members], change</p>
<pre> void open(const char*s, ios_base::openmode mode);
</pre>
<p>to</p>
<hr>
<h3><a name="461"></a>461. time_get hard or impossible to implement</h3>
-<p><b>Section:</b> 22.2.5.1.2 [locale.time.get.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-03-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>Section:</b> 22.4.5.1.2 [locale.time.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-03-23 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Template time_get currently contains difficult, if not impossible,
<hr>
<h3><a name="464"></a>464. Suggestion for new member functions in standard containers</h3>
-<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>Section:</b> 23.3.6 [vector], 23.4.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2004-05-12 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>To add slightly more convenience to vector<T> and map<Key,T> we should consider to add</p>
<p><b>Proposed resolution:</b></p>
-<p>In 23.2.6 [vector], add the following to the <tt>vector</tt>
+<p>In 23.3.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.6 [vector]:</p>
+<p>Add a new subsection of 23.3.6 [vector]:</p>
<blockquote>
<p>23.2.4.x <tt>vector</tt> data access</p>
<pre> pointer data();
<p><b>Throws:</b> Nothing.</p>
</blockquote>
-<p>In 23.3.1 [map], add the following to the <tt>map</tt>
+<p>In 23.4.1 [map], add the following to the <tt>map</tt>
synopsis immediately after the line for operator[]:</p>
<pre> T& at(const key_type& x);
const T& at(const key_type& x) const;
</pre>
-<p>Add the following to 23.3.1.2 [map.access]:</p>
+<p>Add the following to 23.4.1.2 [map.access]:</p>
<blockquote>
<pre> T& at(const key_type& x);
const T& at(const key_type& x) const;
<hr>
<h3><a name="465"></a>465. Contents of <ciso646></h3>
-<p><b>Section:</b> 17.4.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 2004-06-03</p>
+<p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2004-06-03 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>C header <iso646.h> defines macros for some operators, such as
not_eq for !=.</p>
-<p>Section 17.4.1.2 [headers] "Headers" says that except as noted in
+<p>Section 17.6.1.2 [headers] "Headers" says that except as noted in
clauses 18 through 27, the <cname> C++ header contents are the same
as the C header <name.h>. In particular, table 12 lists
<ciso646> as a C++ header.</p>
<hr>
<h3><a name="467"></a>467. char_traits::lt(), compare(), and memcmp()</h3>
-<p><b>Section:</b> 21.1.3.1 [char.traits.specializations.char] <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> 2004-06-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 21.2.3.1 [char.traits.specializations.char] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="468"></a>468. unexpected consequences of ios_base::operator void*()</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#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
+<p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The program below is required to compile but when run it typically
<hr>
<h3><a name="469"></a>469. vector<bool> ill-formed relational operators</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#DR">DR</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
+<p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2009-05-01</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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="474"></a>474. confusing Footnote 297</h3>
-<p><b>Section:</b> 27.6.2.6.4 [ostream.inserters.character] <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> 2004-07-01</p>
+<p><b>Section:</b> 27.7.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-07-01 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.character">issues</a> in [ostream.inserters.character].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="475"></a>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3>
-<p><b>Section:</b> 25.1.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 2004-07-09</p>
+<p><b>Section:</b> 25.3.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Opened:</b> 2004-07-09 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.foreach">active issues</a> in [alg.foreach].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is not clear whether the function object passed to for_each is allowed to
<p><b>Proposed resolution:</b></p>
-<p>Add a nonnormative note to the Effects in 25.1.4 [alg.foreach]: If
+<p>Add a nonnormative note to the Effects in 25.3.4 [alg.foreach]: If
the type of 'first' satisfies the requirements of a mutable iterator,
'f' may apply nonconstant functions through the dereferenced iterators
passed to it.
<hr>
<h3><a name="478"></a>478. Should forward iterator requirements table have a line for r->m?</h3>
-<p><b>Section:</b> 24.1.3 [forward.iterators] <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> 2004-07-11</p>
+<p><b>Section:</b> 24.2.4 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-07-11 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="488"></a>488. rotate throws away useful information</h3>
-<p><b>Section:</b> 25.2.11 [alg.rotate] <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> 2004-11-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>Section:</b> 25.4.11 [alg.rotate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2004-11-22 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
rotate takes 3 iterators: first, middle and last which point into a
ForwardIterator last);
</pre></blockquote>
-<p>In 25.2.11 [alg.rotate], change:</p>
+<p>In 25.4.11 [alg.rotate], change:</p>
<blockquote><pre> template<class ForwardIterator>
<del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
ForwardIterator last);
</pre></blockquote>
-<p>In 25.2.11 [alg.rotate] insert a new paragraph after p1:</p>
+<p>In 25.4.11 [alg.rotate] insert a new paragraph after p1:</p>
<blockquote>
<p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p>
<hr>
<h3><a name="495"></a>495. Clause 22 template parameter requirements</h3>
-<p><b>Section:</b> 22 [localization] <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> 2005-01-10</p>
+<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2005-01-10 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>It appears that there are no requirements specified for many of the
template parameters in clause 22. It looks like this issue has never
</ul>
<p><b>Proposed resolution:</b></p>
-<p>Change 17.3.2.1 [type.descriptions], paragraph 1, from:</p>
+<p>Change 17.5.2.1 [type.descriptions], paragraph 1, from:</p>
<blockquote><p>
The Requirements subclauses may describe names that are used to
specify constraints on template arguments.153) These names are used in
<hr>
<h3><a name="496"></a>496. Illegal use of "T" in vector<bool></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#WP">WP</a>
- <b>Submitter:</b> richard@ex-parrot.com <b>Date:</b> 2005-02-10</p>
+<p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> richard@ex-parrot.com <b>Opened:</b> 2005-02-10 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In the synopsis of the std::vector<bool> specialisation in 23.2.6 [vector],
+In the synopsis of the std::vector<bool> specialisation in 23.3.6 [vector],
the non-template assign() function has the signature</p>
<pre> void assign( size_type n, const T& t );
<hr>
<h3><a name="497"></a>497. meaning of numeric_limits::traps for floating point types</h3>
-<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-03-02</p>
+<p><b>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-03-02 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
<hr>
<h3><a name="505"></a>505. Result_type in random distribution requirements</h3>
-<p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <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>Section:</b> X [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 17: Random distribution requirements
<hr>
<h3><a name="507"></a>507. Missing requirement for variate_generator::operator()</h3>
-<p><b>Section:</b> 26.4 [rand], TR1 5.1.3 [tr.rand.var] <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>Section:</b> 26.5 [rand], TR1 5.1.3 [tr.rand.var] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Paragraph 11 of [tr.rand.var] equires that the member template
<hr>
<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>Section:</b> 26.5.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#CD1">CD1</a>
+ <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The fifth of these engines with predefined parameters, ranlux64_base_01,
<hr>
<h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3>
-<p><b>Section:</b> 23.1.5 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-07-03</p>
+<p><b>Section:</b> 23.2.5 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Issue 371 deals with stability of multiset/multimap under insert and erase
</p>
<p>
-Change 23.1.5 [unord.req], Unordered associative containers, paragraph 6 to:
+Change 23.2.5 [unord.req], Unordered associative containers, paragraph 6 to:
</p>
<blockquote><p>
</p></blockquote>
<p>
-Change 23.1.5 [unord.req], Unordered associative containers, paragraph 8 to:
+Change 23.2.5 [unord.req], Unordered associative containers, paragraph 8 to:
</p>
<blockquote>
<hr>
<h3><a name="519"></a>519. Data() undocumented</h3>
-<p><b>Section:</b> 23.2.1 [array], TR1 6.2.2 [tr.array.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
+<p><b>Section:</b> 23.3.1 [array], TR1 6.2.2 [tr.array.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>array<>::data()</tt> is present in the class synopsis, but not documented.
<hr>
<h3><a name="520"></a>520. Result_of and pointers to data members</h3>
-<p><b>Section:</b> 20.6.11.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 20.7.12.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the original proposal for binders, the return type of bind() when
<hr>
<h3><a name="521"></a>521. Garbled requirements for argument_type in reference_wrapper</h3>
-<p><b>Section:</b> 20.6.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 20.7.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap">issues</a> in [refwrap].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
2.1.2/3, second bullet item currently says that reference_wrapper<T> is
<hr>
+<h3><a name="522"></a>522. Tuple doesn't define swap</h3>
+<p><b>Section:</b> 20.5 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Andy Koenig <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Tuple doesn't define swap(). It should.
+</p>
+<p><i>[
+Berlin: Doug to provide wording.
+]</i></p>
+
+<p><i>[
+Batavia: Howard to provide wording.
+]</i></p>
+
+<p><i>[
+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.5 [tuple]
+</p>
+
+<blockquote><pre>template <class... Types>
+ void swap(tuple<Types...>& x, tuple<Types...>& y);
+template <class... Types>
+ void swap(tuple<Types...>&& x, tuple<Types...>& y);
+template <class... Types>
+ void swap(tuple<Types...>& x, tuple<Types...>&& y);
+</pre></blockquote>
+
+<p>
+Add this signature to 20.5.2 [tuple.tuple]
+</p>
+
+<blockquote><pre>void swap(tuple&&);
+</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&& 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 <class... Types>
+ void swap(tuple<Types...>& x, tuple<Types...>& y);
+template <class... Types>
+ void swap(tuple<Types...>&& x, tuple<Types...>& y);
+template <class... Types>
+ void swap(tuple<Types...>& x, tuple<Types...>&& y);
+</pre>
+
+<blockquote>
+<p>
+<i>Effects:</i> x.swap(y)
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
<h3><a name="524"></a>524. regex named character classes and case-insensitivity don't mix</h3>
-<p><b>Section:</b> 28 [re] <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> 2005-07-01</p>
+<p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2005-07-01 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re">active issues</a> in [re].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This defect is also being discussed on the Boost developers list. The
<hr>
<h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3>
-<p><b>Section:</b> 20.6.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2005-10-01</p>
+<p><b>Section:</b> 20.7.12.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#CD1">CD1</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2005-10-01 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The original bind proposal gives the guarantee that tr1::bind(f, t1,
<p><b>Proposed resolution:</b></p>
<p>
-In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p2:
+In 20.7.12.1.3 [func.bind.bind], add a new paragraph after p2:
</p>
<blockquote>
</blockquote>
<p>
-In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p4:
+In 20.7.12.1.3 [func.bind.bind], add a new paragraph after p4:
</p>
<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>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-11-15</p>
+<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2005-11-15 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, which was incorporated into C++03, mandated
that the elements of a vector must be stored in contiguous memory.
Should the same also apply to <tt>basic_string</tt>?</p>
-<p>We almost require contiguity already. Clause 23.3.4 [multiset]
+<p>We almost require contiguity already. Clause 23.4.4 [multiset]
defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing
is a similar guarantee if we access the string's elements via the
iterator interface.</p>
<p><b>Proposed resolution:</b></p>
-<p>Add the following text to the end of 21.3 [basic.string],
+<p>Add the following text to the end of 21.4 [basic.string],
paragraph 2. </p>
<blockquote>
<hr>
<h3><a name="531"></a>531. array forms of unformatted input functions</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> 2005-11-23</p>
+<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-11-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The array forms of unformatted input functions don't seem to have well-defined
<hr>
<h3><a name="533"></a>533. typo in 2.2.3.10/1</h3>
-<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-11-09</p>
+<p><b>Section:</b> 20.8.13.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#CD1">CD1</a>
+ <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2005-11-09 <b>Last modified:</b> 2009-05-01</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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
<hr>
<h3><a name="534"></a>534. Missing basic_string members</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>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2005-11-16</p>
+<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2005-11-16 <b>Last modified:</b> 2008-09-26</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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
OK, we all know std::basic_string is bloated and already has way too
<hr>
<h3><a name="535"></a>535. std::string::swap specification poorly worded</h3>
-<p><b>Section:</b> 21.3.6.8 [string::swap] <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> 2005-12-14</p>
+<p><b>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2005-12-14 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
std::string::swap currently says for effects and postcondition:
<hr>
<h3><a name="537"></a>537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</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> Paolo Carlini <b>Date:</b> 2006-02-12</p>
+<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-12 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the most recent working draft, I'm still seeing:
<hr>
<h3><a name="538"></a>538. 241 again: Does unique_copy() require CopyConstructible and Assignable?</h3>
-<p><b>Section:</b> 25.2.9 [alg.unique] <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-09</p>
+<p><b>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-02-09 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I believe I botched the resolution of
<hr>
<h3><a name="540"></a>540. shared_ptr<void>::operator*()</h3>
-<p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-15</p>
+<p><b>Section:</b> 20.8.13.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#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-15 <b>Last modified:</b> 2008-09-26</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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
<hr>
<h3><a name="541"></a>541. shared_ptr template assignment and void</h3>
-<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-16</p>
+<p><b>Section:</b> 20.8.13.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#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-16 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Is the void specialization of the template assignment operator taking
<hr>
<h3><a name="542"></a>542. shared_ptr observers</h3>
-<p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-18</p>
+<p><b>Section:</b> 20.8.13.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#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-18 <b>Last modified:</b> 2008-09-26</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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Peter Dimov wrote:
<p><b>Proposed resolution:</b></p>
<p>
-Change 20.7.12.2.5 [util.smartptr.shared.obs] p12:
+Change 20.8.13.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
</p></blockquote>
<p>
-Change 20.7.12.3.5 [util.smartptr.weak.obs] p3:
+Change 20.8.13.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
<hr>
<h3><a name="543"></a>543. valarray slice default constructor</h3>
-<p><b>Section:</b> 26.5.4 [class.slice] <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> 2005-11-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>Section:</b> 26.6.4 [class.slice] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2005-11-03 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
If one explicitly constructs a slice or glice with the default
<p><b>Proposed resolution:</b></p>
-<p><i>[Martin suggests removing the second sentence in 26.5.4.1 [cons.slice] as well.]</i></p>
+<p><i>[Martin suggests removing the second sentence in 26.6.4.1 [cons.slice] as well.]</i></p>
<p>
-Change 26.5.4.1 [cons.slice]:
+Change 26.6.4.1 [cons.slice]:
</p>
<blockquote><p>
</p></blockquote>
<p>
-Change 26.5.6.1 [gslice.cons]:
+Change 26.6.6.1 [gslice.cons]:
</p>
<blockquote><p>
<hr>
<h3><a name="545"></a>545. When is a deleter deleted?</h3>
-<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
+<p><b>Section:</b> 20.8.13.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#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2008-09-26</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>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if
<p><b>Proposed resolution:</b></p>
<p>
-Add after the first sentence of 20.7.12.2.11 [util.smartptr.getdeleter]/1:
+Add after the first sentence of 20.8.13.2.11 [util.smartptr.getdeleter]/1:
</p>
<blockquote>
<p>
<hr>
<h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-12</p>
+<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-12 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Assuming we adopt the
<p><b>Proposed resolution:</b></p>
<p>
-Change 26.7 [c.math] p10:
+Change 26.8 [c.math] p10:
</p>
<blockquote>
<hr>
<h3><a name="551"></a>551. <ccomplex></h3>
-<p><b>Section:</b> 26.3.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-23</p>
-<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>Section:</b> 26.4.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-23 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Previously xxx.h was parsable by C++. But in the case of C99's <complex.h>
<hr>
<h3><a name="552"></a>552. random_shuffle and its generator</h3>
-<p><b>Section:</b> 25.2.12 [alg.random.shuffle] <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-01-25</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>Section:</b> 25.4.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-01-25 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.random.shuffle">issues</a> in [alg.random.shuffle].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
...is specified to shuffle its range by calling swap but not how
<hr>
<h3><a name="559"></a>559. numeric_limits<const T></h3>
-<p><b>Section:</b> 18.2.1 [limits] <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-19</p>
+<p><b>Section:</b> 18.3.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-19 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-18.2.1 [limits], p2 requires implementations to provide specializations of the
+18.3.1 [limits], p2 requires implementations to provide specializations of the
<code>numeric_limits</code> template for each scalar type. While this
could be interepreted to include cv-qualified forms of such types such
an interepretation is not reflected in the synopsis of the
<p>
-Add a new paragraph to the end of 18.2.1.1 [numeric.limits], with the following
+Add a new paragraph to the end of 18.3.1.1 [numeric.limits], with the following
text:
</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#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>Section:</b> 24.7.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-02-21 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The declaration of <tt>std::inserter</tt> is:
<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#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
+<p><b>Section:</b> 27.8 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<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#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
+<p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to Table 92 (unchanged by issue 432), when <code>(way ==
<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>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<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#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-25</p>
+<p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-25 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<hr>
<h3><a name="574"></a>574. DR 369 Contradicts Text</h3>
-<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2006-04-18</p>
+<p><b>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2006-04-18 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
lib.iostream.objects requires that the standard stream objects are never
<p><b>Proposed resolution:</b></p>
<p>
-Change 27.3 [iostream.objects]/1:
+Change 27.4 [iostream.objects]/1:
</p>
<blockquote>
<p><i>[
-Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects
+Kona (2007): From 27.4 [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
<hr>
<h3><a name="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3>
-<p><b>Section:</b> 20.7.12.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-04-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 20.8.13.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#CD1">CD1</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2006-04-23 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.dest">issues</a> in [util.smartptr.shared.dest].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
[tr.util.smartptr.shared.dest] says in its second bullet:
<hr>
<h3><a name="576"></a>576. find_first_of is overconstrained</h3>
-<p><b>Section:</b> 25.1.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Doug Gregor <b>Date:</b> 2006-04-25</p>
+<p><b>Section:</b> 25.3.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2006-04-25 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
<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>
-<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>Section:</b> 25.5.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2006-05-03 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
ISO/IEC 14882:2003 says:
<hr>
<h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3>
-<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-17</p>
+<p><b>Section:</b> 20.8.6.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<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#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
+<p><b>Section:</b> 27.7.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<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>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-22 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<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>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2006-08-02 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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>
<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>Section:</b> 18.4 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Walter Brown <b>Opened:</b> 2006-08-28 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
<hr>
<h3><a name="595"></a>595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified</h3>
-<p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Stefan Große Pawig <b>Date:</b> 2006-09-24</p>
+<p><b>Section:</b> 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Stefan Große Pawig <b>Opened:</b> 2006-09-24 <b>Last modified:</b> 2009-03-21</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
TR1 introduced, in the C compatibility chapter, the function
<p><b>Proposed resolution:</b></p>
<p>
-Change the synopsis in 26.3.1 [complex.synopsis]:
+Change the synopsis in 26.4.1 [complex.syn]:
</p>
<blockquote><pre><del>template<class T> complex<T> fabs(const complex<T>&);</del>
</pre></blockquote>
<p>
-Remove 26.3.7 [complex.value.ops], p7:
+Remove 26.4.7 [complex.value.ops], p7:
</p>
<blockquote>
<hr>
<h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</h3>
-<p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2006-09-26</p>
+<p><b>Section:</b> 27.9.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2006-09-26 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke
+In testing 27.9.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><b>Proposed resolution:</b></p>
<p>
-Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
+Add to the table "File open modes" in 27.9.1.4 [filebuf.members]:
</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>
+ <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-04-21</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>
<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>
+ <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-04-21</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>
<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>
+ <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-04-21</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>
<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>
+ <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-04-21</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>
<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>
+ <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-04-21</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>
<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>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-04-21</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>
<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>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-07-25</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>
<hr>
<h3><a name="605"></a>605. Decimal: <decfloat.h> 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>
+ <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2006-10-17 <b>Last modified:</b> 2007-04-21</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>
<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>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Charles Karney <b>Opened:</b> 2006-10-26 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Short seed vectors of 32-bit quantities all result in different states. However
<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>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Charles Karney <b>Opened:</b> 2006-10-26 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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
<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>Section:</b> 26.5.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#CD1">CD1</a>
+ <b>Submitter:</b> Walter E. Brown <b>Opened:</b> 2006-11-02 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In preparing N2111, an error on my part resulted in the omission of the
<hr>
<h3><a name="610"></a>610. Suggested non-normative note for C++0x</h3>
-<p><b>Section:</b> 20.6.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Scott Meyers <b>Date:</b> 2006-11-02</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 20.7.16.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#CD1">CD1</a>
+ <b>Submitter:</b> Scott Meyers <b>Opened:</b> 2006-11-02 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
My suggestion is that implementers of both tr1::function and its
<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>Section:</b> 17.6.3.8 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Nicola Musatti <b>Opened:</b> 2006-11-13 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.functions">issues</a> in [res.on.functions].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the latest available draft standard
<hr>
<h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently defined</h3>
-<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2006-11-10</p>
+<p><b>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2006-11-10 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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
<p><b>Proposed resolution:</b></p>
<p>
-Suggest 18.2.1.2 [numeric.limits.members], paragraph 57 is amended to:
+Suggest 18.3.1.2 [numeric.limits.members], paragraph 57 is amended to:
</p>
<blockquote><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>Section:</b> 18.3.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-11-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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
+Section 18.3.1.5 [numeric.special] starts out by saying that "All members shall be provided
for all specializations."
</p>
<p>
<p><b>Proposed resolution:</b></p>
<p>
-Change and add after 18.2.1.2 [numeric.limits.members], p11:
+Change and add after 18.3.1.2 [numeric.limits.members], p11:
</p>
<blockquote>
</blockquote>
<p>
-Change 18.2.1.5 [numeric.special], p2:
+Change 18.3.1.5 [numeric.special], p2:
</p>
<blockquote><pre>template<> class numeric_limits<float> {
</pre></blockquote>
<p>
-Change 18.2.1.5 [numeric.special], p3:
+Change 18.3.1.5 [numeric.special], p3:
</p>
<blockquote><pre>template<> class numeric_limits<bool> {
<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>Section:</b> 22.4.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-16 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 22.2.1.2 defines the ctype_byname class template. It contains the
<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#WP">WP</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 26.6.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2007-01-10 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I would respectfully request an issue be opened with the intention to
<p><b>Proposed resolution:</b></p>
<p>
-Change 26.5.2.7 [valarray.members], paragraph 10:
+Change 26.6.2.7 [valarray.members], paragraph 10:
</p>
<blockquote>
<hr>
<h3><a name="619"></a>619. Longjmp wording problem</h3>
-<p><b>Section:</b> 18.9 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2007-01-12</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2007-01-12 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.runtime">issues</a> in [support.runtime].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The wording for <tt>longjmp</tt> is confusing.
</p>
<p>
-18.9 [support.runtime] -4- Other runtime support
+18.10 [support.runtime] -4- Other runtime support
</p>
<blockquote><p>
The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted
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.9 [support.runtime] paragraph 4, change
+In 18.10 [support.runtime] paragraph 4, change
</p>
<blockquote><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#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
+<p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<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]):
+Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.6.2.1 [valarray.cons]):
</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>Section:</b> 26.6 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
</p>
<p>
-Change the signature in 26.5.5 [template.slice.array] and
-26.5.5.1 [slice.arr.assign] as follows:
+Change the signature in 26.6.5 [template.slice.array] and
+26.6.5.1 [slice.arr.assign] as follows:
</p>
<blockquote><pre>
</pre></blockquote>
<p>
-Change the signature in 26.5.7 [template.gslice.array] and
-26.5.7.1 [gslice.array.assign] as follows:
+Change the signature in 26.6.7 [template.gslice.array] and
+26.6.7.1 [gslice.array.assign] as follows:
</p>
<blockquote><pre>
</pre></blockquote>
<p>
-Change the signature in 26.5.8 [template.mask.array] and 26.5.8.1 [mask.array.assign] as
+Change the signature in 26.6.8 [template.mask.array] and 26.6.8.1 [mask.array.assign] as
follows:
</p>
</pre></blockquote>
<p>
-Change the signature in 26.5.9 [template.indirect.array] and
-26.5.9.1 [indirect.array.assign] as follows:
+Change the signature in 26.6.9 [template.indirect.array] and
+26.6.9.1 [indirect.array.assign] as follows:
</p>
<blockquote><pre>
<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>Section:</b> 27.9.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
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.9 [res.on.exception.handling].
+17.6.4.10 [res.on.exception.handling].
</p>
<p>
<p>
Specifically, we propose to make the following edits in
-27.8.1.4 [filebuf.members]:
+27.9.1.4 [filebuf.members]:
</p>
<blockquote>
</blockquote>
<p>
-And to make the following edits in 27.8.1.2 [filebuf.cons].
+And to make the following edits in 27.9.1.2 [filebuf.cons].
</p>
<blockquote>
<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.9 [res.on.exception.handling]).</ins>
+17.6.4.10 [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>Section:</b> 27.2.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-27.1.1 [iostream.limits.imbue] specifies that "no function described in
+27.2.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."
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:
+change 27.2.1 [iostream.limits.imbue], p1 to read:
</p>
<blockquote><p>
<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#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>Section:</b> 26.6.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></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
+on <code>slice_array</code> et al (26.6.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.
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:
+<i>Requires</i> clause to 26.6.2.2 [valarray.assign] as follows:
</p>
<blockquote><p>
<p><b>Proposed resolution:</b></p>
<p>
-Insert new paragraph into 26.5.2.2 [valarray.assign]:
+Insert new paragraph into 26.6.2.2 [valarray.assign]:
</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>Section:</b> 28.9 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-01-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Section 28.8 [re.regex] lists a constructor
+Section 28.9 [re.regex] lists a constructor
</p>
<blockquote><pre>template<class InputIterator>
</pre></blockquote>
<p>
-However, in section 28.8.2 [re.regex.construct], this constructor takes a
+However, in section 28.9.2 [re.regex.construct], this constructor takes a
pair of <tt>ForwardIterator</tt>.
</p>
<p><b>Proposed resolution:</b></p>
<p>
-Change 28.8.2 [re.regex.construct]:
+Change 28.9.2 [re.regex.construct]:
</p>
<blockquote><pre>template <class <del>ForwardIterator</del> <ins>InputIterator</ins>>
<hr>
+<h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3>
+<p><b>Section:</b> 26.4.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2007-01-28 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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><i>[
+Pre-Sophia Antipolis, Howard adds:
+]</i></p>
+
+
+<blockquote>
+Changed "showbase" to "showpoint" and changed from Ready to Review.
+</blockquote>
+
+<p><i>[
+Post-Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change.
+In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready. We subsequently
+voted the footnote into the WP with "showbase".
+</p>
+<p>
+I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a footnote to 26.4.6 [complex.ops] p16:
+</p>
+
+<blockquote>
+[In a locale in which comma is being used as a decimal point character,
+inserting <tt>showpoint</tt> into the output stream forces all outputs to show
+an explicit decimal point character; then all inserted complex sequences
+will extract unambiguously.]
+</blockquote>
+
+
+
+
+
+<hr>
<h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&</tt></h3>
-<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-07</p>
+<p><b>Section:</b> 20.8.6.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-07 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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.7.5.1 [allocator.members] says:
+20.8.6.1 [allocator.members] says:
</p>
<blockquote>
<pre>pointer address(reference <i>x</i>) const;</pre>
</blockquote>
<p>
-20.7.5.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
+20.8.6.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&</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
<p><b>Proposed resolution:</b></p>
<p>
-Change 20.7.5.1 [allocator.members]:
+Change 20.8.6.1 [allocator.members]:
</p>
<blockquote>
<hr>
<h3><a name="638"></a>638. deque end invalidation during erase</h3>
-<p><b>Section:</b> 23.2.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Steve LoBasso <b>Date:</b> 2007-02-17</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 23.3.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Steve LoBasso <b>Opened:</b> 2007-02-17 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The standard states at 23.2.2.3 [deque.modifiers]/4:
+The standard states at 23.3.2.3 [deque.modifiers]/4:
</p>
<blockquote><pre>deque erase(...)
</pre>
<p><b>Proposed resolution:</b></p>
<p>
-Change 23.2.2.3 [deque.modifiers], p4:
+Change 23.3.2.3 [deque.modifiers], p4:
</p>
<blockquote>
<hr>
<h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3>
-<p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p>
+<p><b>Section:</b> 27.7.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic].
+The arithmetic inserters are described in 27.7.2.6.2 [ostream.inserters.arithmetic].
Although the section starts with a listing of the inserters including
the new ones:
</p>
<p><b>Proposed resolution:</b></p>
<p>
-In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
+In 27.7.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
</p>
<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>Section:</b> 27.9.1.1 [filebuf], 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-20 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current standard 14882:2003(E) as well as N2134 have the
</p>
<p>
-27.8.1.1 [filebuf]/5 says:
+27.9.1.1 [filebuf]/5 says:
</p>
<blockquote>
</p>
<p>
-A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>.
+A similar issue arises in 22.4.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>.
</p>
<p><b>Proposed resolution:</b></p>
<p>
-In 27.8.1.1 [filebuf]/5 change the "as if" code
+In 27.9.1.1 [filebuf]/5 change the "as if" code
</p>
<blockquote><pre><ins>const </ins>codecvt<charT,char,typename traits::state_type><ins>&</ins> <i>a_codecvt</i> =
</pre></blockquote>
<p>
-In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
+In 22.4.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
</p>
<blockquote>
<hr>
<h3><a name="646"></a>646. const incorrect match_result members</h3>
-<p><b>Section:</b> 28.10.4 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
-<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>Section:</b> 28.11.4 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-26 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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
+28.11.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.
+as const in 28.11 [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].
+in section 28.11.4 [re.results.form].
</p>
<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>Section:</b> 28.13.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-05 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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
+Both the class definition of regex_token_iterator (28.13.2
+[re.tokiter]/6) and the latter member specifications (28.13.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).
+unexpectedly also declared as non-const in 28.13.2 [re.tokiter]/6
+as well as in (28.13.2.3 [re.tokiter.deref]/1+2).
</p>
<p><b>Proposed resolution:</b></p>
<p>
-1) In (28.12.2 [re.tokiter]/6) change the current declarations
+1) In (28.13.2 [re.tokiter]/6) change the current declarations
</p>
<blockquote><pre>bool operator==(const regex_token_iterator&) <ins>const</ins>;
</pre></blockquote>
<p>
-2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
+2) In 28.13.2.2 [re.tokiter.comp] change the following declarations
</p>
<blockquote><pre>bool operator==(const regex_token_iterator& right) <ins>const</ins>;
</pre></blockquote>
<p>
-3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
+3) In 28.13.2.3 [re.tokiter.deref] change the following declarations
</p>
<blockquote><pre>const value_type& operator*() <ins>const</ins>;
<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>Section:</b> 28.13.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-05 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
+The text provided in 28.13.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
+an issue, if one takes 28.13.2 [re.tokiter]/9 into account, which explains
the notion of a "current match" by saying:
</p>
<p><b>Proposed resolution:</b></p>
<p>
Add the following precondition paragraph just before the current
-28.12.2.1 [re.tokiter.cnstr]/2:
+28.13.2.1 [re.tokiter.cnstr]/2:
</p>
<blockquote><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>
-<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>Section:</b> 28.13.1 [re.regiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-05 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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)
+<p>Both the class definition of regex_iterator (28.13.1 [re.regiter]/1)
+and the latter member specification (28.13.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).
+unexpectedly also declared as non-const in 28.13.1 [re.regiter]/1
+as well as in (28.13.1.3 [re.regiter.deref]/1+2).
</p>
<p><b>Proposed resolution:</b></p>
<p>
-1) In (28.12.1 [re.regiter]/1) change the current declarations
+1) In (28.13.1 [re.regiter]/1) change the current declarations
</p>
<blockquote><pre>bool operator==(const regex_iterator&) <ins>const</ins>;
</pre></blockquote>
<p>
-2) In 28.12.1.3 [re.regiter.deref] change the following declarations
+2) In 28.13.1.3 [re.regiter.deref] change the following declarations
</p>
<blockquote><pre>const value_type& operator*() <ins>const</ins>;
</pre></blockquote>
<p>
-3) In 28.12.1.2 [re.regiter.comp] change the following declarations
+3) In 28.13.1.2 [re.regiter.comp] change the following declarations
</p>
<blockquote><pre>bool operator==(const regex_iterator& right) <ins>const</ins>;
<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">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
+<p><b>Section:</b> X [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-08 <b>Last modified:</b> 2009-05-01</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify
+Table 98 and para 5 in X [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
RanNumEngine() : state(42) {}
bool operator==(RanNumEngine other) const {
- return state == other.state;
+ return state == other.state;
}
template <typename Ch, typename Tr>
friend std::basic_ostream<Ch, Tr>& operator<<(std::basic_ostream<Ch, Tr>& os, RanNumEngine engine) {
- Ch old = os.fill(os.widen(' ')); // Sets space character
- std::ios_base::fmtflags f = os.flags();
- os << std::dec << std::left << engine.state; // Adds ios_base::dec|ios_base::left
- os.fill(old); // Undo
- os.flags(f);
- return os;
+ Ch old = os.fill(os.widen(' ')); // Sets space character
+ std::ios_base::fmtflags f = os.flags();
+ os << std::dec << std::left << engine.state; // Adds ios_base::dec|ios_base::left
+ os.fill(old); // Undo
+ os.flags(f);
+ return os;
}
template <typename Ch, typename Tr>
friend std::basic_istream<Ch, Tr>& operator>>(std::basic_istream<Ch, Tr>& is, RanNumEngine& engine) {
// Uncomment only for the fix.
- //std::ios_base::fmtflags f = is.flags();
- //is >> std::dec;
- is >> engine.state;
- //is.flags(f);
- return is;
+ //std::ios_base::fmtflags f = is.flags();
+ //is >> std::dec;
+ is >> engine.state;
+ //is.flags(f);
+ return is;
}
};
int main() {
- std::stringstream s;
- s << std::setfill('#'); // No problem
+ std::stringstream s;
+ s << std::setfill('#'); // No problem
s << std::oct; // Yikes!
// Here starts para 5 requirements:
- RanNumEngine x;
- s << x;
- RanNumEngine v;
- s >> v;
- assert(x == v); // Fails: 42 == 34
+ RanNumEngine x;
+ s << x;
+ RanNumEngine v;
+ s >> v;
+ assert(x == v); // Fails: 42 == 34
}
</pre></blockquote>
<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">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
+<p><b>Section:</b> 26.5.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-08 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In 26.4.2 [rand.synopsis] we have the declaration
+In 26.5.1 [rand.synopsis] we have the declaration
</p>
<blockquote><pre>template<class RealType, class UniformRandomNumberGenerator,
<hr>
<h3><a name="660"></a>660. Missing Bitwise Operations</h3>
-<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-04-02</p>
+<p><b>Section:</b> 20.7 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-04-02 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
-<p>Section 20.6 [function.objects] provides <span id="st" name="st" class="st">function</span>
+<p>Section 20.7 [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
<p><b>Proposed resolution:</b></p>
-<p>To 20.6 [function.objects], Function objects, paragraph 2, add to the header
+<p>To 20.7 [function.objects], Function objects, paragraph 2, add to the header
<functional> synopsis:</p>
<blockquote>
<pre>template <class T> struct bit_and;
<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>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-04-01 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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
+To the more drastic changes of 27.7.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>
<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
+27.7.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or
an
oversight.
</li>
<ol>
<li>
<p>
-In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
+In 27.7.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
</p>
<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
iostate err = 0;
</pre></blockquote>
<p>
-Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
+Similarily in 27.7.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
</p>
<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
<hr>
<h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt<char, char, mbstate_t></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>Section:</b> 22.4.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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>):
+22.4.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>):
</p>
<blockquote><p>
<p><b>Proposed resolution:</b></p>
<p>
-Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
+Change 22.4.1.4.2 [locale.codecvt.virtuals], p7:
</p>
<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#WP">WP</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>Section:</b> 22.4.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
+22.4.1.4.2 [locale.codecvt.virtuals], para 8 says:
</p>
<blockquote><p>
<p><b>Proposed resolution:</b></p>
<p>
-Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
+Change 22.4.1.4.2 [locale.codecvt.virtuals], p8:
</p>
<blockquote>
<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#WP">WP</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>Section:</b> 22.4.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
+22.4.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
</p>
<blockquote><p>
<p><b>Proposed resolution:</b></p>
<p>
-Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
+Change footnote 253 in 22.4.6.3.2 [locale.moneypunct.virtuals]:
</p>
<blockquote>
<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#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
+<p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-04 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current <tt>Swappable</tt> is:
<p><b>Proposed resolution:</b></p>
<p>
-Change 20.1.1 [utility.arg.requirements]:
+Change X [utility.arg.requirements]:
</p>
<blockquote>
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
+this issue, and open a separated issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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,
<hr>
<h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
-<p><b>Section:</b> 20.7.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
+<p><b>Section:</b> 20.8.12 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-04 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Since the publication of
<li>
<p>
-Change 20.7.11.2 [unique.ptr.single]:
+Change 20.8.12.2 [unique.ptr.single]:
</p>
<blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr {
</pre></blockquote>
<p>
-Change 20.7.11.2.4 [unique.ptr.single.observers]:
+Change 20.8.12.2.4 [unique.ptr.single.observers]:
</p>
<blockquote><pre><del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const;
<li>
<p>
-Change 20.7.11.2 [unique.ptr.single]:
+Change 20.8.12.2 [unique.ptr.single]:
</p>
<blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr {
</p>
<p>
-Change 20.7.11.2.1 [unique.ptr.single.ctor]:
+Change 20.8.12.2.1 [unique.ptr.single.ctor]:
</p>
<blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
</p>
<p>
-Change 20.7.11.2.3 [unique.ptr.single.asgn]:
+Change 20.8.12.2.3 [unique.ptr.single.asgn]:
</p>
<blockquote>
</blockquote>
<p>
-Change 20.7.11.2.4 [unique.ptr.single.observers]:
+Change 20.8.12.2.4 [unique.ptr.single.observers]:
</p>
<blockquote>
</blockquote>
<p>
-Change 20.7.11.2.5 [unique.ptr.single.modifiers]:
+Change 20.8.12.2.5 [unique.ptr.single.modifiers]:
</p>
<blockquote>
</blockquote>
<p>
-Change 20.7.11.3 [unique.ptr.runtime]:
+Change 20.8.12.3 [unique.ptr.runtime]:
</p>
<blockquote><pre>template <class T, class D> class unique_ptr<T[], D> {
</pre></blockquote>
<p>
-Change 20.7.11.3.1 [unique.ptr.runtime.ctor]:
+Change 20.8.12.3.1 [unique.ptr.runtime.ctor]:
</p>
<blockquote>
</blockquote>
<p>
-Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:
+Change 20.8.12.3.3 [unique.ptr.runtime.modifiers]:
</p>
<blockquote>
<li>
<p>
-Change 20.7.11.2.1 [unique.ptr.single.ctor]:
+Change 20.8.12.2.1 [unique.ptr.single.ctor]:
</p>
<blockquote>
<hr>
<h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3>
-<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-05</p>
+<p><b>Section:</b> 20.8.13.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-05 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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
<p><b>Proposed resolution:</b></p>
<p>
-Change 20.7.12.2 [util.smartptr.shared] as follows:
+Change 20.8.13.2 [util.smartptr.shared] as follows:
</p>
<blockquote>
</blockquote>
<p>
-Change 20.7.12.2.1 [util.smartptr.shared.const] as follows:
+Change 20.8.13.2.1 [util.smartptr.shared.const] as follows:
</p>
<blockquote>
</blockquote>
<p>
-Add to 20.7.12.2.1 [util.smartptr.shared.const]:
+Add to 20.8.13.2.1 [util.smartptr.shared.const]:
</p>
<blockquote>
</blockquote>
<p>
-Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows:
+Change 20.8.13.2.3 [util.smartptr.shared.assign] as follows:
</p>
<blockquote>
</blockquote>
<p>
-Add to 20.7.12.2.3 [util.smartptr.shared.assign]:
+Add to 20.8.13.2.3 [util.smartptr.shared.assign]:
</p>
<blockquote>
<hr>
-<h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<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>
+<h3><a name="675"></a>675. Move assignment of containers</h3>
+<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-05 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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
+James Hopkin pointed out to me that if <tt>vector<T></tt> move assignment is O(1)
+(just a <tt>swap</tt>) then containers such as <tt>vector<shared_ptr<ostream>></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>
-<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 <= n</tt>, each of the 2^(32s) seed vectors results in a
- distinct state.</li>
-</ul>
+<blockquote><pre><tt>vector<shared_ptr<ostream>></tt> v1;
+<tt>vector<shared_ptr<ostream>></tt> v2;
+...
+v1 = v2; // #1
+v1 = std::move(v2); // #2
+</pre></blockquote>
+
<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 < 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>
+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> 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
+<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.2 [container.requirements]:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 89: Container requirements</caption>
+<tbody><tr>
+<th>expression</th><th>return type</th><th>operational semantics</th>
+<th>assertion/note pre/post-condition</th><th>complexity</th>
+</tr>
+<tr>
+<td><tt>a = rv;</tt></td><td><tt>X&</tt></td>
+<td>All existing elements of <tt>a</tt> are either move assigned or destructed</td>
+<td><tt>a</tt> shall be equal to the
+value that <tt>rv</tt> had
+before this construction
+</td>
+<td><del>(Note C)</del> <ins>linear</ins></td>
+</tr>
+</tbody></table>
+
+<p>
+Notes: the algorithms <tt>swap()</tt>, <tt>equal()</tt> and
+<tt>lexicographical_compare()</tt> are defined in clause 25. Those
+entries marked "(Note A)" should have constant complexity. Those entries
+marked "(Note B)" have constant complexity unless
+<tt>allocator_propagate_never<X::allocator_type>::value</tt> is
+<tt>true</tt>, in which case they have linear complexity.
+<del>Those entries
+marked "(Note C)" have constant complexity if <tt>a.get_allocator() ==
+rv.get_allocator()</tt> or if either
+<tt>allocator_propagate_on_move_assignment<X::allocator_type>::value</tt>
+is <tt>true</tt> or
+<tt>allocator_propagate_on_copy_assignment<X::allocator_type>::value</tt>
+is <tt>true</tt> and linear complexity otherwise.</del>
+</p>
+</blockquote>
+
+
+
+<p><i>[
+post Bellevue 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>
+
+<p><i>[
+post Sophia Antipolis Howard updated proposed wording:
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
+<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Charles Karney <b>Opened:</b> 2007-05-15 <b>Last modified:</b> 2008-09-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#CD1">CD1</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
+</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 <= 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 < 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>
<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>Section:</b> X [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Charles Karney <b>Opened:</b> 2007-05-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
+Section X [rand.req.eng] Random number engine requirements:
</p>
<p>
<li>It leads to the possibility of a collision in the state provided
by some other <tt>X(q)</tt> with <tt>q.size() > 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
+paragraphs 26.5.3.1 [rand.eng.lcong] p5, 26.5.3.2 [rand.eng.mers] p8, and 26.5.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>
<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>Section:</b> 23.3 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-06-11 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequences">issues</a> in [sequences].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The C++98 standard specifies that one member function alone of the containers
<p><b>Proposed resolution:</b></p>
<p>
-Change 23.2.2 [deque], p2:
+Change 23.3.2 [deque], p2:
</p>
<blockquote><pre>class deque {
</pre></blockquote>
<p>
-Change 23.2.2.2 [deque.capacity], p3:
+Change 23.3.2.2 [deque.capacity], p3:
</p>
<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
</pre></blockquote>
<p>
-Change 23.2.4 [list], p2:
+Change 23.3.4 [list], p2:
</p>
<blockquote><pre>class list {
</pre></blockquote>
<p>
-Change 23.2.4.2 [list.capacity], p3:
+Change 23.3.4.2 [list.capacity], p3:
</p>
<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
</pre></blockquote>
<p>
-Change 23.2.6 [vector], p2:
+Change 23.3.6 [vector], p2:
</p>
<blockquote><pre>class vector {
</pre></blockquote>
<p>
-Change 23.2.6.2 [vector.capacity], p11:
+Change 23.3.6.2 [vector.capacity], p11:
</p>
<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
<hr>
<h3><a name="680"></a>680. move_iterator operator-> 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>Section:</b> 24.5.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-06-11 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>move_iterator</tt>'s <tt>operator-></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].
+in 24.5.3.2.5 [move.iter.op.ref].
</p>
<blockquote><pre>template <class Iterator>
<p><b>Proposed resolution:</b></p>
<p>
-Change the synopsis in 24.4.3.1 [move.iterator]:
+Change the synopsis in 24.5.3.1 [move.iterator]:
</p>
<blockquote><pre>typedef <del>typename iterator_traits<</del>Iterator<del>>::pointer</del> pointer;
<hr>
<h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3>
-<p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 28.10.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Nozomu Katoo <b>Opened:</b> 2007-05-27 <b>Last modified:</b> 2009-05-01</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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. E.g.:
+In 28.10.2 [re.submatch.op] of N2284,
+operator functions numbered 31-42 seem impossible to compare. E.g.:
</p>
<blockquote>
<pre>template <class BiIter>
- bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
- const sub_match<BiIter>& rhs);
+ bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
+ const sub_match<BiIter>& rhs);
</pre>
<blockquote>
<p>
<p>
When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits<BiIter>::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<char></tt>. However, the behaviour of comparison between
-these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
- This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>.
+of <tt>std::basic_string<char></tt>. However, the behaviour of comparison between
+these two types is not defined in 21.4.8 [string.nonmembers] of N2284.
+ This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>.
</p>
<hr>
<h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
-<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 28.9.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2007-06-03 <b>Last modified:</b> 2009-05-01</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex.construct">issues</a> in [re.regex.construct].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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
+Looking at N2284, 28.9 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this
constructor:
</p>
<blockquote><pre>template <class InputIterator>
- basic_regex(InputIterator first, InputIterator last,
- flag_type f = regex_constants::ECMAScript);
+ basic_regex(InputIterator first, InputIterator last,
+ flag_type f = regex_constants::ECMAScript);
</pre></blockquote>
<p>
-In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature:
+In 28.9.2 [re.regex.construct], p15, the constructor appears with this signature:
</p>
<blockquote><pre>template <class ForwardIterator>
- basic_regex(ForwardIterator first, ForwardIterator last,
- flag_type f = regex_constants::ECMAScript);
+ basic_regex(ForwardIterator first, ForwardIterator last,
+ flag_type f = regex_constants::ECMAScript);
</pre></blockquote>
<p>
<blockquote>
<p>
-I think either could be implemented? Although an input iterator would
+I think either could be implemented? Although an input iterator would
probably require an internal copy of the string being made.
</p>
<p>
<hr>
<h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
-<p><b>Section:</b> 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-06-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Section:</b> 24.5.1.2.19 [reverse.iter.opdiff], 24.5.3.2.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-06-10 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In C++03 the difference between two <tt>reverse_iterators</tt>
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]
+In the current draft, the operator is defined as 24.5.1.2.19 [reverse.iter.opdiff]
</p>
<blockquote><pre>template<class Iterator1, class Iterator2>
typename reverse_iterator<Iterator>::difference_type
</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].
+24.5.3.2.14 [move.iter.nonmember].
</p>
<p><b>Proposed resolution:</b></p>
<p>
-Change the synopsis in 24.4.1.1 [reverse.iterator]:
+Change the synopsis in 24.5.1.1 [reverse.iterator]:
</p>
<blockquote>
</blockquote>
<p>
-Change 24.4.1.3.19 [reverse.iter.opdiff]:
+Change 24.5.1.2.19 [reverse.iter.opdiff]:
</p>
<blockquote>
<p>
-Change the synopsis in 24.4.3.1 [move.iterator]:
+Change the synopsis in 24.5.3.1 [move.iterator]:
</p>
<blockquote>
</blockquote>
<p>
-Change 24.4.3.3.14 [move.iter.nonmember]:
+Change 24.5.3.2.14 [move.iter.nonmember]:
</p>
<blockquote>
<hr>
<h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3>
-<p><b>Section:</b> 20.7.12.2.1 [util.smartptr.shared.const], 20.7.12.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
+<p><b>Section:</b> 20.8.13.2.1 [util.smartptr.shared.const], 20.8.13.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2009-02-02</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Since all conversions from <tt>shared_ptr<T></tt> to <tt>shared_ptr<U></tt> have the same
int main()
{
- f( shared_ptr<double>() ); // ambiguous
+ f( shared_ptr<double>() ); // ambiguous
}
</pre></blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-In 20.7.12.2.1 [util.smartptr.shared.const], change:
+In 20.8.13.2.1 [util.smartptr.shared.const], change:
</p>
<blockquote><p>
</p></blockquote>
<p>
-In 20.7.12.3.1 [util.smartptr.weak.const], change:
+In 20.8.13.3.1 [util.smartptr.weak.const], change:
</p>
<blockquote>
<hr>
<h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3>
-<p><b>Section:</b> 20.6.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
+<p><b>Section:</b> 20.7.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
<hr>
+<h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3>
+<p><b>Section:</b> 23.5 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Joaquín M López Muñoz <b>Opened:</b> 2007-06-14 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+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>
+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>
+Is this really an oversight, or am I missing something?
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following two rows to table 93 (unordered associative container
+requirements) in section 23.2.5 [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>
+Add to the synopsis in 23.5.1 [unord.map]:
+</p>
+
+<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;</ins>
+</pre></blockquote>
+
+<p>
+Add to the synopsis in 23.5.2 [unord.multimap]:
+</p>
+
+<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;</ins>
+</pre></blockquote>
+
+<p>
+Add to the synopsis in 23.5.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>
+Add to the synopsis in 23.5.4 [unord.multiset]:
+</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 formatted I/O functions</h3>
+<p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+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>
+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>
+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.7.4 [ext.manip] with the
+following text:
+</p>
+<blockquote><p>
+<i>Effects</i>: The expression <code><i>in</i> >> get_money(mon, intl)</code>
+described below behaves as a formatted input function (as
+described in 27.7.1.2.1 [istream.formatted.reqmts]).
+</p></blockquote>
+<p>
+Also change p4 of 27.7.4 [ext.manip] as follows:
+</p>
+<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<charT,
+traits></code> then the expression <code><i>in</i> >> 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="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>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <code>bitset</code> class template provides the member function
<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,
+defintion of the <code>bitset</code> template in 20.3.6 [template.bitset], p1,
right above the declaration of <code>any()</code> as shown below:
</p>
</pre></blockquote>
<p>
-Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
+Add a description of the new member function to the end of 20.3.6.2 [bitset.members] with the following text:
</p>
<blockquote><p>
<code>bool all() const;</code>
<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>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Objects of the <code>bitset</code> class template specializations can
</pre>
</blockquote>
<p>
-Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+Make a corresponding change in 20.3.6.1 [bitset.cons], p2:
</p>
<blockquote>
<p>
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:
+in 20.3.6 [template.bitset], p1, as shown below:
</p>
<blockquote>
<pre>// element access:
</pre>
</blockquote>
<p>
-And add a description of the new member function to 23.3.5.2 [bitset.members],
+And add a description of the new member function to 20.3.6.2 [bitset.members],
below the description of the existing <code>to_ulong()</code> (if
possible), with the following text:
</p>
<hr>
<h3><a name="695"></a>695. ctype<char>::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>Section:</b> 22.4.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <code>ctype<char>::classic_table()</code> static member
Make the <code>ctype<char>::classic_table()</code> and
<code>ctype<char>::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:
+specialization in 22.4.1.3 [facet.ctype.special] as shown below:
</p>
<blockquote>
<pre> static locale::id id;
<hr>
+<h3><a name="698"></a>698. <tt>system_error</tt> needs <tt>const char*</tt> constructors</h3>
+<p><b>Section:</b> 19.5.5.1 [syserr.syserr.overview] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-24 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In 19.5.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.2 [std.exceptions],
+or <tt>ios_base::failure</tt> in 27.5.2.1.1 [ios::failure]), only overloads with with
+<tt>const string&</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>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+This proposed wording assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a> has been accepted and applied to the working paper.
+</p>
+
+<p>
+Change 19.5.5.1 [syserr.syserr.overview] Class system_error overview, as indicated:
+</p>
+
+<blockquote><pre>public:
+ system_error(error_code ec, const string& what_arg);
+ <ins>system_error(error_code ec, const char* what_arg);</ins>
+ system_error(error_code ec);
+ system_error(int ev, const error_category* ecat,
+ const string& what_arg);
+ <ins>system_error(int ev, const error_category* ecat,
+ const char* what_arg);</ins>
+ system_error(int ev, const error_category* ecat);
+</pre></blockquote>
+
+<p>
+To 19.5.5.2 [syserr.syserr.members] Class system_error members add:
+</p>
+
+<blockquote>
+<pre>system_error(error_code ec, const char* what_arg);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
+</p>
+</blockquote>
+
+<pre>system_error(int ev, const error_category* ecat, const char* what_arg);
+</pre>
+
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
<h3><a name="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>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-07-01 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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>
<hr>
<h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3>
-<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
+<p><b>Section:</b> 20.3.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-07-01 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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>
<p><b>Proposed resolution:</b></p>
<p>
-Change 20.2.2 [forward]:
+Change 20.3.2 [forward]:
</p>
<blockquote>
<hr>
<h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3>
-<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-07-03</p>
+<p><b>Section:</b> 23.4.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-07-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>map::at()</tt> need a complexity specification.
<p><b>Proposed resolution:</b></p>
<p>
-Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]:
+Add the following to the specification of <tt>map::at()</tt>, 23.4.1.2 [map.access]:
</p>
<blockquote>
<p>
<hr>
<h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3>
-<p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p>
+<p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2007-07-08 <b>Last modified:</b> 2008-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The current working draft has a type-trait <tt>decay</tt> in 20.5.7 [meta.trans.other].
+The current working draft has a type-trait <tt>decay</tt> in 20.6.7 [meta.trans.other].
</p>
<p>
<p><b>Proposed resolution:</b></p>
<p>
-In 20.5.7 [meta.trans.other] change the last sentence:
+In 20.6.7 [meta.trans.other] change the last sentence:
</p>
<blockquote><p>
</p></blockquote>
<p>
-In 20.4.1.3 [tuple.creation]/1 change:
+In 20.5.2.2 [tuple.creation]/1 change:
</p>
<blockquote><p>
<hr>
<h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p>
+<p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2007-07-08 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16
-and <tt>make_tuple()</tt> in 20.4.1.3 [tuple.creation].
+The current draft has <tt>make_pair()</tt> in 20.3.3 [pairs]/16
+and <tt>make_tuple()</tt> in 20.5.2.2 [tuple.creation].
<tt>make_tuple()</tt> detects the presence of
<tt>reference_wrapper<X></tt> arguments and "unwraps" the reference in
such cases. <tt>make_pair()</tt> would OTOH create a
<p><b>Proposed resolution:</b></p>
<p>
-In 20.2 [utility] change the synopsis for make_pair() to read
+In 20.3 [utility] change the synopsis for make_pair() to read
</p>
<blockquote><pre>template <class T1, class T2>
</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:
+In 20.3.3 [pairs]/16 change the declaration to match the above synopsis.
+Then change the 20.3.3 [pairs]/17 to:
</p>
<blockquote>
<hr>
-<h3><a name="710"></a>710. Missing postconditions</h3>
-<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3>
+<p><b>Section:</b> 21.2.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-08-13 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.
+The changes made for <tt>constexpr</tt> in 21.2.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.2.1 [char.traits.require].
</p>
-<p><i>[
-Bellevue:
-]</i></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>&</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.2.3.1 [char.traits.specializations.char],
+21.2.3.2 [char.traits.specializations.char16_t], 21.2.3.3 [char.traits.specializations.char32_t],
+and 21.2.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>
+
+<p><i>[
+Post Sophia Antipolis
+]</i></p>
+
+
+<blockquote>
+Moved from Pending NAD Editorial to Review. The proposed wording appears to be correct but non-editorial.
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="710"></a>710. Missing postconditions</h3>
+<p><b>Section:</b> 20.8.13.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-08-24 <b>Last modified:</b> 2008-09-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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+A discussion on
+<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
+has identified a contradiction in the <tt>shared_ptr</tt> specification.
+The <tt>shared_ptr</tt> move constructor and the cast functions are
+missing postconditions for the <tt>get()</tt> accessor.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
<blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Add to 20.7.12.2.1 [util.smartptr.shared.const]:
+Add to 20.8.13.2.1 [util.smartptr.shared.const]:
</p>
<blockquote>
</blockquote>
<p>
-Add to 20.7.12.2.10 [util.smartptr.shared.cast]:
+Add to 20.8.13.2.10 [util.smartptr.shared.cast]:
</p>
<blockquote>
</p>
<p>
-Change 20.7.12.2.10 [util.smartptr.shared.cast]:
+Change 20.8.13.2.10 [util.smartptr.shared.cast]:
</p>
<blockquote>
<hr>
<h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Marc Paterno <b>Date:</b> 2007-08-25</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
+<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Marc Paterno <b>Opened:</b> 2007-08-25 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
One of the motivations for incorporating <tt>seed_seq::size()</tt>
was to simplify the wording
-in other parts of 26.4 [rand].
+in other parts of 26.5 [rand].
As a side effect of resolving related issues,
all such references
to <tt>seed_seq::size()</tt> will have been excised.
<hr>
+<h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3>
+<p><b>Section:</b> 25.5.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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.5.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> (where <i>N</i> == <i>last</i> - <i>first</i> )
+comparisons<del> on the average</del>.<del><sup>266)</sup></del>
+</p>
+<p>
+<del><sup>266)</sup>
+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="714"></a>714. <tt>search_n</tt> complexity is too lax</h3>
+<p><b>Section:</b> 25.3.12 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The complexity for <tt>search_n</tt> (25.3.12 [alg.search] par 7) is specified as "At most
+(last - first ) * count applications of the corresponding predicate if
+count is positive, or 0 otherwise." This is unnecessarily pessimistic.
+Regardless of the value of count, there is no reason to examine any
+element in the range more than once.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the complexity to "At most (last - first) applications of the corresponding predicate".
+</p>
+
+<blockquote>
+<pre>template<class ForwardIterator, class Size, class T>
+ ForwardIterator
+ search_n(ForwardIterator first , ForwardIterator last , Size count ,
+ const T& value );
+
+template<class ForwardIterator, class Size, class T,
+ class BinaryPredicate>
+ ForwardIterator
+ search_n(ForwardIterator first , ForwardIterator last , Size count ,
+ const T& 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>.
+</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#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
+<p><b>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 *
+The complexity for <tt>minmax_element</tt> (25.5.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
<p><b>Proposed resolution:</b></p>
<p>
-Change 25.3.7 [alg.min.max] to:
+Change 25.5.7 [alg.min.max] to:
</p>
<blockquote>
<hr>
+<h3><a name="720"></a>720. Omissions in constexpr usages</h3>
+<p><b>Section:</b> 23.3.1 [array], 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-25 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<ol>
+<li>
+The member function <tt>bool array<T,N>::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<N>::test() const</tt> must be a
+<tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
+bitset<N>::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
+</li>
+<li>
+I wonder how the constructor <tt>bitset<N>::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><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+We handle this as two parts
+</p>
+<ol>
+<li>
+The proposed resolution is correct; move to ready.
+</li>
+<li>
+The issue points out a real problem, but the issue is larger than just
+this solution. We believe a paper is needed, applying the full new
+features of C++ (including extensible literals) to update <tt>std::bitset</tt>.
+We note that we do not consider this new work, and that is should be
+handled by the Library Working Group.
+</li>
+</ol>
+<p>
+In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>In the class template definition of 23.3.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 20.3.6 [template.bitset]/p. 1 change</p>
+<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
+</pre></blockquote>
+
+<p>
+and in 20.3.6.2 [bitset.members] change
+</p>
+
+<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
+</pre></blockquote>
+
+</li>
+</ol>
+
+
+
+
+
+<hr>
<h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p>
+<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-27 <b>Last modified:</b> 2008-09-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-In the listing of 26.7 [c.math], table 108: Header <tt><cmath></tt> synopsis I miss
+In the listing of 26.8 [c.math], table 108: Header <tt><cmath></tt> synopsis I miss
the following C99 functions (from 7.12.11.2):
</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>
+In 26.8 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt>
just after the existing entry <tt>nan</tt>.
</p>
<hr>
-<h3><a name="740"></a>740. Please remove <tt>*_ptr<T[N]></tt></h3>
-<p><b>Section:</b> 20.7.11.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Herb Sutter <b>Date:</b> 2007-10-04</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3>
+<p><b>Section:</b> 26.5.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Please don't provide <tt>*_ptr<T[N]></tt>. It doesn't enable any useful
-bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
-<tt>shared_ptr<T[N]></tt> yields a <tt>shared_ptr<T[N-1]></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.
+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>
<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><T[N]></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.
+I see two possible resolutions:
</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>
+<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>
-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<T[N]></tt> which equally makes the smart pointer more like
-<tt>std::array.</tt> :-)
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for further discussion.
</p>
<p><i>[
<blockquote>
-<p>Suggestion that fixed-size array instantiations are going to fail at
-compile time anyway (if we remove specialization) due to pointer decay,
-at least that appears to be result from available compilers.
-</p>
<p>
-So concerns about about requiring static_assert seem unfounded.
-</p>
-<p>After a little more experimentation with compiler, it appears that
-fixed size arrays would only work at all if we supply these explicit
-specialization. So removing them appears less breaking than originally
-thought.
+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>
-straw poll unanimous move to Ready.
+Take the proposed recommendation in N2424 and move to REVIEW.
</p>
</blockquote>
+
<p><b>Proposed resolution:</b></p>
+
<p>
-Change the synopsis under 20.7.11 [unique.ptr] p2:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
</p>
-<blockquote><pre>...
-template<class T> struct default_delete;
-template<class T> struct default_delete<T[]>;
-<del>template<class T, size_t N> struct default_delete<T[N]>;</del>
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
-template<class T, class D = default_delete<T>> class unique_ptr;
-template<class T, class D> class unique_ptr<T[], D>;
-<del>template<class T, class D, size_t N> class unique_ptr<T[N], D>;</del>
-...
-</pre></blockquote>
-<p>
-Remove the entire section 20.7.11.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete<T[N]></tt></b>.
-</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>
-<p>
-Remove the entire section 20.7.11.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
-and its subsections: 20.7.11.4.1 [unique.ptr.compiletime.dtor], 20.7.11.4.2 [unique.ptr.compiletime.observers],
-20.7.11.4.3 [unique.ptr.compiletime.modifiers].
-</p>
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Note the main part of the issue is resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>.
+</blockquote>
<hr>
-<h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.7.12.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<h3><a name="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3>
+<p><b>Section:</b> 26.5.8.4.3 [rand.dist.norm.chisq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a> in Kona the following note was made:
+<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>
-<blockquote><p>
-We may need to open an issue to deal with the question of
-whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
-</p></blockquote>
-
<p>
-This issue was opened in response to that note.
+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>
-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.
+<b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters
+to double.
</p>
<p><i>[
<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>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
<p>
-Concern that the three signatures for swap is needlessly complicated,
-but this issue merely brings shared_ptr into equal complexity with the
-rest of the library. Will open a new issue for concern about triplicate
-signatures.
+Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test.
</p>
<p>
-Adopt issue as written.
+Marc Paterno: Ask implementers whether floating-point is a significant burden.
+</p>
+<p>
+Alisdair: It's neater to do it now, do ask Bill Plauger.
+</p>
+<p>
+Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent.
</p>
</blockquote>
+
<p><b>Proposed resolution:</b></p>
<p>
-Change the synopsis in 20.7.12.2 [util.smartptr.shared]:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
</p>
-<blockquote><pre>void swap(shared_ptr&<ins>&</ins> r);
-...
-template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
-<ins>template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
-template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);</ins>
-</pre></blockquote>
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
+
+<blockquote>
<p>
-Change 20.7.12.2.4 [util.smartptr.shared.mod]:
+In 26.5.8.4.3 [rand.dist.norm.chisq]:
</p>
-<blockquote><pre>void swap(shared_ptr&<ins>&</ins> r);
-</pre></blockquote>
+<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>
+
+<p>
+In 26.5.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>
+
+<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>
+Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>".
+</p>
+
+<p>
+Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>".
+</p>
+</blockquote>
+
+<p>
+In 26.5.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>
+Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
+</p>
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="740"></a>740. Please remove <tt>*_ptr<T[N]></tt></h3>
+<p><b>Section:</b> X [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2007-10-04 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Please don't provide <tt>*_ptr<T[N]></tt>. It doesn't enable any useful
+bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
+<tt>shared_ptr<T[N]></tt> yields a <tt>shared_ptr<T[N-1]></tt>, but that promising path
+immediately falters on <tt>op--</tt> which can't reliably dereference because we
+don't know the lower bound). Also, most buffers you'd want to point to
+don't have a compile-time known size.
+</p>
+
+<p>
+To enable any bounds-checking would require run-time information, with
+the usual triplet: base (lower bound), current offset, and max offset
+(upper bound). And I can sympathize with the point of view that you
+wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
+follow the <tt><T[N]></tt> path, especially not with additional functions to
+query the bounds etc., because this sets wrong user expectations by
+embarking on a path that doesn't go all the way to bounds checking as it
+seems to imply.
+</p>
+
+<p>
+If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
+<tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
+user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
+debug builds and not doing so on release builds (for example).
+</p>
+
+<p>
+Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart
+pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I
+don't agree, but if that were true that would be another reason to
+remove <tt>*_ptr<T[N]></tt> which equally makes the smart pointer more like
+<tt>std::array.</tt> :-)
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>Suggestion that fixed-size array instantiations are going to fail at
+compile time anyway (if we remove specialization) due to pointer decay,
+at least that appears to be result from available compilers.
+</p>
+<p>
+So concerns about about requiring static_assert seem unfounded.
+</p>
+<p>After a little more experimentation with compiler, it appears that
+fixed size arrays would only work at all if we supply these explicit
+specialization. So removing them appears less breaking than originally
+thought.
+</p>
+<p>
+straw poll unanimous move to Ready.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis under 20.8.12 [unique.ptr] p2:
+</p>
+
+<blockquote><pre>...
+template<class T> struct default_delete;
+template<class T> struct default_delete<T[]>;
+<del>template<class T, size_t N> struct default_delete<T[N]>;</del>
+
+template<class T, class D = default_delete<T>> class unique_ptr;
+template<class T, class D> class unique_ptr<T[], D>;
+<del>template<class T, class D, size_t N> class unique_ptr<T[N], D>;</del>
+...
+</pre></blockquote>
+
+<p>
+Remove the entire section 20.8.12.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete<T[N]></tt></b>.
+</p>
+
+<p>
+Remove the entire section X [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
+and its subsections: [unique.ptr.compiletime.dtor], [unique.ptr.compiletime.observers],
+ [unique.ptr.compiletime.modifiers].
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
+<p><b>Section:</b> 20.8.13.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a> in Kona the following note was made:
+</p>
+
+<blockquote><p>
+We may need to open an issue to deal with the question of
+whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
+</p></blockquote>
+
+<p>
+This issue was opened in response to that note.
+</p>
+
+<p>
+I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both
+appropriate, and consistent with how other library components are currently specified.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Concern that the three signatures for swap is needlessly complicated,
+but this issue merely brings shared_ptr into equal complexity with the
+rest of the library. Will open a new issue for concern about triplicate
+signatures.
+</p>
+<p>
+Adopt issue as written.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 20.8.13.2 [util.smartptr.shared]:
+</p>
+
+<blockquote><pre>void swap(shared_ptr&<ins>&</ins> r);
+...
+template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
+<ins>template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);</ins>
+</pre></blockquote>
+
+<p>
+Change 20.8.13.2.4 [util.smartptr.shared.mod]:
+</p>
+
+<blockquote><pre>void swap(shared_ptr&<ins>&</ins> r);
+</pre></blockquote>
<p>
-Change 20.7.12.2.9 [util.smartptr.shared.spec]:
+Change 20.8.13.2.9 [util.smartptr.shared.spec]:
</p>
<blockquote><pre>template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
<hr>
<h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</h3>
-<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
+<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Without some lifetime guarantee, it is hard to know how this type can be
<p><b>Proposed resolution:</b></p>
<p>
-Change 18.7.5 [propagation]/7:
+Change 18.8.5 [propagation]/7:
</p>
<blockquote>
<hr>
<h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3>
-<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
+<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I understand that the attempt to copy an exception may run out of memory,
<p><b>Proposed resolution:</b></p>
<p>
-Add the following exemption clause to 17.4.4.9 [res.on.exception.handling]:
+Add the following exemption clause to 17.6.4.10 [res.on.exception.handling]:
</p>
<blockquote>
<hr>
<h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor<T>::value</tt> is true if T has 'a' nothrow copy constructor.</h3>
-<p><b>Section:</b> 20.5.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
+<p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Unfortunately a class can have multiple copy constructors, and I believe to
<p><b>Proposed resolution:</b></p>
<p>
-Change 20.5.4.3 [meta.unary.prop]:
+Change 20.6.4.3 [meta.unary.prop]:
</p>
<blockquote>
<hr>
-<h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3>
-<p><b>Section:</b> 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-10-31</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
+<h3><a name="752"></a>752. Allocator complexity requirement</h3>
+<p><b>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2007-10-11 <b>Last modified:</b> 2009-03-09</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#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom:
+Did LWG recently discuss X [allocator.requirements]-2, which states that "All the operations
+on the allocators are expected to be amortized constant time."?
</p>
-
-<blockquote><pre>vector<int> v;
-...
-v.swap(vector<int>(v)); // shrink to fit
-</pre>
-<blockquote><p>
-or:
-</p></blockquote>
-<pre>vector<int>(v).swap(v); // shrink to fit
-</pre>
-<blockquote><p>
-or:
-</p></blockquote>
-<pre>swap(v, vector<int>(v)); // shrink to fit
-</pre>
-</blockquote>
-
<p>
-A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via:
+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. 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>
-
-<blockquote><pre>string s;
-...
-s.reserve(0);
-</pre></blockquote>
-
<p>
-Neither of these is at all obvious to beginners, and even some
-experienced C++ programmers are not aware that shrink-to-fit is
-trivially available.
+<tt>Allocate()</tt> more blatantly takes time proportional to the size of the
+object if you mix in GC. But it's not really a new problem, and I think
+we'd be confusing things by leaving the bogus requirements there. The
+current requirement on <tt>allocate()</tt> is generally not important anyway,
+since it takes O(size) to construct objects in the resulting space.
+There are real performance issues here, but they're all concerned with
+the constants, not the asymptotic complexity.
</p>
+
+
+<p><b>Proposed resolution:</b></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.
+Change X [allocator.requirements]/2:
</p>
+
+<blockquote>
<p>
-The proposed resolution addresses these concerns. The proposed function
-takes no arguments to keep the solution simple and focused.
+-2- Table 39 describes the requirements on types manipulated through
+allocators. <del>All the operations on the allocators are expected to be
+amortized constant time.</del> Table 40 describes the
+requirements on allocator types.
</p>
+</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>
-To Class template basic_string 21.3 [basic.string] synopsis,
-Class template vector 23.2.6 [vector] synopsis, and Class
-vector<bool> 23.2.7 [vector.bool] synopsis, add:
-</p>
-<blockquote><pre>
-void shrink_to_fit();
-</pre></blockquote>
+
+<hr>
+<h3><a name="753"></a>753. Move constructor in draft</h3>
+<p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Yechezkel Mett <b>Opened:</b> 2007-10-14 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-To basic_string capacity 21.3.4 [string.capacity] and vector
-capacity 23.2.6.2 [vector.capacity], add:
+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>
+<tt>MoveConstructible</tt> requirements are defined in Table 33 in X [utility.arg.requirements] as
+follows:
+</p>
+
+<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>
+(where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
+</p>
+
+<p>
+So I assume the move constructor is the constructor that would be used
+in filling the above requirement.
+</p>
+
+<p>
+For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in
+23.3.6.4 [vector.modifiers] we have
+</p>
+
+<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>
+
+<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>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add new defintions to 17.3 [definitions]:
+</p>
+
+<blockquote>
+<p>
+<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>
+
+
+
+
+
+
+<hr>
+<h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3>
+<p><b>Section:</b> 23.3.6.2 [vector.capacity], 21.4.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-10-31 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom:
+</p>
+
+<blockquote><pre>vector<int> v;
+...
+v.swap(vector<int>(v)); // shrink to fit
+</pre>
+<blockquote><p>
+or:
+</p></blockquote>
+<pre>vector<int>(v).swap(v); // shrink to fit
+</pre>
+<blockquote><p>
+or:
+</p></blockquote>
+<pre>swap(v, vector<int>(v)); // shrink to fit
+</pre>
+</blockquote>
+
+<p>
+A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via:
+</p>
+
+<blockquote><pre>string s;
+...
+s.reserve(0);
+</pre></blockquote>
+
+<p>
+Neither of these is at all obvious to beginners, and even some
+experienced C++ programmers are not aware that shrink-to-fit is
+trivially available.
+</p>
+<p>
+Lack of explicit functions to perform these commonly requested
+operations makes vector and string less usable for non-experts. Because
+the idioms are somewhat obscure, code readability is impaired. It is
+also unfortunate that two similar vector-like containers use different
+syntax for the same operation.
+</p>
+<p>
+The proposed resolution addresses these concerns. The proposed function
+takes no arguments to keep the solution simple and focused.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+To Class template basic_string 21.4 [basic.string] synopsis,
+Class template vector 23.3.6 [vector] synopsis, and Class
+vector<bool> 23.3.7 [vector.bool] synopsis, add:
+</p>
+
+<blockquote><pre>
+void shrink_to_fit();
+</pre></blockquote>
+
+<p>
+To basic_string capacity 21.4.4 [string.capacity] and vector
+capacity 23.3.6.2 [vector.capacity], add:
+</p>
+
+<blockquote>
<pre>void shrink_to_fit();
</pre>
<blockquote>
</blockquote>
<p><i>[
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a> has been added to deal with this issue with respect to <tt>deque</tt>.
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a> has been added to deal with this issue with respect to <tt>deque</tt>.
]</i></p>
<hr>
-<h3><a name="759"></a>759. A reference is not an object</h3>
-<p><b>Section:</b> 2
3.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-11-06</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
+<h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3>
+<p><b>Section:</b> 2
0.8.13.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> Joe Gottman <b>Opened:</b> 2007-10-31 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-23.1 [container.requirements] says:
+Consider the following program:
</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>
+<blockquote><pre>int main() {
+ shared_ptr<int> p(nullptr);
+ return 0;
+}
+</pre></blockquote>
<p>
-A reference is not an object, but this sentence appears to claim so.
+This program will fail to compile because <tt>shared_ptr</tt> uses the following
+template constructor to construct itself from pointers:
</p>
+<blockquote><pre>template <class Y> shared_ptr(Y *);
+</pre></blockquote>
+
<p>
-What is probably meant here:
+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<T *>(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<T*>(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<T *>(0))</tt> may not.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></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.
+<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>
+<p>
+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>
+<p>
+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>
+<p>
+Move to Ready, modulo editorial comments
+</p>
</blockquote>
+<p><i>[
+post Bellevue Peter adds:
+]</i></p>
+
+<blockquote>
+<p>
+The following wording changes are less intrusive:
+</p>
+
+<p>
+In 20.8.13.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>
-<p><b>Proposed resolution:</b></p>
<p>
-Change 23.1 [container.requirements]:
+(Absence of explicit intentional.)
</p>
+<p>
+<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><pre>template<class D> shared_ptr(nullptr_t p, D d);
+template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
+</pre></blockquote>
+
+<p>
+after
+</p>
+
+<blockquote><pre>template<class Y, class D> shared_ptr(Y* p, D d);
+template<class Y, class D, class A> 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><i>[
+Sophia Antipolis:
+]</i></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.
+<p>
+We want to remove the reset functions from the proposed resolution.
+</p>
+<p>
+The remaining proposed resolution text (addressing the constructors) are wanted.
+</p>
+<p>
+Disposition: move to review. The review should check the wording in the then-current working draft.
+</p>
</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.8.13.2 [util.smartptr.shared] p4, add to the definition/synopsis
+of <tt>shared_ptr</tt>:
+</p>
+<blockquote><pre>template<class D> shared_ptr(nullptr_t p, D d);
+template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
+</pre></blockquote>
+<p>
+after
+</p>
+
+<blockquote><pre>template<class Y, class D> shared_ptr(Y* p, D d);
+template<class Y, class D, class A> shared_ptr(Y* p, D d, A 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#WP">WP</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>. It acts
-like <tt>operator[]()</tt>, except it throws an exception when the input key is
-not found. It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the
-key doesn't have a default constructor, it is an error if the key is
-not found, or the user wants to avoid accidentally adding an element to
-the map. For exactly these same reasons, <tt>at()</tt> would be equally useful
-in <tt>std::unordered_map</tt>.
+In 20.8.13.2.1 [util.smartptr.shared.const] add:
+</p>
+
+<blockquote><pre>template<class D> shared_ptr(nullptr_t p, D d);
+template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
+</pre></blockquote>
+
+<p>
+after
</p>
+<blockquote><pre>template<class Y, class D> shared_ptr(Y* p, D d);
+template<class Y, class D, class A> shared_ptr(Y* p, D d, A a);
+</pre></blockquote>
+
+<p>
+(reusing the following paragraphs 20.8.13.2.1 [util.smartptr.shared.const]/9-13 that speak of p.)
+</p>
+
+<p>
+In 20.8.13.2.1 [util.smartptr.shared.const]/10, change
+</p>
+
+<blockquote>
+<i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that <i>owns</i> the
+<del>pointer</del> <ins>object</ins> <tt>p</tt> and the deleter <tt>d</tt>. The second
+constructor shall use a copy of <tt>a</tt> to allocate memory for internal use.
+</blockquote>
+
+
+<p><b>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+"pointer" is changed to "object" to handle the fact that nullptr_t isn't a pointer.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="759"></a>759. A reference is not an object</h3>
+<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2007-11-06 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+23.2 [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.2 [container.requirements]:
+</p>
+
+<blockquote>
+-12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del>
+<ins>An object bound to an rvalue
+reference parameter of a member function of a container shall not be
+an element</ins>
+of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o
+diagnostic required.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3>
+<p><b>Section:</b> 23.5.1.2 [unord.map.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-11-15 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>. It acts
+like <tt>operator[]()</tt>, except it throws an exception when the input key is
+not found. It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the
+key doesn't have a default constructor, it is an error if the key is
+not found, or the user wants to avoid accidentally adding an element to
+the map. For exactly these same reasons, <tt>at()</tt> would be equally useful
+in <tt>std::unordered_map</tt>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.5.1 [unord.map]):
+</p>
+
+<blockquote><pre>mapped_type& at(const key_type& k);
+const mapped_type &at(const key_type &k) const;
+</pre></blockquote>
+
+<p>
+Add the following definitions to 23.5.1.2 [unord.map.elem]:
+</p>
+
+<blockquote>
+<pre>mapped_type& at(const key_type& k);
+const mapped_type &at(const key_type &k) const;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element
+whose key is equivalent to <tt>k</tt>.
+</p>
+<p>
+<i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element
+is present.
+</p>
+</blockquote>
+</blockquote>
+
+<p><i>[
+Bellevue: Editorial note: the "(unique)" differs from map.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3>
+<p><b>Section:</b> 20.8.12 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-11-30 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+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.6.3.8 [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>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<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>
+The proposed changes in the following revision refers to the current state of
+N2521 including the assumption that X [unique.ptr.compiletime] will be removed
+according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>.
+</p>
+<p>
+The specialization <tt>unique_ptr<T[]></tt> has some more restrictive constraints on
+type-completeness on <tt>T</tt> than <tt>unique_ptr<T></tt>. The following proposed wordings
+try to cope with that. If the committee sees less usefulness on relaxed
+constraints on <tt>unique_ptr<T[]></tt>, the alternative would be to stop this relaxation
+e.g. by adding one further bullet to 20.8.12.3 [unique.ptr.runtime]/1:
+"<tt>T</tt> shall be a complete type, if used as template argument of
+<tt>unique_ptr<T[], D></tt>
+</p>
+<p>
+This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, but it seems not to cause any
+problems with this one,
+because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict
+with the here discussed
+ones, provided that <tt>D::pointer</tt>'s operations (including default
+construction, copy construction/assignment,
+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>
+
+<ol>
+<li>
+<p>
+In 20.8.12 [unique.ptr]/2 add as the last sentence to the existing para:
+</p>
+
+<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>
+
+<li>
+<p>
+20.8.12.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
+</p>
+
+<blockquote>
+<p><i>[
+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>
+
+<li>
+<p>
+In 20.8.12.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
+</p>
+
+<blockquote>
+<p>
+<i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor
+of <tt>D</tt> shall not throw an exception.</del>
+<del><tt>D</tt> must not be a reference type.</del>
+<ins>
+<tt>D</tt> shall be default constructible, and that construction
+shall not throw an exception.
+</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<Y*, X*></tt>, which
+again requires Completeness of <tt>Y</tt>, if <tt>!SameType<X, Y></tt>
+]</i></p>
+
+</blockquote>
+</li>
+
+<li>
+<p>
+Merge 20.8.12.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
+of 12, but transferring the "requires" to 13:
+</p>
+
+<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>
+
+<li>
+20.8.12.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
+</li>
+<li>
+<p>20.8.12.2.1 [unique.ptr.single.ctor]/21:</p>
+
+<blockquote>
+<i>Requires:</i> If <tt>D</tt> is not a reference type, construction of
+the deleter <tt>D</tt> from an rvalue of type <tt>E</tt> shall be well
+formed and shall not throw an exception. If <tt>D</tt> is a reference
+type, then <tt>E</tt> shall be the same type as <tt>D</tt> (diagnostic
+required). <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt>.
+<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
+be complete types. <i>-- end note</i>]</ins>
+</blockquote>
+
+<p><i>[
+N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt>
+is completely defined, because it requires that <tt>Convertible<U*, T*></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>
+
+<li>
+<p>
+20.8.12.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
+</p>
+<blockquote>
+<p>
+<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
+shall have well-defined behavior, and shall not throw exceptions.
+<ins>[<i>Note:</i> The use of <tt>default_delete</tt> requires <tt>T</tt> to
+be a complete type. <i>-- end note</i>]</ins>
+</p>
+<p><i>[
+N.B.: This requirement ensures that the whole responsibility on
+type-completeness of <tt>T</tt> is delegated to this expression.
+]</i></p>
+
+</blockquote>
+</li>
+
+<li>
+<p>
+20.8.12.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>
+
+<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>
+
+</li>
+
+<li>
+<p>
+20.8.12.2.3 [unique.ptr.single.asgn]/6:
+</p>
+
+<blockquote>
+<i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
+<tt>D</tt> shall not throw an exception. <tt>U*</tt> shall be implicitly
+convertible to <tt>T*</tt>.
+<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
+be complete types. <i>-- end note</i>]</ins>
+</blockquote>
+
+<p><i>[
+N.B.: The current wording of p. 6 already implicitly guarantees that
+<tt>U</tt> is completely defined, because it requires that <tt>Convertible<U*, T*></tt>
+is true, see (6)+(8).
+]</i></p>
+
+</li>
+
+<li>
+<p>
+20.8.12.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>
+
+</li>
+
+<li>
+20.8.12.2.4 [unique.ptr.single.observers]/1+4+7+9+11:
+</li>
+
+<blockquote>
+<pre>T* operator->() const;</pre>
+<blockquote>
+<ins><i>Note:</i> Use typically requires <tt>T</tt> shall be complete. <i>-- end note</i>]</ins>
+</blockquote>
+</blockquote>
+
+<li>
+20.8.12.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
+</li>
+
+<li>
+<p>
+20.8.12.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.8.12.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
+</li>
+
+<li>
+<p>
+20.8.12.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1:
+</p>
+
+<blockquote>
+<p>
+A specialization for array types is provided with a slightly altered interface.
+</p>
+
+<ul>
+<li>
+...
+</li>
+<li>
+<ins><tt>T</tt> shall be a complete type.</ins>
+</li>
+</ul>
+</blockquote>
+</li>
+</ol>
+
+<p><i>[
+post Bellevue: Daniel provided revised wording.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3>
+<p><b>Section:</b> 23.2 [container.requirements], 23.2.5.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Ion Gaztañaga <b>Opened:</b> 2007-12-22 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+23.2 [container.requirements]p10 states:
+</p>
+
+<blockquote>
+<p>
+Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
+additional requirements:
+</p>
+<ul>
+
+<li>[...]</li>
+
+<li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li>
+
+</ul>
+</blockquote>
+
+<p>
+23.3.2.3 [deque.modifiers] and 23.3.6.4 [vector.modifiers] offer
+additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and
+<tt>erase()</tt> members. However, 23.2 [container.requirements]p10
+does not mention 23.2.5.1 [unord.req.except] that specifies exception
+safety guarantees
+for unordered containers. In addition, 23.2.5.1 [unord.req.except]p1
+offers the following guaratee for
+<tt>erase()</tt>:
+</p>
+
+<blockquote>
+No <tt>erase()</tt> function throws an exception unless that exception
+is thrown by the container's Hash or Pred object (if any).
+</blockquote>
+
+<p>
+Summary:
+</p>
+
+<p>
+According to 23.2 [container.requirements]p10 no
+<tt>erase()</tt> function should throw an exception unless otherwise
+specified. Although does not explicitly mention 23.2.5.1 [unord.req.except], this section offers additional guarantees
+for unordered containers, allowing <tt>erase()</tt> to throw if
+predicate or hash function throws.
+</p>
+
+<p>
+In contrast, associative containers have no exception safety guarantees
+section so no <tt>erase()</tt> function should throw, <em>including
+<tt>erase(k)</tt></em> that needs to use the predicate function to
+perform its work. This means that the predicate of an associative
+container is not allowed to throw.
+</p>
+
+<p>
+So:
+</p>
+
+<ol>
+<li>
+<tt>erase(k)</tt> for associative containers is not allowed to throw. On
+the other hand, <tt>erase(k)</tt> for unordered associative containers
+is allowed to throw.
+</li>
+<li>
+<tt>erase(q)</tt> for associative containers is not allowed to throw. On
+the other hand, <tt>erase(q)</tt> for unordered associative containers
+is allowed to throw if it uses the hash or predicate.
+</li>
+<li>
+To fulfill 1), predicates of associative containers are not allowed to throw.
+Predicates of unordered associative containers are allowed to throw.
+</li>
+<li>
+2) breaks a widely used programming pattern (flyweight pattern) for
+unordered containers, where objects are registered in a global map in
+their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is
+allowed to throw, the destructor of the object would need to rethrow the
+exception or swallow it, leaving the object registered.
+</li>
+</ol>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Create a new sub-section of 23.2.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
+safety guarantees".
+</p>
+
+<blockquote>
+<p>
+1 For associative containers, no <tt>clear()</tt> function throws an exception.
+<tt>erase(k)</tt> does not throw an exception unless that exception is thrown by
+the container's Pred object (if any).
+</p>
+
+<p>
+2 For associative containers, if an exception is thrown by any operation
+from within an <tt>insert()</tt> function inserting a single element, the
+<tt>insert()</tt> function has no effect.
+</p>
+
+<p>
+3 For associative containers, no <tt>swap</tt> function throws an exception
+unless that exception is thrown by the copy constructor or copy
+assignment operator of the container's Pred object (if any).
+</p>
+</blockquote>
+
+<p>
+Change 23.2.5.1 [unord.req.except]p1:
+</p>
+
+<blockquote>
+For unordered associative containers, no <tt>clear()</tt> function
+throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt>
+<del>function</del> <ins>does not</ins> throw<del>s</del> an exception
+unless that exception is thrown by the container's Hash or Pred object
+(if any).
+</blockquote>
+
+<p>
+Change 23.2 [container.requirements]p10 to add references to new sections:
+</p>
+
+<blockquote>
+Unless otherwise specified (see [deque.modifiers]<ins>,</ins>
+<del>and</del> [vector.modifiers]<ins>, [associative.req.except],
+[unord.req.except]</ins>) all container types defined in this clause meet
+the following additional requirements:
+</blockquote>
+
+<p>
+Change 23.2 [container.requirements]p10 referring to <tt>swap</tt>:
+</p>
+
+<blockquote>
+<ul>
+<li>
+no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown
+by the copy constructor or assignment operator of the container's
+Compare object (if any; see [associative.reqmts])</del>.
+</li>
+</ul>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="768"></a>768. Typos in [atomics]?</h3>
+<p><b>Section:</b> 29.5.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2007-12-28 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+in the latest publicly available draft, paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>,
+in section 29.5.3 [atomics.types.generic], the following specialization of the template
+<tt>atomic<></tt> is provided for pointers:
+</p>
+
+<blockquote><pre>template <class T> struct atomic<T*> : atomic_address {
+ T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
+ T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
+
+ atomic() = default;
+ constexpr explicit atomic(T);
+ atomic(const atomic&) = delete;
+ atomic& operator=(const atomic&) = delete;
+
+ T* operator=(T*) volatile;
+ T* operator++(int) volatile;
+ T* operator--(int) volatile;
+ T* operator++() volatile;
+ T* operator--() volatile;
+ T* operator+=(ptrdiff_t) volatile;
+ T* operator-=(ptrdiff_t) volatile;
+};
+</pre></blockquote>
+
+<p>
+First of all, there is a typo in the non-default constructor which
+should take a <tt>T*</tt> rather than a <tt>T</tt>.
+</p>
+
+<p>
+As you can see, the specialization redefine and therefore hide a few
+methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>,
+<tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened
+to the other methods, in particular these ones:
+</p>
+
+<blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile;
+T* load( memory_order = memory_order_seq_cst ) volatile;
+T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
+bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;
+bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
+</pre></blockquote>
+
+<p>
+By reading paper
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>,
+I see that the
+definition of the specialization <tt>atomic<T*></tt> matches the one in the
+draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt>
+and <tt>compare_swap()</tt> are indeed present.
+</p>
+
+<p>
+Strangely, the example implementation does not redefine the method
+<tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not
+hiding the <tt>void*</tt> signature from the base class makes the class
+error-prone to say the least: it lets you assign pointers of any type to
+a <tt>T*</tt>, without any hint from the compiler.
+</p>
+
+<p>
+Is there a true intent to remove them from the specialization or are
+they just missing from the definition because of a mistake?
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+The proposed revisions are accepted.
+</p>
+<p>
+Further discussion: why is the ctor labeled "constexpr"? Lawrence said
+this permits the object to be statically initialized, and that's
+important because otherwise there would be a race condition on
+initialization.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 29.5.3 [atomics.types.generic]:
+</p>
+
+<blockquote><pre>template <class T> struct atomic<T*> : 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*&, T*, memory_order, memory_order ) volatile;</ins>
+ <ins>bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;</ins>
+
+ T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
+ T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
+
+ atomic() = default;
+ constexpr explicit atomic(T<ins>*</ins>);
+ atomic(const atomic&) = delete;
+ atomic& operator=(const atomic&) = delete;
+
+ T* operator=(T*) volatile;
+ T* operator++(int) volatile;
+ T* operator--(int) volatile;
+ T* operator++() volatile;
+ T* operator--() volatile;
+ T* operator+=(ptrdiff_t) volatile;
+ T* operator-=(ptrdiff_t) volatile;
+};
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3>
+<p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-10 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+N2461 already replaced in 20.7.16.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>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+In 20.7 [function.objects], header <tt><functional></tt> synopsis replace:
+</p>
+
+<blockquote><pre>template<class R, class... ArgTypes>
+ bool operator==(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template<class R, class... ArgTypes>
+ bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
+template<class R, class... ArgTypes>
+ bool operator!=(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template<class R, class... ArgTypes>
+ bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
+</pre></blockquote>
+
+<p>
+In the class function synopsis of 20.7.16.2 [func.wrap.func] replace
+</p>
+
+<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+...
+function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+</pre></blockquote>
+
+<p>
+In 20.7.16.2 [func.wrap.func], "Null pointer comparisons" replace:
+</p>
+
+<blockquote><pre>template <class R, class... ArgTypes>
+ bool operator==(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template <class R, class... ArgTypes>
+ bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
+template <class R, class... ArgTypes>
+ bool operator!=(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template <class R, class... ArgTypes>
+ bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
+</pre></blockquote>
+
+<p>
+In 20.7.16.2.1 [func.wrap.func.con], replace
+</p>
+
+<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+...
+function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+</pre></blockquote>
+
+<p>
+In 20.7.16.2.6 [func.wrap.func.nullptr], replace
+</p>
+
+<blockquote><pre>template <class R, class... ArgTypes>
+ bool operator==(const function<R(ArgTypes...)>& f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template <class R, class... ArgTypes>
+ bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>& f);
+</pre></blockquote>
+
+<p>
+and replace
+</p>
+
+<blockquote><pre>template <class R, class... ArgTypes>
+ bool operator!=(const function<R(ArgTypes...)>& f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template <class R, class... ArgTypes>
+ bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>& f);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="770"></a>770. std::function should use rvalue swap</h3>
+<p><b>Section:</b> 20.7.16 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-10 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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.7 [function.objects], header <tt><functional></tt> synopsis, just below of
+</p>
+
+<blockquote><pre>template<class R, class... ArgTypes>
+ void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
+<ins>template<class R, class... ArgTypes>
+ void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
+template<class R, class... ArgTypes>
+ void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins>
+</pre></blockquote>
+
+<p>
+In 20.7.16.2 [func.wrap.func] class <tt>function</tt> definition, change
+</p>
+
+<blockquote><pre>void swap(function&<ins>&</ins>);
+</pre></blockquote>
+
+<p>
+In 20.7.16.2 [func.wrap.func], just below of
+</p>
+
+<blockquote><pre>template <class R, class... ArgTypes>
+ void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
+<ins>template <class R, class... ArgTypes>
+ void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
+template <class R, class... ArgTypes>
+ void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins>
+</pre></blockquote>
+
+<p>
+In 20.7.16.2.2 [func.wrap.func.mod] change
+</p>
+
+<blockquote><pre>void swap(function&<ins>&</ins> other);
+</pre></blockquote>
+
+<p>
+In 20.7.16.2.7 [func.wrap.func.alg] add the two overloads
+</p>
+
+<blockquote><pre><ins>template<class R, class... ArgTypes>
+ void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2);
+template<class R, class... ArgTypes>
+ void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2);</ins>
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3>
+<p><b>Section:</b> 21.5 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-13 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.5 [string.conversions]
+have throws clauses (paragraphs 8 and 16) which say:
+</p>
+
+<blockquote>
+<i>Throws:</i> nothing
+</blockquote>
+
+<p>
+Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value
+this throws clause is impossible to realize in general, since the <tt>basic_string</tt>
+constructors can fail due to out-of-memory conditions. Either these throws
+clauses should be removed or should be more detailled like:
+</p>
+
+<blockquote>
+<i>Throws:</i> Nothing if the string construction throws nothing
+</blockquote>
+
+<p>
+Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt>
+overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The
+header <tt><string></tt> synopsis of 21.3 [string.classes] is correct in this
+regard).
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 21.5 [string.conversions], remove the paragraphs 8 and 16.
+</p>
+
+<blockquote>
+<pre>string to_string(long long val);
+string to_string(unsigned long long val);
+string to_string(long double val);
+</pre>
+<blockquote>
+<del><i>Throws:</i> nothing</del>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre><ins>w</ins>string to_wstring(long long val);
+<ins>w</ins>string to_wstring(unsigned long long val);
+<ins>w</ins>string to_wstring(long double val);
+</pre>
+<blockquote>
+<del><i>Throws:</i> nothing</del>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="772"></a>772. Impossible return clause in [string.conversions]</h3>
+<p><b>Section:</b> 21.5 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-13 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The return clause 21.5 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
+overloads says:
+</p>
+
+<blockquote>
+<i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character
+representation of the value of its argument that would be generated by
+calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>,
+or <tt>L"%f"</tt>, respectively.
+</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><wchar.h>/<cwchar></tt>, but this has the non-equivalent
+declaration:
+</p>
+
+<blockquote><pre>int swprintf(wchar_t * restrict s, size_t n,
+const wchar_t * restrict format, ...);
+</pre></blockquote>
+
+<p>
+therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the current wording of 21.5 [string.conversions]/p. 15 to:
+</p>
+
+<blockquote>
+<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a
+<tt>wstring</tt> object holding the character representation of the
+value of its argument that would be generated by calling
+<tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt,
+val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>,
+<tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt>
+designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>.
+</blockquote>
+
+<p>
+[Hint to the editor: The resolution also adds to mention the name of
+the format specifier "fmt"]
+</p>
+
+<p>
+I also would like to remark that the current wording of it's equivalent
+paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>.
+</p>
+
+<p>
+Change the current wording of 21.5 [string.conversions]/p. 7 to:
+</p>
+
+<blockquote>
+<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the
+character representation of the value of its argument that would be
+generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of
+<tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal
+character buffer of sufficient size</ins>.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3>
+<p><b>Section:</b> 20.5.2.3 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-01-16 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The tuple element access API identifies the element in the sequence
+using signed integers, and then goes on to enforce the requirement that
+I be >= 0. There is a much easier way to do this - declare I as
+<tt>unsigned</tt>.
+</p>
+<p>
+In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API.
+</p>
+<p>
+A second suggestion is that it is hard to imagine an API that deduces
+and index at compile time and returns a reference throwing an exception.
+Add a specific <em>Throws:</em> Nothing paragraph to each element
+access API.
+</p>
+<p>
+In addition to <code>tuple</code>, update the API applies to
+<code>pair</code> and <code>array</code>, and should be updated
+accordingly.
+</p>
+
+<p>
+A third observation is that the return type of the <code>get</code>
+functions for <code>std::pair</code> is pseudo-code, but it is not
+clearly marked as such. There is actually no need for pseudo-code as
+the return type can be specified precisely with a call to
+<code>tuple_element</code>. This is already done for
+<code>std::tuple</code>, and <code>std::array</code> does not have a
+problem as all elements are of type <code>T</code>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Update header <utility> synopsis in 20.3 [utility]
+</p>
+<pre><em>// 20.2.3, tuple-like access to pair:</em>
+template <class T> class tuple_size;
+template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element;
+
+template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >;
+template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >;
+template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >;
+
+template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
+ <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(std::pair<T1, T2>&);
+template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
+ const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const std::pair<T1, T2>&);
+</pre>
+<p>
+Update <strong>20.3.3 [pairs] Pairs</strong>
+</p>
+<pre>template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
+ <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(pair<T1, T2>&);
+template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
+ const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const pair<T1, T2>&);
+</pre>
+<p>
+<del>24 <em>Return type:</em> If <code>I == 0</code> then <code>P</code> is <code>T1</code>, if <code>I == 1</code> then <code>P</code> is <code>T2</code>, and otherwise the program is ill-formed.</del>
+</p>
+<p>
+25 <em>Returns:</em> If <code>I == 0</code> returns <code>p.first</code>, <del>otherwise</del> <ins>if <code>I == 1</code></ins> returns <code>p.second</code><ins>, and otherwise the program is ill-formed</ins>.
+</p>
+<p>
+<ins><em>Throws:</em> Nothing.</ins>
+</p>
+
+
+<p>
+Update header <tuple> synopsis in 20.5 [tuple] with a APIs as below:
+</p>
+<pre>template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// undefined</em>
+template <<del>int</del><ins>size_t</ins> I, class... Types> class tuple_element<I, tuple<Types...> >;
+
+<em>// 20.3.1.4, element access:</em>
+template <<del>int</del><ins>size_t</ins> I, class... Types>
+ typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&);
+template <<del>int</del><ins>size_t</ins> I, class ... types>
+ typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&);
+</pre>
+
+<p>
+Update <strong>20.5.2.3 [tuple.helper] Tuple helper classes</strong>
+</p>
+<pre>template <<del>int</del><ins>size_t</ins> I, class... Types>
+class tuple_element<I, tuple<Types...> > {
+public:
+ typedef TI type;
+};</pre>
+<p>
+1 <em>Requires:</em> <code><del>0 <= I and </del>I < 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.5.2.4 [tuple.elem] Element access</strong>
+</p>
+<pre>template <<del>int</del><ins>size_t</ins> I, class... types >
+typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t);
+</pre>
+1 <em>Requires:</em> <code><del>0 <= I and </del>I < 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 <<del>int</del><ins>size_t</ins> I, class... types>
+typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>& t);
+</pre>
+<p>
+3 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
+</p>
+<p>
+4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
+</p>
+<p>
+<ins><em>Throws:</em> Nothing.</ins>
+</p>
+
+
+<p>
+Update header <array> synopsis in 20.3 [utility]
+</p>
+<pre>template <class T> class tuple_size; <em>// forward declaration</em>
+template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// forward declaration</em>
+template <class T, size_t N>
+ struct tuple_size<array<T, N> >;
+template <<del>int</del><ins>size_t</ins> I, class T, size_t N>
+ struct tuple_element<I, array<T, N> >;
+template <<del>int</del><ins>size_t</ins> I, class T, size_t N>
+ T& get(array<T, N>&);
+template <<del>int</del><ins>size_t</ins> I, class T, size_t N>
+ const T& get(const array<T, N>&);
+</pre>
+
+<p>
+Update <strong>23.3.1.7 [array.tuple] Tuple interface to class template array</strong>
+</p>
+<pre>tuple_element<<ins>size_t </ins>I, array<T, N> >::type
+</pre>
+<p>
+3 <em>Requires:</em> <code><del>0 <= </del>I < 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 <<del>int</del><ins>size_t</ins> I, class T, size_t N> T& get(array<T, N>& a);
+</pre>
+<p>
+5 <em>Requires:</em> <code><del>0 <= </del>I < 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 <<del>int</del><ins>size_t</ins> I, class T, size_t N> const T& get(const array<T, N>& a);
+</pre>
+<p>
+6 <em>Requires:</em> <code><del>0 <= </del>I < 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="776"></a>776. Undescribed assign function of std::array</h3>
+<p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-20 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The class template array synopsis in 23.3.1 [array]/3 declares a member
+function
+</p>
+
+<blockquote><pre>void assign(const T& 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>
+I found only one reference to this function in the issue list,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a> where the question is raised:
+</p>
+
+<blockquote>
+what's the effect of calling <tt>assign(T&)</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.3.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& u);
+</pre>
+
+<p>
+1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
+</p>
+</blockquote>
+
+<p>
+[N.B: I wonder, why class <tt>array</tt> does not have a "modifiers"
+section. If it had, then <tt>assign</tt> would naturally belong to it]
+</p>
+
+<p>
+Change the synopsis in 23.3.1 [array]/3:
+</p>
+
+<blockquote><pre>template <class T, size_t N>
+struct array {
+ ...
+ void <del>assign</del> <ins>fill</ins>(const T& 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="777"></a>777. Atomics Library Issue</h3>
+<p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-01-21 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The load functions are defined as
+</p>
+
+<blockquote><pre>C atomic_load(volatile A* object);
+C atomic_load_explicit(volatile A* object, memory_order);
+C A::load(memory_order order = memory_order_seq_cst) volatile;
+</pre></blockquote>
+
+<p>
+which prevents their use in <tt>const</tt> contexts.
+</p>
+
+<p><i>[
+post Bellevue Peter adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a
+subtle point here. Atomic loads do not generally write to the object, except
+potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the
+architecture, a dummy write with the same value may be required to be issued
+by the atomic load to maintain sequential consistency. This, in turn, may
+make the following code:
+</p>
+
+<blockquote><pre>const atomic_int x{};
+
+int main()
+{
+ x.load();
+}
+</pre></blockquote>
+
+<p>
+dump core under a straightforward implementation that puts const objects in
+a read-only section.
+</p>
+<p>
+There are ways to sidestep the problem, but it needs to be considered.
+</p>
+<p>
+The tradeoff is between making the data member of the atomic types
+mutable and requiring the user to explicitly mark atomic members as
+mutable, as is already the case with mutexes.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>.
+</p>
+
+<blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object);
+C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order);
+C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3>
+<p><b>Section:</b> 20.3.6.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-01-24 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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>
+A small issue with <tt>std::bitset</tt>: it does not have any constructor
+taking a string literal, which is clumsy and looks like an oversigt when
+we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library.
+</p>
+
+<p>
+Suggestion: Add
+</p>
+
+<blockquote><pre>explicit bitset( const char* str );
+</pre></blockquote>
+
+<p>
+to std::bitset.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to synopsis in 20.3.6 [template.bitset]
+</p>
+
+<blockquote><pre>explicit bitset( const char* str );
+</pre></blockquote>
+
+<p>
+Add to synopsis in 20.3.6.1 [bitset.cons]
+</p>
+
+<blockquote><pre>explicit bitset( const char* str );
+</pre>
+<p>
+<i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>.
+</p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="779"></a>779. Resolution of #283 incomplete</h3>
+<p><b>Section:</b> 25.4.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-25 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> did not resolve similar necessary changes for algorithm
+<tt>remove_copy[_if]</tt>,
+which seems to be an oversight.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 25.4.8 [alg.remove]/p.6, replace the N2461 requires clause with:
+</p>
+
+<blockquote>
+<i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
+and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be
+valid.</ins>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3>
+<p><b>Section:</b> 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-26 <b>Last modified:</b> 2009-03-21</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+A comparision of the N2461 header <tt><complex></tt> synopsis ([complex.syn])
+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>
+I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent
+C++ functions. This addition is easy to do in one sentence (delegation to C99
+function).
+</p>
+
+<p>
+Please note also that the current entry <tt>polar</tt>
+in 26.4.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<T></tt> arguments, which are not accepted by
+this function.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 26.4.1 [complex.syn] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>:
+</p>
+
+<blockquote><pre>template<class T> complex<T> conj(const complex<T>&);
+<ins>template<class T> complex<T> proj(const complex<T>&);</ins>
+template<class T> complex<T> fabs(const complex<T>&);
+</pre></blockquote>
+
+<p>
+In 26.4.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add:
+</p>
+
+<blockquote>
+<pre>template<class T> complex<T> proj(const complex<T>& x);
+</pre>
+<blockquote>
+
+<i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in
+subclause 7.3.9.4."
+</blockquote>
+</blockquote>
+
+<p>
+In 26.4.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to
+the overload list.
+</p>
+
+<blockquote>
+<p>
+The following function templates shall have additional overloads:
+</p>
+<blockquote><pre>arg norm
+conj <del>polar</del> <ins>proj</ins>
+imag real
+</pre></blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</h3>
+<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-27 <b>Last modified:</b> 2009-05-01</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Part of the resolution of n2423, issue 8 was the proposal to
+extend the <tt>seed_seq</tt> constructor accepting an input range
+as follows (which is now part of N2461):
+</p>
+
+<blockquote><pre>template<class InputIterator,
+size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
+seed_seq(InputIterator begin, InputIterator end);
+</pre></blockquote>
+
+<p>
+First, the expression <tt>iterator_traits<InputIterator>::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.9.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>
+
+
+<blockquote>
+<p>
+Fermilab does not have a strong opinion. Would prefer to go with
+solution A. Bill agrees that solution A is a lot simpler and does the
+job.
+</p>
+<p>
+Proposed Resolution: Accept Solution A.
+</p>
+</blockquote>
+
+<p>
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a> claims to make this issue moot.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol type="A">
+<li>
+<p>
+In 26.5.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace:
+</p>
+
+<blockquote><pre>class seed_seq
+{
+public:
+ ...
+ template<class InputIterator<del>,
+ size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
+ seed_seq(InputIterator begin, InputIterator end<ins>,
+ size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</ins>);
+ ...
+};
+</pre></blockquote>
+
+<p>
+and do a similar replacement in the member description between
+p.3 and p.4.
+</p>
+</li>
+
+<li>
+<p>
+In 26.5.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the
+member description between p.3 and p.4 replace:
+</p>
+
+<blockquote><pre>template<class InputIterator<del>,
+ size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
+ seed_seq(InputIterator begin, InputIterator end);
+<ins>template<class InputIterator, size_t u>
+seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins>
+</pre></blockquote>
+
+<p>
+In 26.5.1 [rand.synopsis], header <tt><random></tt> synopsis, immediately after the
+class <tt>seed_seq</tt> declaration <em>and</em> in 26.5.7.1 [rand.util.seedseq]/2, immediately
+after the class <tt>seed_seq</tt> definition add:
+</p>
+
+<blockquote><pre>template<size_t u, class InputIterator>
+ seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+</pre></blockquote>
+
+<p>
+In 26.5.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
+</p>
+
+<blockquote>
+<p>
+The first constructor behaves as if it would provide an
+integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value
+<tt>numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</tt>.
+</p>
+<p>
+The second constructor uses an implementation-defined mechanism
+to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and
+is called by the function <tt>make_seed_seq</tt>.
+</p>
+</blockquote>
+
+<p>
+In 26.5.7.1 [rand.util.seedseq], just after the last paragraph add:
+</p>
+
+<blockquote>
+<pre>template<size_t u, class InputIterator>
+ seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+</pre>
+<blockquote>
+<p>
+where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type.
+</p>
+<p>
+<i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>;
+</p>
+</blockquote>
+</blockquote>
+
+</li>
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3>
+<p><b>Section:</b> 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-02-01 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.id">issues</a> in [thread.thread.id].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The current working paper
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>,
+integrated just before Bellevue) is
+not completely clear whether a given <tt>thread::id</tt> value may be reused once
+a thread has exited and has been joined or detached. Posix allows
+thread ids (<tt>pthread_t</tt> values) to be reused in this case. Although it is
+not completely clear whether this originally was the right decision, it
+is clearly the established practice, and we believe it was always the
+intent of the C++ threads API to follow Posix and allow this. Howard
+Hinnant's example implementation implicitly relies on allowing reuse
+of ids, since it uses Posix thread ids directly.
+</p>
+
+<p>
+It is important to be clear on this point, since it the reuse of thread
+ids often requires extra care in client code, which would not be
+necessary if thread ids were unique across all time. For example, a
+hash table indexed by thread id may have to be careful not to associate
+data values from an old thread with a new one that happens to reuse the
+id. Simply removing the old entry after joining a thread may not be
+sufficient, if it creates a visible window between the join and removal
+during which a new thread with the same id could have been created and
+added to the table.
+</p>
+
+<p><i>[
+post Bellevue Peter adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to
+reconsider fixing this by disallowing reuse, rather than explicitly allowing
+it. Dealing with thread id reuse is an incredibly painful exercise that
+would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over
+and over.
+</p>
+<p>
+In addition, it would be nice if a <tt>thread::id</tt> could be manipulated
+atomically in a lock-free manner, as motivated by the recursive lock
+example:
+</p>
+
+<p>
+<a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a>
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a sentence to 30.3.1.1 [thread.thread.id]/p1:
+</p>
+
+<blockquote>
+<p>
+An object of type <code>thread::id</code> provides
+a unique identifier for each thread of execution
+and a single distinct value for all thread objects
+that do not represent a thread of execution ([thread.threads.class]).
+Each thread of execution has a <code>thread::id</code>
+that is not equal to the <code>thread::id</code>
+of other threads of execution
+and that is not equal to
+the <code>thread::id</code> of <code>std::thread</code> objects
+that do not represent threads of execution.
+<ins>The library may reuse the value of a <code>thread::id</code> of a
+terminated thread that can no longer be joined.</ins>
+</p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3>
+<p><b>Section:</b> 25.5.3.4 [binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-09-08 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In 25.5.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>
+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>
+All existing libraries I'm aware of, delegate to
+<tt>lower_bound</tt> (+ one further comparison). Since
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>
+has now WP status, the resolution of #787 should
+be brought in-line with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> by changing the <tt>+ 2</tt>
+to <tt>+ O(1)</tt>.
+</p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Alisdair prefers to apply an upper bound instead of O(1), but that would
+require fixing for <tt>lower_bound</tt>, <tt>upper_bound</tt> etc. as well. If he really
+cares about it, he'll send an issue to Howard.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 25.5.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="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3>
+<p><b>Section:</b> X [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<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.5.1 [rand.synopsis].
+</p>
+<p>
+Remove X [rand.adapt.xor] <tt>xor_combine_engine</tt>.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3>
+<p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>piecewise_constant_distribution</tt> is undefined for a range with just one
+endpoint. (Probably should be the same as an empty range.)
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.5.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
+</p>
+
+<blockquote>
+b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>,
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3>
+<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-02-14 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf">N2521</a>
+and its earlier predecessors have moved the old binders from
+[lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming
+of the template parameter names (<tt>Operation -> 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>
+Change D.8.1 [depr.lib.binder.1st]:
+</p>
+
+<blockquote>
+<pre>template <class Fn>
+class binder1st
+ : public unary_function<typename Fn::second_argument_type,
+ typename Fn::result_type> {
+protected:
+ Fn <del>fn</del> <ins>op</ins>;
+ typename Fn::first_argument_type value;
+public:
+ binder1st(const Fn& x,
+ const typename Fn::first_argument_type& y);
+ typename Fn::result_type
+ operator()(const typename Fn::second_argument_type& x) const;
+ typename Fn::result_type
+ operator()(typename Fn::second_argument_type& x) const;
+};
+</pre>
+
+<blockquote>
+<p>
+-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
+</p>
+<p>
+-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change D.8.3 [depr.lib.binder.2nd]:
+</p>
+
+<blockquote>
+<pre>template <class Fn>
+class binder2nd
+ : public unary_function<typename Fn::first_argument_type,
+ typename Fn::result_type> {
+protected:
+ Fn <del>fn</del> <ins>op</ins>;
+ typename Fn::second_argument_type value;
+public:
+ binder2nd(const Fn& x,
+ const typename Fn::second_argument_type& y);
+ typename Fn::result_type
+ operator()(const typename Fn::first_argument_type& x) const;
+ typename Fn::result_type
+ operator()(typename Fn::first_argument_type& x) const;
+};
+</pre>
+
+<blockquote>
+<p>
+-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
+</p>
+<p>
+-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3>
+<p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-02-24 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<ol type="A">
+<li>
+<p>
+19.5.2.2 [syserr.errcode.overview]/1, class <tt>error_code</tt> and
+19.5.3.2 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses
+declare an expository data member <tt>cat_</tt>:
+</p>
+<blockquote><pre>const error_category& cat_; // exposition only
+</pre></blockquote>
+<p>
+which is used to define the semantics of several members. The decision
+to use a member of reference type lead to several problems:
+</p>
+<ol>
+<li>
+The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent.
+</li>
+<li>
+The post conditions of all modifiers from
+19.5.2.4 [syserr.errcode.modifiers] and 19.5.3.4 [syserr.errcondition.modifiers], resp.,
+cannot be fulfilled.
+</li>
+</ol>
+<p>
+The simple fix would be to replace the reference by a pointer member.
+</p>
+</li>
+
+<li>
+I would like to give the editorial remark that in both classes the
+constrained <tt>operator=</tt>
+overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
+usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
+parameter the return type would be defined to be <tt>void&</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.5.1.2 [syserr.errcat.virtuals]/10, 19.5.2.5 [syserr.errcode.observers]/8, and
+19.5.3.5 [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-defects.html#771">771</a>).
+</li>
+</ol>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Part A: NAD (editorial), cleared by the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.
+</p>
+<p>
+Part B: Technically correct, save for typo. Rendered moot by the concept proposal
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2620.html">N2620</a>) NAD (editorial).
+</p>
+<p>
+Part C: We agree; this is consistent with the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>.
+</p>
+<p>
+Howard: please ping Beman, asking him to clear away parts A and B from
+the wording in the proposed resolution, so it is clear to the editor
+what needs to be applied to the working paper.
+</p>
+<p>
+Beman provided updated wording. Since issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a> is not going
+forward, the provided wording includes resolution of part A.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Resolution of part A:
+</p>
+<blockquote>
+<p>
+Change 19.5.2.2 [syserr.errcode.overview] Class error_code overview synopsis as indicated:
+</p>
+
+<blockquote><pre>private:
+ int val_; // exposition only
+ const error_category<del>&</del><ins>*</ins> cat_; // exposition only
+</pre></blockquote>
+
+<p>
+Change 19.5.2.3 [syserr.errcode.constructors] Class error_code constructors as indicated:
+</p>
+
+<blockquote>
+<pre>error_code();
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>system_category</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+<pre>error_code(int val, const error_category& cat);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 19.5.2.4 [syserr.errcode.modifiers] Class error_code modifiers as indicated:
+</p>
+
+<blockquote>
+<pre>void assign(int val, const error_category& cat);
+</pre>
+<blockquote>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 19.5.2.5 [syserr.errcode.observers] Class error_code observers as indicated:
+</p>
+
+<blockquote>
+const error_category& category() const;
+<blockquote>
+<p>
+<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 19.5.3.2 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated:
+</p>
+
+<blockquote><pre>private:
+ int val_; // exposition only
+ const error_category<del>&</del><ins>*</ins> cat_; // exposition only
+</pre></blockquote>
+
+<p>
+Change 19.5.3.3 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
+</p>
+<p><i>[
+(If the proposed resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a> has already been applied, the
+name <tt>posix_category</tt> will have been changed to <tt>generic_category</tt>. That has
+no effect on this resolution.)
+]</i></p>
+
+
+<blockquote>
+<pre>error_condition();
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>posix_category</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+<pre>error_condition(int val, const error_category& cat);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 19.5.3.4 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
+</p>
+
+<blockquote>
+void assign(int val, const error_category& cat);
+<blockquote>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 19.5.3.5 [syserr.errcondition.observers] Class error_condition observers as indicated:
+</p>
+
+<blockquote>
+const error_category& category() const;
+<blockquote>
+<p>
+<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+</blockquote>
+
+<p>
+Resolution of part C:
+</p>
+
+<blockquote>
+
+<p>
+In 19.5.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
+</p>
+
+<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.5.2.5 [syserr.errcode.observers], remove the throws clause p. 8.
+</p>
+
+<blockquote>
+<pre>string message() const;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>category().message(value())</tt>.
+</p>
+<p>
+<del><i>Throws:</i> Nothing.</del>
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+In 19.5.3.5 [syserr.errcondition.observers], remove the throws clause p. 6.
+</p>
+
+<blockquote>
+<pre>string message() const;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>category().message(value())</tt>.
+</p>
+<p>
+<del><i>Throws:</i> Nothing.</del>
+</p>
+</blockquote>
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
+<p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-02-24 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+19.5 [syserr]
+</p>
+
+<blockquote><pre>namespace posix_error {
+ enum posix_errno {
+ address_family_not_supported, // EAFNOSUPPORT
+ ...
+</pre></blockquote>
+
+<p>
+should rather use the new scoped-enum facility (7.2 [dcl.enum]),
+which would avoid the necessity for a new <tt>posix_error</tt>
+namespace, if I understand correctly.
+</p>
+
+<p><i>[
+Further discussion:
+]</i></p>
+
+
+<blockquote>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>,
+Strongly Typed Enums, since renamed Scoped Enums.
+</p>
+<p>
+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.5 [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 <> struct is_error_condition_enum<<del>posix_error::posix_errno</del> <ins>errc</ins>>
+ : public true_type {}
+
+<del>namespace posix_error {</del>
+ error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
+ error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
+<del>} // namespace posix_error</del>
+</pre></blockquote>
+
+<p>
+Change System error support 19.5 [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>
+Change System error support 19.5 [syserr] and its subsections:
+</p>
+
+<blockquote>
+<ul>
+<li>
+remove all occurrences of <tt>posix_error::</tt>
+</li>
+<li>
+change all instances of <tt>posix_errno</tt> to <tt>errc</tt>
+</li>
+<li>
+change all instances of <tt>posix_category</tt> to <tt>generic_category</tt>
+</li>
+<li>
+change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt>
+</li>
+</ul>
+</blockquote>
+
+<p>
+Change Error category objects 19.5.1.5 [syserr.errcat.objects], paragraph 2:
+</p>
+
+<blockquote>
+<i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual
+functions shall behave as specified for the class <tt>error_category</tt>. The
+object's name virtual function shall return a pointer to the string
+<del>"POSIX"</del> <ins>"generic"</ins>.
+</blockquote>
+
+<p>
+Change 19.5.2.6 [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<int>(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
+</blockquote>
+</blockquote>
+
+<p>
+Change 19.5.3.6 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
+</p>
+
+<blockquote>
+<pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
+</pre>
+
+<blockquote>
+<i>Returns:</i> <tt>error_condition(<ins>static_cast<int>(</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="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
+<p><b>Section:</b> 20.8.12.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-03-13 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.modifiers">active issues</a> in [unique.ptr.single.modifiers].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
+</p>
+
+<blockquote>
+<i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+</blockquote>
+
+<p>
+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>
+Two, the special check for <tt>get() == p</tt> is generally not needed and such a
+situation usually indicates an error in the client code, which is being
+masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
+self-resets in 2001 and there were no complaints.
+</p>
+
+<p>
+One might think that self-resets are necessary for operator= to work; it's specified to perform
+</p>
+
+<blockquote><pre>reset( u.release() );
+</pre></blockquote>
+
+<p>
+and the self-assignment
+</p>
+
+<blockquote><pre>p = move(p);
+</pre></blockquote>
+
+<p>
+might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
+performed first, zeroing the stored pointer. In other words, <tt>p.reset(
+q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
+is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
+scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change 20.8.12.2.5 [unique.ptr.single.modifiers]:
+</p>
+
+<blockquote>
+<pre>void reset(T* p = 0);
+</pre>
+<blockquote>
+-4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+</blockquote>
+</blockquote>
+
+<p>
+Change 20.8.12.3.3 [unique.ptr.runtime.modifiers]:
+</p>
+
+<blockquote>
+<pre>void reset(T* p = 0);
+</pre>
+<blockquote>
+<p>...</p>
+<p>
+-2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
+<p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-03-13 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors. I believe the same throws clause
+should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to 20.5.2.1 [tuple.cnstr]:
+</p>
+
+<blockquote>
+<p>
+For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
+or assignment of one of the types in <tt>Types</tt> throws an exception.
+</p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
+<p><b>Section:</b> 20.3.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-03-13 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+p4 (forward) says:
+</p>
+<blockquote>
+<i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
+</blockquote>
+
+<p>
+First of all, lvalue-ness and rvalue-ness are properties of an expression,
+not of a type (see 3.10 [basic.lval]). Thus, the phrasing "Return type" is wrong.
+Second, the phrase says exactly what the core language wording says for
+folding references in 14.4.1 [temp.arg.type]/p4 and for function return values
+in 5.2.2 [expr.call]/p10. (If we feel the wording should be retained, it should
+at most be a note with cross-references to those sections.)
+</p>
+<p>
+The prose after the example talks about "forwarding as an <tt>int&</tt> (an lvalue)" etc.
+In my opinion, this is a category error: "<tt>int&</tt>" is a type, "lvalue" is a
+property of an expression, orthogonal to its type. (Btw, expressions cannot
+have reference type, ever.)
+</p>
+<p>
+Similar with move:
+</p>
+<blockquote>
+Return type: an rvalue.
+</blockquote>
+<p>
+is just wrong and also redundant.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.3.2 [forward] as indicated:
+</p>
+
+<blockquote>
+<pre>template <class T> T&& forward(typename identity<T>::type&& t);
+</pre>
+
+<blockquote>
+<p>...</p>
+<p>
+<del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
+</p>
+<p>...</p>
+<p>
+-7- In the first call to <tt>factory</tt>, <tt>A1</tt> is deduced as <tt>int</tt>, so 2 is forwarded to <tt>A</tt>'s constructor
+as <del>an <tt>int&&</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
+as <tt>int&</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&</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&&</tt> (</del>an rvalue<del>)</del>.
+</p>
+</blockquote>
+
+<pre>template <class T> typename remove_reference<T>::type&& move(T&& t);
+</pre>
+
+<blockquote>
+<p>...</p>
+<p>
+<del><i>Return type:</i> an rvalue.</del>
+</p>
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="809"></a>809. std::swap should be overloaded for array types</h3>
+<p><b>Section:</b> 25.4.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-02-28 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+For the sake of generic programming, the header <code><algorithm></code> should provide an
+overload of <code>std::swap</code> for array types:
+</p><pre>template<class T, size_t N> void swap(T (&a)[N], T (&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<class T> class W {
+public:
+ T data;
+};
+</pre>
+Clearly <code>W<T></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<T></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<class T> void swap(W<T>& x, W<T>& 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<std::string[8]></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<std::string[8]> 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.
+
+
+<p>
+Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
+arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
+means of recursion.
+</p>
+
+<p>
+For your information, there was a discussion on this issue at comp.lang.c++.moderated: <a href="http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9341ebd3635c9c74">[Standard
+Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add an extra condition to the definition of Swappable requirements [swappable] in X [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.4.3 [alg.swap]:
+</p>
+<blockquote>
+<pre>template<class T, size_t N> void swap(T (&a)[N], T (&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="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
+<p><b>Section:</b> 20.8.13.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Matt Austern <b>Opened:</b> 2008-02-26 <b>Last modified:</b> 2008-09-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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Several places in 20.8.13.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
+However, that term is nowhere defined. The closest thing we have to a
+definition is that the default constructor creates an empty <tt>shared_ptr</tt>
+and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
+other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
+are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
+term or stop using it.
+</p><p>
+</p>
+One reason it's not good enough to leave this term up to the reader's
+intuition is that, in light of
+<a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
+and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, most readers'
+intuitive understanding is likely to be wrong. Intuitively one might
+expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
+but, whatever the definition is, that isn't it.
+
+
+<p><i>[
+Peter adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+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>
+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>
+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>
+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>
+Green and red are "nowhere defined" and completely defined at the same time.
+</p>
+</li>
+</ul>
+
+<p>
+Alisdair's wording is fine.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Append the following sentance to 20.8.13.2 [util.smartptr.shared]
+</p>
+<blockquote>
+The <code>shared_ptr</code> class template stores a pointer, usually obtained
+via <code>new</code>. <code>shared_ptr</code> implements semantics of
+shared ownership; the last remaining owner of the pointer is responsible for
+destroying the object, or otherwise releasing the resources associated with
+the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
+a pointer is said to be <i>empty</i>.</ins>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="818"></a>818. wording for memory ordering</h3>
+<p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-03-22 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+29.3 [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>
+To my naked eye, that seems to imply that even an atomic read has both
+acquire and release semantics.
+</p>
+
+<p>
+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>
+So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
+constraints.
+</p>
+
+<p>
+I'm then reading p2, where it says:
+</p>
+
+<blockquote>
+The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
+on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
+are release operations on the affected locations.
+</blockquote>
+
+<p>
+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>
+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.6 [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.3 [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.6 [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>
+
+<p>
+(Since this is exactly the same restriction as for "store", it seems to be a typo.)
+</p>
+
+<p>
+And then: 29.6 [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>
+This is redundant with 1.10 [intro.multithread], see above for the reasoning.
+</p>
+
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
+<p>
+Boehm: "I don't think that this changes anything terribly substantive,
+but it improves the text."
+</p>
+<p>
+Note that "Rephrase the table in as [sic] follows..." should read
+"Replace the table in [atomics.order] with the following...."
+</p>
+<p>
+The proposed resolution needs more work. Crowl volunteered to address
+all of the atomics issues in one paper.
+</p>
+
+<p>
+This issue is addressed in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+edit 29.3 [atomics.order], paragraph 1 as follows.
+</p>
+
+<blockquote>
+<p>
+The enumeration <code>memory_order</code>
+specifies the detailed regular (non-atomic) memory synchronization order
+as defined in <del>Clause 1.7</del> <ins>section 1.10</ins>
+and may provide for operation ordering.
+Its enumerated values and their meanings are as follows:
+</p>
+<blockquote>
+<dl>
+<dt><ins>For <code>memory_order_relaxed</code>,</ins></dt>
+<dd><ins>no operation orders memory.</ins></dd>
+<dt><ins>For <code>memory_order_release</code>,
+<code>memory_order_acq_rel</code>,
+and <code>memory_order_seq_cst</code>,</ins></dt>
+<dd><ins>a store operation performs a release operation
+on the affected memory location.</ins></dd>
+<dt><ins>For <code>memory_order_consume</code>,</ins></dt>
+<dd><ins>a load operation performs a consume operation
+on the affected memory location.</ins></dd>
+<dt><ins>For <code>memory_order_acquire</code>,
+<code>memory_order_acq_rel</code>,
+and <code>memory_order_seq_cst</code>,</ins></dt>
+<dd><ins>a load operation performs an acquire operation
+on the affected memory location.</ins></dd>
+</dl>
+</blockquote>
+</blockquote>
-<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]):
+remove table 136 in 29.3 [atomics.order].
</p>
-<blockquote><pre>mapped_type& at(const key_type& k);
-const mapped_type &at(const key_type &k) const;
-</pre></blockquote>
+<blockquote>
+<table border="1">
+<caption><del>Table 136 — memory_order effects</del></caption>
+<tbody><tr><th><del>Element</del></th><th><del>Meaning</del></th></tr>
+<tr><td valign="top"><del><code>memory_order_relaxed</code></del></td>
+<td valign="top"><del>the operation does not order memory</del></td></tr>
+<tr><td valign="top"><del><code>memory_order_release</code></del></td>
+<td valign="top"><del>the operation
+performs a release operation on the affected memory location,
+thus making regular memory writes visible to other threads
+through the atomic variable to which it is applied</del></td></tr>
+<tr><td valign="top"><del><code>memory_order_acquire</code></del></td>
+<td valign="top"><del>the operation
+performs an acquire operation on the affected memory location,
+thus making regular memory writes in other threads
+released through the atomic variable to which it is applied
+visible to the current thread</del></td></tr>
+<tr><td valign="top"><del><code>memory_order_consume</code></del></td>
+<td valign="top"><del>the operation
+performs a consume operation on the affected memory location,
+thus making regular memory writes in other threads
+released through the atomic variable to which it is applied
+visible to the regular memory reads
+that are dependencies of this consume operation.</del></td></tr>
+<tr><td valign="top"><del><code>memory_order_acq_rel</code></del></td>
+<td valign="top"><del>the operation has both acquire and release semantics</del></td></tr>
+<tr><td valign="top"><del><code>memory_order_seq_cst</code></del></td>
+<td valign="top"><del>the operation has both acquire and release semantics,
+and, in addition, has sequentially-consistent operation ordering</del></td></tr>
+</tbody></table>
+</blockquote>
<p>
-Add the following definitions to 23.4.1.2 [unord.map.elem]:
+edit 29.3 [atomics.order], paragraph 2 as follows.
</p>
<blockquote>
-<pre>mapped_type& at(const key_type& k);
-const mapped_type &at(const key_type &k) const;
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element
-whose key is equivalent to <tt>k</tt>.
-</p>
<p>
-<i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element
-is present.
+<del>The <code>memory_order_seq_cst</code> operations that load a value
+are acquire operations on the affected locations.
+The <code>memory_order_seq_cst</code> operations that store a value
+are release operations on the affected locations.
+In addition, in a consistent execution,
+there</del> <ins>There</ins> <del>must be</del> <ins>is</ins>
+a single total order <var>S</var>
+on all <code>memory_order_seq_cst</code> operations,
+consistent with the happens before order
+and modification orders for all affected locations,
+such that each <code>memory_order_seq_cst</code> operation
+observes either the last preceding modification
+according to this order <var>S</var>,
+or the result of an operation that is not <code>memory_order_seq_cst</code>.
+[<i>Note:</i>
+Although it is not explicitly required that <var>S</var> 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>]
</p>
</blockquote>
-</blockquote>
-
-<p><i>[
-Bellevue: Editorial note: the "(unique)" differs from map.
-]</i></p>
-
<hr>
-<h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3>
-<p><b>Section:</b> 23.1 [container.requirements], 23.1.5.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Ion Gaztañaga <b>Date:</b> 2007-12-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
+<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2008-03-26 <b>Last modified:</b> 2008-09-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#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-23.1 [container.requirements]p10 states:
+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.8.5 [propagation]/7 says "If the
+function needs to allocate memory and the attempt fails, it returns an
+<tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
+doesn't say anything about what should happen if memory allocation
+succeeds but the actual copying fails.
</p>
-<blockquote>
<p>
-Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
-additional requirements:
+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>
-<ul>
-
-<li>[...]</li>
-
-<li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li>
-
-</ul>
-</blockquote>
<p>
-23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer
-additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and
-<tt>erase()</tt> members. However, 23.1 [container.requirements]p10
-does not mention 23.1.5.1 [unord.req.except] that specifies exception
-safety guarantees
-for unordered containers. In addition, 23.1.5.1 [unord.req.except]p1
-offers the following guaratee for
-<tt>erase()</tt>:
+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>
-<blockquote>
-No <tt>erase()</tt> function throws an exception unless that exception
-is thrown by the container's Hash or Pred object (if any).
-</blockquote>
+<p><i>[
+Peter's summary:
+]</i></p>
+
+<blockquote>
<p>
-Summary:
+The current practice is to not have throwing copy constructors in
+exception classes, because this can lead to <tt>terminate()</tt> as described in
+15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems
+consistent and does not introduce any new problems.
</p>
<p>
-According to 23.1 [container.requirements]p10 no
-<tt>erase()</tt> function should throw an exception unless otherwise
-specified. Although does not explicitly mention 23.1.5.1 [unord.req.except], this section offers additional guarantees
-for unordered containers, allowing <tt>erase()</tt> to throw if
-predicate or hash function throws.
+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>
-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.
+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>
-So:
+Option (2) cannot be adopted by itself, because a potential infinite
+recursion will need to be terminated by one of the other options.
</p>
-<ol>
-<li>
-<tt>erase(k)</tt> for associative containers is not allowed to throw. On
-the other hand, <tt>erase(k)</tt> for unordered associative containers
-is allowed to throw.
-</li>
-<li>
-<tt>erase(q)</tt> for associative containers is not allowed to throw. On
-the other hand, <tt>erase(q)</tt> for unordered associative containers
-is allowed to throw if it uses the hash or predicate.
-</li>
-<li>
-To fulfill 1), predicates of associative containers are not allowed to throw.
-Predicates of unordered associative containers are allowed to throw.
-</li>
-<li>
-2) breaks a widely used programming pattern (flyweight pattern) for
-unordered containers, where objects are registered in a global map in
-their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is
-allowed to throw, the destructor of the object would need to rethrow the
-exception or swallow it, leaving the object registered.
-</li>
-</ol>
+</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Create a new sub-section of 23.1.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
-safety guarantees".
+Add the following paragraph after 18.8.5 [propagation]/7:
</p>
<blockquote>
<p>
-1 For associative containers, no <tt>clear()</tt> function throws an exception.
-<tt>erase(k)</tt> does not throw an exception unless that exception is thrown by
-the container's Pred object (if any).
-</p>
-
-<p>
-2 For associative containers, if an exception is thrown by any operation
-from within an <tt>insert()</tt> function inserting a single element, the
-<tt>insert()</tt> function has no effect.
+<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>
-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).
+[<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>
-<p>
-Change 23.1.5.1 [unord.req.except]p1:
-</p>
-<blockquote>
-For unordered associative containers, no <tt>clear()</tt> function
-throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt>
-<del>function</del> <ins>does not</ins> throw<del>s</del> an exception
-unless that exception is thrown by the container's Hash or Pred object
-(if any).
-</blockquote>
-<p>
-Change 23.1 [container.requirements]p10 to add references to new sections:
-</p>
+<p><b>Rationale:</b></p>
+<p><i>[
+San Francisco:
+]</i></p>
-<blockquote>
-Unless otherwise specified (see [deque.modifiers]<ins>,</ins>
-<del>and</del> [vector.modifiers]<ins>, [associative.req.except],
-[unord.req.except]</ins>) all container types defined in this clause meet
-the following additional requirements:
-</blockquote>
+<blockquote>
<p>
-Change 23.1 [container.requirements]p10 referring to <tt>swap</tt>:
+Pete: there may be an implied assumption in the proposed wording that
+current_exception() copies the existing exception object; the
+implementation may not actually do that.
+</p>
+<p>
+Pete will make the required editorial tweaks to rectify this.
</p>
-
-<blockquote>
-<ul>
-<li>
-no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown
-by the copy constructor or assignment operator of the container's
-Compare object (if any; see [associative.reqmts])</del>.
-</li>
-</ul>
</blockquote>
-
<hr>
-<h3><a name="768"></a>768. Typos in [atomics]?</h3>
-<p><b>Section:</b> 2
9.3.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2007-12-28</p>
+<h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
+<p><b>Section:</b> 2
0.8.12.3.3 [unique.ptr.runtime.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-30 <b>Last modified:</b> 2009-03-09</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-in the latest publicly available draft, paper
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>,
-in section 29.3.3 [atomics.types.generic], the following specialization of the template
-<tt>atomic<></tt> is provided for pointers:
+Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> I noticed the following:
</p>
-<blockquote><pre>template <class T> struct atomic<T*> : 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>
+<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+</pre>
- atomic() = default;
- constexpr explicit atomic(T);
- atomic(const atomic&) = delete;
- atomic& operator=(const atomic&) = delete;
+<p>
+-1- <i>Requires:</i> Does not accept pointer types which are convertible
+to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
+required). [<i>Note:</i> One implementation technique is to create a private
+templated overload. <i>-- end note</i>]
+</p>
+</blockquote>
+
+<p>
+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>
- 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><b>Proposed resolution:</b></p>
<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>.
+Add to class template definition in 20.8.12.3 [unique.ptr.runtime]
</p>
+<blockquote>
+<pre>// modifiers
+pointer release();
+void reset(pointer p = pointer());
+<ins>void reset( nullptr_t );</ins>
+<ins>template< typename U > void reset( U ) = delete;</ins>
+void swap(unique_ptr&& u);
+</pre>
+</blockquote>
+
<p>
-As you can see, the specialization redefine and therefore hide a few
-methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>,
-<tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened
-to the other methods, in particular these ones:
+Update 20.8.12.3.3 [unique.ptr.runtime.modifiers]
</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*&, T*, memory_order, memory_order ) volatile;
-bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
-</pre></blockquote>
+<blockquote>
+<pre>void reset(pointer p = pointer());
+<ins>void reset(nullptr_t);</ins>
+</pre>
<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<T*></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.
+<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-defects.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (Ready).
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="823"></a>823. <tt>identity<void></tt> seems broken</h3>
+<p><b>Section:</b> 20.3.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Walter Brown <b>Opened:</b> 2008-04-09 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-Strangely, the example implementation does not redefine the method
-<tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not
-hiding the <tt>void*</tt> signature from the base class makes the class
-error-prone to say the least: it lets you assign pointers of any type to
-a <tt>T*</tt>, without any hint from the compiler.
+N2588 seems to have added an <tt>operator()</tt> member function to the
+<tt>identity<></tt> helper in 20.3.2 [forward]. I believe this change makes it no
+longer possible to instantiate <tt>identity<void></tt>, as it would require
+forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
</p>
<p>
-Is there a true intent to remove them from the specialization or are
-they just missing from the definition because of a mistake?
+Suggested resolution: Specialize <tt>identity<void></tt> so as not to require
+the member function's presence.
</p>
<p><i>[
-Bellevue:
+Sophia Antipolis:
]</i></p>
<blockquote>
<p>
-The proposed revisions are accepted.
+Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>.
</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.
+Alisdair: also consider cv-qualified <tt>void</tt>.
</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
<p>
-Change the synopsis in 29.3.3 [atomics.types.generic]:
+Alberto provided proposed wording.
</p>
-
-<blockquote><pre>template <class T> struct atomic<T*> : 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*&, T*, memory_order, memory_order ) volatile;</ins>
- <ins>bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;</ins>
-
- T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
- T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
-
- atomic() = default;
- constexpr explicit atomic(T<ins>*</ins>);
- atomic(const atomic&) = delete;
- atomic& operator=(const atomic&) = delete;
-
- T* operator=(T*) volatile;
- T* operator++(int) volatile;
- T* operator--(int) volatile;
- T* operator++() volatile;
- T* operator--() volatile;
- T* operator+=(ptrdiff_t) volatile;
- T* operator-=(ptrdiff_t) volatile;
-};
-</pre></blockquote>
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change definition of <tt>identity</tt> in 20.3.2 [forward], paragraph 2, to:
+</p>
+<blockquote><pre>template <class T> struct identity {
+ typedef T type;
+ <ins>requires ReferentType<T></ins>
+ const T& operator()(const T& x) const;
+ };
+</pre></blockquote>
+<p>...</p>
+<blockquote><pre> <ins>requires ReferentType<T></ins>
+ const T& operator()(const T& x) const;
+</pre></blockquote>
-<hr>
-<h3><a name="770"></a>770. std::function should use rvalue swap</h3>
-<p><b>Section:</b> 20.6.15 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
+<p><b>Rationale:</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.
+The point here is to able to write <tt>T&</tt> given <tt>T</tt> and <tt>ReferentType</tt> is
+precisely the concept that guarantees so, according to N2677
+(Foundational concepts). Because of this, it seems preferable than an
+explicit check for <tt>cv void</tt> using <tt>SameType/remove_cv</tt> as it was suggested
+in Sophia. In particular, Daniel remarked that there may be types other
+than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?).
</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.6 [function.objects], header <tt><functional></tt> synopsis, just below of
-</p>
-<blockquote><pre>template<class R, class... ArgTypes>
- void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
-<ins>template<class R, class... ArgTypes>
- void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
-template<class R, class... ArgTypes>
- void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins>
-</pre></blockquote>
+
+<hr>
+<h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
+<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-04-10 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-In 20.6.15.2 [func.wrap.func] class <tt>function</tt> definition, change
+In the current working paper, the <tt><string></tt> header synopsis at the end of
+21.3 [string.classes] lists a single <tt>operator<<</tt> overload
+for <tt>basic_string</tt>.
</p>
-<blockquote><pre>void swap(function&<ins>&</ins>);
+<blockquote><pre>template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+ operator<<(basic_ostream<charT, traits>&& os,
+ const basic_string<charT,traits,Allocator>& str);
</pre></blockquote>
<p>
-In 20.6.15.2 [func.wrap.func], just below of
+The definition in 21.4.8.9 [string.io] lists two:
</p>
-<blockquote><pre>template <class R, class... ArgTypes>
- void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
-<ins>template <class R, class... ArgTypes>
- void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
-template <class R, class... ArgTypes>
- void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins>
+<blockquote><pre>template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+ operator<<(basic_ostream<charT, traits>& os,
+ const basic_string<charT,traits,Allocator>& str);
+
+template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+ operator<<(basic_ostream<charT, traits>&& os,
+ const basic_string<charT,traits,Allocator>& str);
</pre></blockquote>
<p>
-In 20.6.15.2.2 [func.wrap.func.mod] change
+I believe the synopsis in 21.3 [string.classes] is correct, and the first of the two
+signatures in 21.4.8.9 [string.io] should be deleted.
</p>
-<blockquote><pre>void swap(function&<ins>&</ins> other);
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-In 20.6.15.2.7 [func.wrap.func.alg] add the two overloads
+Delete the first of the two signatures in 21.4.8.9 [string.io]:
</p>
-<blockquote><pre><ins>template<class R, class... ArgTypes>
- void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2);
-template<class R, class... ArgTypes>
- void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2);</ins>
-</pre></blockquote>
+<blockquote><pre><del>template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+ operator<<(basic_ostream<charT, traits>& os,
+ const basic_string<charT,traits,Allocator>& str);</del>
+template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+ operator<<(basic_ostream<charT, traits>&& os,
+ const basic_string<charT,traits,Allocator>& str);
+</pre></blockquote>
<hr>
-<h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3>
-<p><b>Section:</b> 20.4.1.4 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-16</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<h3><a name="829"></a>829. current_exception wording unclear about exception type</h3>
+<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-04-20 <b>Last modified:</b> 2008-09-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#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
+<p>Consider this code:</p>
+
+<blockquote>
+<pre>exception_ptr xp;</pre>
+<pre>try {do_something(); }
+
+catch (const runtime_error& ) {xp = current_exception();}
+
+...
+
+rethrow_exception(xp);</pre>
+</blockquote>
+
<p>
-The tuple element access API identifies the element in the sequence
-using signed integers, and then goes on to enforce the requirement that
-I be >= 0. There is a much easier way to do this - declare I as
-<tt>unsigned</tt>.
+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>
-In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API.
+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>
-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.
+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>
-In addition to <code>tuple</code>, update the API applies to
-<code>pair</code> and <code>array</code>, and should be updated
-accordingly.
+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>
-A third observation is that the return type of the <code>get</code>
-functions for <code>std::pair</code> is pseudo-code, but it is not
-clearly marked as such. There is actually no need for pseudo-code as
-the return type can be specified precisely with a call to
-<code>tuple_element</code>. This is already done for
-<code>std::tuple</code>, and <code>std::array</code> does not have a
-problem as all elements are of type <code>T</code>.
-</p>
<p><b>Proposed resolution:</b></p>
+
<p>
-Update header <utility> synopsis in 20.2 [utility]
+After 18.8.5 [propagation] , paragraph 7, add the indicated text:
</p>
-<pre><em>// 20.2.3, tuple-like access to pair:</em>
-template <class T> class tuple_size;
-template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element;
-template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >;
-template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >;
-template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >;
+<blockquote>
+<pre>exception_ptr current_exception();</pre>
-template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
- <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(std::pair<T1, T2>&);
-template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
- const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const std::pair<T1, T2>&);
-</pre>
-<p>
-Update <strong>20.2.3 [pairs] Pairs</strong>
-</p>
-<pre>template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
- <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(pair<T1, T2>&);
-template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
- const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const pair<T1, T2>&);
-</pre>
+<blockquote>
<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>
+<i>Returns:</i> <code>exception_ptr</code> object that refers
+to the currently handled exception <ins>(15.3 [except.handle])</ins> or a copy of the currently handled
+exception, or a null <code>exception_ptr</code> object if no exception is being handled. If
+the function needs to allocate memory and the attempt fails, it returns an
+<code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>.
+It is unspecified whether the return values of two successive calls to
+<code>current_exception</code> refer to the same exception object.
+[<i>Note:</i> that is, it
+is unspecified whether <code>current_exception</code>
+creates a new copy each time it is called.
+<i>-- end note</i>]
</p>
+
<p>
-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>.
+<i>Throws:</i> nothing.
</p>
+
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="842"></a>842. ConstructibleAsElement and bit containers</h3>
+<p><b>Section:</b> 23.2 [container.requirements], 23.3.7 [vector.bool], 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-<ins><em>Throws:</em> Nothing.</ins>
+23.2 [container.requirements]/p3 says:
</p>
+<blockquote>
+Objects stored in these components shall be constructed using
+<tt>construct_element</tt> (20.6.9). For each operation that inserts an
+element of type <tt>T</tt> into a container (<tt>insert</tt>,
+<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
+arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
+as described in table 88. [<i>Note:</i> If the component is instantiated
+with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
+<tt>is_scoped_allocator<A>::value</tt> is <tt>true</tt>), then
+<tt>construct_element</tt> may pass an inner allocator argument to
+<tt>T</tt>'s constructor. <i>-- end note</i>]
+</blockquote>
<p>
-Update header <tuple> synopsis in 20.4 [tuple] with a APIs as below:
+However <tt>vector<bool, A></tt> (23.3.7 [vector.bool]) and <tt>bitset<N></tt>
+(20.3.6 [template.bitset]) store bits, not <tt>bool</tt>s, and <tt>bitset<N></tt>
+does not even have an allocator. But these containers are governed by this clause. Clearly this
+is not implementable.
</p>
-<pre>template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// undefined</em>
-template <<del>int</del><ins>size_t</ins> I, class... Types> class tuple_element<I, tuple<Types...> >;
-<em>// 20.3.1.4, element access:</em>
-template <<del>int</del><ins>size_t</ins> I, class... Types>
- typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&);
-template <<del>int</del><ins>size_t</ins> I, class ... types>
- typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&);
-</pre>
+<p><b>Proposed resolution:</b></p>
<p>
-Update <strong>20.4.1.4 [tuple.helper] Tuple helper classes</strong>
+Change 23.2 [container.requirements]/p3:
</p>
-<pre>template <<del>int</del><ins>size_t</ins> I, class... Types>
-class tuple_element<I, tuple<Types...> > {
-public:
- typedef TI type;
-};</pre>
+
+<blockquote>
+Objects stored in these components shall be constructed using
+<tt>construct_element</tt> (20.6.9)<ins>, unless otherwise specified</ins>.
+For each operation that inserts an
+element of type <tt>T</tt> into a container (<tt>insert</tt>,
+<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
+arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
+as described in table 88. [<i>Note:</i> If the component is instantiated
+with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
+<tt>is_scoped_allocator<A>::value</tt> is <tt>true</tt>), then
+<tt>construct_element</tt> may pass an inner allocator argument to
+<tt>T</tt>'s constructor. <i>-- end note</i>]
+</blockquote>
+
<p>
-1 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
+Change 23.3.7 [vector.bool]/p2:
</p>
+
+<blockquote>
+Unless described below, all operations have the same requirements and semantics as the primary <tt>vector</tt> template,
+except that operations dealing with the <tt>bool</tt> value type map to bit values in the container storage<ins>,
+and <tt>construct_element</tt> (23.2 [container.requirements]) is not used to construct these values</ins>.
+</blockquote>
+
<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.
+Move 20.3.6 [template.bitset] to clause 20.
</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="843"></a>843. Reference Closure</h3>
+<p><b>Section:</b> 20.7.18.1 [func.referenceclosure.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-02 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-Update <strong>20.4.1.5 [tuple.elem] Element access</strong>
+The <tt>std::reference_closure</tt> type has a deleted copy assignment operator
+under the theory that references cannot be assigned, and hence the
+assignment of its reference member must necessarily be ill-formed.
</p>
-<pre>template <<del>int</del><ins>size_t</ins> I, class... types >
-typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t);
-</pre>
-1 <em>Requires:</em> <code><del>0 <= I and </del>I < 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.
+However, other types, notably <tt>std::reference_wrapper</tt> and <tt>std::function</tt>
+provide for the "copying of references", and thus the current definition
+of <tt>std::reference_closure</tt> seems unnecessarily restrictive. In particular,
+it should be possible to write generic functions using both <tt>std::function</tt>
+and <tt>std::reference_closure</tt>, but this generality is much harder when
+one such type does not support assignment.
</p>
-<ins><em>Throws:</em> Nothing.</ins>
-<pre>template <<del>int</del><ins>size_t</ins> I, class... types>
-typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>& t);
-</pre>
<p>
-3 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
+The definition of <tt>reference_closure</tt> does not necessarily imply direct
+implementation via reference types. Indeed, the <tt>reference_closure</tt> is
+best implemented via a frame pointer, for which there is no standard
+type.
</p>
<p>
-4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
+The semantics of assignment are effectively obtained by use of the
+default destructor and default copy assignment operator via
</p>
+
+<blockquote><pre>x.~reference_closure(); new (x) reference_closure(y);
+</pre></blockquote>
+
<p>
-<ins><em>Throws:</em> Nothing.</ins>
+So the copy assignment operator generates no significant real burden
+to the implementation.
</p>
+<p><b>Proposed resolution:</b></p>
<p>
-Update header <array> synopsis in 20.2 [utility]
+In 20.7.18 [func.referenceclosure] Class template reference_closure,
+replace the <tt>=delete</tt> in the copy assignment operator in the synopsis
+with <tt>=default</tt>.
</p>
-<pre>template <class T> class tuple_size; <em>// forward declaration</em>
-template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// forward declaration</em>
-template <class T, size_t N>
- struct tuple_size<array<T, N> >;
-template <<del>int</del><ins>size_t</ins> I, class T, size_t N>
- struct tuple_element<I, array<T, N> >;
-template <<del>int</del><ins>size_t</ins> I, class T, size_t N>
- T& get(array<T, N>&);
-template <<del>int</del><ins>size_t</ins> I, class T, size_t N>
- const T& get(const array<T, N>&);
-</pre>
+
+<blockquote><pre>template<class R , class... ArgTypes >
+ class reference_closure<R (ArgTypes...)> {
+ public:
+ ...
+ reference_closure& operator=(const reference_closure&) = <del>delete</del> <ins>default</ins>;
+ ...
+</pre></blockquote>
<p>
-Update <strong>23.2.1.6 [array.tuple] Tuple interface to class template array</strong>
+In 20.7.18.1 [func.referenceclosure.cons] Construct, copy, destroy,
+add the member function description
</p>
-<pre>tuple_element<<ins>size_t </ins>I, array<T, N> >::type
+
+<blockquote>
+<pre>reference_closure& operator=(const reference_closure& f)
</pre>
+<blockquote>
<p>
-3 <em>Requires:</em> <code><del>0 <= </del>I < N.</code> The program is ill-formed if <code>I</code> is out of bounds.
+<i>Postcondition:</i> <tt>*this</tt> is a copy of <tt>f</tt>.
</p>
<p>
-4 <em>Value:</em> The type <code>T</code>.
+<i>Returns:</i> <tt>*this</tt>.
</p>
-<pre>template <<del>int</del><ins>size_t</ins> I, class T, size_t N> T& get(array<T, N>& a);
-</pre>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="844"></a>844. <tt>complex pow</tt> return type is ambiguous</h3>
+<p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2009-03-21</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-5 <em>Requires:</em> <code><del>0 <= </del>I < N</code>. The program is ill-formed if <code>I</code> is out of bounds.
+The current working draft is in an inconsistent state.
</p>
+
<p>
-<em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
+26.4.8 [complex.transcendentals] says that:
</p>
+
+<blockquote>
+<tt>pow(complex<float>(), int())</tt> returns a <tt>complex<float></tt>.
+</blockquote>
+
<p>
-<ins><em>Throws:</em> Nothing.</ins>
+26.4.9 [cmplx.over] says that:
</p>
-<pre>template <<del>int</del><ins>size_t</ins> I, class T, size_t N> const T& get(const array<T, N>& a);
-</pre>
+
+<blockquote>
+<tt>pow(complex<float>(), int())</tt> returns a <tt>complex<double></tt>.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
<p>
-6 <em>Requires:</em> <code><del>0 <= </del>I < N</code>. The program is ill-formed if <code>I</code> is out of bounds.
+Since <tt>int</tt> promotes to <tt>double</tt>, and C99 doesn't have an <tt>int</tt>-based
+overload for <tt>pow</tt>, the C99 result is <tt>complex<double></tt>, see also C99
+7.22, see also library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>.
</p>
<p>
-7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
+Special note: ask P.J. Plauger.
</p>
+<blockquote>
+Looks fine.
+</blockquote>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-<ins><em>Throws:</em> Nothing.</ins>
+Strike this <tt>pow</tt> overload in 26.4.1 [complex.syn] and in 26.4.8 [complex.transcendentals]:
</p>
+<blockquote><pre><del>template<class T> complex<T> pow(const complex<T>& x, int y);</del>
+</pre></blockquote>
-<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="777"></a>777. Atomics Library Issue</h3>
-<p><b>Section:</b> 29.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-01-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
+<hr>
+<h3><a name="845"></a>845. atomics cannot support aggregate initialization</h3>
+<p><b>Section:</b> 29.5 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The atomic classes (and class templates) are required to support aggregate
+initialization (29.5.1 [atomics.types.integral]p2 / 29.5.2 [atomics.types.address]p1)
+yet also have user declared constructors, so cannot be aggregates.
+</p>
+<p>
+This problem might be solved with the introduction of the proposed
+initialization syntax at Antipolis, but the wording above should be altered.
+Either strike the sentence as redundant with new syntax, or refer to 'brace
+initialization'.
+</p>
+
+<p><i>[
+Jens adds:
+]</i></p>
+
+
+<blockquote>
<p>
-The load functions are defined as
+Note that
</p>
-
-<blockquote><pre>C atomic_load(volatile A* object);
-C atomic_load_explicit(volatile A* object, memory_order);
-C A::load(memory_order order = memory_order_seq_cst) volatile;
+<blockquote><pre>atomic_itype a1 = { 5 };
</pre></blockquote>
-
<p>
-which prevents their use in <tt>const</tt> contexts.
+would be aggregate-initialization syntax (now coming under the disguise
+of brace initialization), but would be ill-formed, because the corresponding
+constructor for atomic_itype is explicit. This works, though:
</p>
+<blockquote><pre>atomic_itype a2 { 6 };
+</pre></blockquote>
+
+</blockquote>
<p><i>[
-post Bellevue Peter adds:
+San Francisco:
]</i></p>
<blockquote>
<p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a
-subtle point here. Atomic loads do not generally write to the object, except
-potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the
-architecture, a dummy write with the same value may be required to be issued
-by the atomic load to maintain sequential consistency. This, in turn, may
-make the following code:
+The preferred approach to resolving this is to remove the explicit
+specifiers from the atomic integral type constructors.
+</p>
+<p>
+Lawrence will provide wording.
</p>
+<p>
+This issue is addressed in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>.
+</p>
+</blockquote>
-<blockquote><pre>const atomic_int x{};
-int main()
-{
- x.load();
-}
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-dump core under a straightforward implementation that puts const objects in
-a read-only section.
+within the synopsis in 29.5.1 [atomics.types.integral] edit as follows.
</p>
+
+<blockquote><pre><code>
+....
+typedef struct atomic_bool {
+....
+ constexpr <del>explicit</del> atomic_bool(bool);
+....
+typedef struct atomic_<var>itype</var> {
+....
+ constexpr <del>explicit</del> atomic_<var>itype</var>(<var>integral</var>);
+....
+</code></pre></blockquote>
+
<p>
-There are ways to sidestep the problem, but it needs to be considered.
+edit 29.5.1 [atomics.types.integral] paragraph 2 as follows.
</p>
+
+<blockquote>
+The atomic integral types shall have standard layout.
+They shall each have a trivial default constructor,
+a constexpr <del>explicit</del> value constructor,
+a deleted copy constructor,
+a deleted copy assignment operator,
+and a trivial destructor.
+They shall each support aggregate initialization syntax.
+</blockquote>
+
<p>
-The tradeoff is between making the data member of the atomic types
-mutable and requiring the user to explicitly mark atomic members as
-mutable, as is already the case with mutexes.
+within the synopsis of 29.5.2 [atomics.types.address] edit as follows.
+</p>
+
+<blockquote><pre><code>
+....
+typedef struct atomic_address {
+....
+ constexpr <del>explicit</del> atomic_address(void*);
+....
+</code></pre></blockquote>
+
+<p>
+edit 29.5.2 [atomics.types.address] paragraph 1 as follows.
</p>
+
+<blockquote>
+The type <code>atomic_address</code> shall have standard layout.
+It shall have a trivial default constructor,
+a constexpr <del>explicit</del> value constructor,
+a deleted copy constructor,
+a deleted copy assignment operator,
+and a trivial destructor.
+It shall support aggregate initialization syntax.
</blockquote>
+<p>
+within the synopsis of 29.5.3 [atomics.types.generic] edit as follows.
+</p>
+<blockquote><pre><code>
+....
+template <class T> struct atomic {
+....
+ constexpr <del>explicit</del> atomic(T);
+....
+template <> struct atomic<<var>integral</var>> : atomic_<var>itype</var> {
+....
+ constexpr <del>explicit</del> atomic(<var>integral</var>);
+....
+template <> struct atomic<T*> : atomic_address {
+....
+ constexpr <del>explicit</del> atomic(T*);
+....
+</code></pre></blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
-Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>.
+edit 29.5.3 [atomics.types.generic] paragraph 2 as follows.
</p>
-<blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object);
-C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order);
-C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
-</pre></blockquote>
+<blockquote>
+Specializations of the <code>atomic</code> template
+shall have a deleted copy constructor,
+a deleted copy assignment operator,
+and a constexpr <del>explicit</del> value constructor.
+</blockquote>
<hr>
-<h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3>
-<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-01-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p>
+<h3><a name="846"></a>846. No definition for constructor</h3>
+<p><b>Section:</b> 29.5 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-A small issue with <tt>std::bitset</tt>: it does not have any constructor
-taking a string literal, which is clumsy and looks like an oversigt when
-we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library.
+The atomic classes and class templates (29.5.1 [atomics.types.integral] /
+29.5.2 [atomics.types.address]) have a constexpr
+constructor taking a value of the appropriate type for that atomic.
+However, neither clause provides semantics or a definition for this
+constructor. I'm not sure if the initialization is implied by use of
+constexpr keyword (which restricts the form of a constructor) but even if
+that is the case, I think it is worth spelling out explicitly as the
+inference would be far too subtle in that case.
</p>
+<p><i>[
+San Francisco:
+]</i></p>
+
+
+<blockquote>
<p>
-Suggestion: Add
+Lawrence will provide wording.
+</p>
+<p>
+This issue is addressed in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>.
</p>
+</blockquote>
-<blockquote><pre>explicit bitset( const char* str );
-</pre></blockquote>
+
+<p><b>Proposed resolution:</b></p>
<p>
-to std::bitset.
+before the description of ...<code>is_lock_free</code>,
+that is before 29.6 [atomics.types.operations] paragraph 4,
+add the following description.
</p>
+<blockquote>
+<pre><code>
+constexpr <var>A</var>::<var>A</var>(<var>C</var> desired);
+</code></pre>
+<dl>
+<dt><i>Effects:</i></dt>
+<dd>
+Initializes the object with the value <code>desired</code>.
+[<i>Note:</i>
+Construction is not atomic.
+—<i>end note</i>]
+</dd>
+</dl>
+</blockquote>
+
-<p><b>Proposed resolution:</b></p>
+
+
+
+<hr>
+<h3><a name="848"></a>848. missing <tt>std::hash</tt> specializations for <tt>std::bitset/std::vector<bool></tt></h3>
+<p><b>Section:</b> 20.7.17 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-Add to synopsis in 23.3.5 [template.bitset]
+In the current working draft, <tt>std::hash<T></tt> is specialized for builtin
+types and a few other types. Bitsets seems like one that is missing from
+the list, not because it cannot not be done by the user, but because it
+is hard or impossible to write an efficient implementation that works on
+32bit/64bit chunks at a time. For example, <tt>std::bitset</tt> is too much
+encapsulated in this respect.
</p>
-<blockquote><pre>explicit bitset( const char* str );
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-Add to synopsis in 23.3.5.1 [bitset.cons]
+Add the following to the synopsis in 20.7 [function.objects]/2:
</p>
-<blockquote><pre>explicit bitset( const char* str );
-</pre>
+<blockquote><pre>template<class Allocator> struct hash<std::vector<bool,Allocator>>;
+template<size_t N> struct hash<std::bitset<N>>;
+</pre></blockquote>
+
<p>
-<i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>.
+Modify the last sentence of 20.7.17 [unord.hash]/1 to end with:
</p>
+
+<blockquote>
+... and <tt>std::string</tt>, <tt>std::u16string</tt>, <tt>std::u32string</tt>, <tt>std::wstring</tt>,
+<tt>std::error_code</tt>, <tt>std::thread::id</tt>, <tt>std::bitset</tt>, <tt>and std::vector<bool></tt>.
</blockquote>
<hr>
-<h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3>
-<p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<h3><a name="850"></a>850. Should <tt>shrink_to_fit</tt> apply to <tt>std::deque</tt>?</h3>
+<p><b>Section:</b> 23.3.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-A comparision of the N2461 header <tt><complex></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:
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a> added a <tt>shrink_to_fit</tt> function to <tt>std::vector</tt> and <tt>std::string</tt>.
+It did not yet deal with <tt>std::deque</tt>, because of the fundamental
+difference between <tt>std::deque</tt> and the other two container types. The
+need for <tt>std::deque</tt> may seem less evident, because one might think that
+for this container, the overhead is a small map, and some number of
+blocks that's bounded by a small constant.
</p>
-
-<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>
-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).
+The container overhead can in fact be arbitrarily large (i.e. is not
+necessarily O(N) where N is the number of elements currently held by the
+<tt>deque</tt>). As Bill Plauger noted in a reflector message, unless the map of
+block pointers is shrunk, it must hold at least maxN/B pointers where
+maxN is the maximum of N over the lifetime of the <tt>deque</tt> since its
+creation. This is independent of how the map is implemented
+(<tt>vector</tt>-like circular buffer and all), and maxN bears no relation to N,
+the number of elements it currently holds.
</p>
-
<p>
-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<T></tt> arguments, which are not accepted by
-this function.
+Hervé Brönnimann reports a situation where a <tt>deque</tt> of requests grew very
+large due to some temporary backup (the front request hanging), and the
+map of the <tt>deque</tt> grew quite large before getting back to normal. Just
+to put some color on it, assuming a <tt>deque</tt> with 1K pointer elements in
+steady regime, that held, at some point in its lifetime, maxN=10M
+pointers, with one block holding 128 elements, the spine must be at
+least (maxN / 128), in that case 100K. In that case, shrink-to-fit
+would allow to reuse about 100K which would otherwise never be reclaimed
+in the lifetime of the <tt>deque</tt>.
+</p>
+<p>
+An added bonus would be that it *allows* implementations to hang on to
+empty blocks at the end (but does not care if they do or not). A
+<tt>shrink_to_fit</tt> would take care of both shrinks, and guarantee that at
+most O(B) space is used in addition to the storage to hold the N
+elements and the N/B block pointers.
</p>
<p><b>Proposed resolution:</b></p>
<p>
-In 26.3.1 [complex.synopsis] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>:
+To Class template deque 23.3.2 [deque] synopsis, add:
</p>
-
-<blockquote><pre>template<class T> complex<T> conj(const complex<T>&);
-<ins>template<class T> complex<T> proj(const complex<T>&);</ins>
-template<class T> complex<T> fabs(const complex<T>&);
+<blockquote><pre>void shrink_to_fit();
</pre></blockquote>
<p>
-In 26.3.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add:
+To deque capacity 23.3.2.2 [deque.capacity], add:
</p>
-
-<blockquote>
-<pre>template<class T> complex<T> proj(const complex<T>& x);
+<blockquote><pre>void shrink_to_fit();
</pre>
-<blockquote>
-<i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in
-subclause 7.3.9.4."
+<blockquote>
+<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce memory
+use. [<i>Note:</i> The request is non-binding to allow latitude for
+implementation-specific optimizations. -- <i>end note</i>]
</blockquote>
</blockquote>
+
+
+
+
+<hr>
+<h3><a name="852"></a>852. unordered containers <tt>begin(n)</tt> mistakenly <tt>const</tt></h3>
+<p><b>Section:</b> 23.5 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2008-06-12 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-In 26.3.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to
-the overload list.
+In 3 of the four unordered containers the local <tt>begin</tt> member is mistakenly declared <tt>const</tt>:
</p>
-<blockquote>
+<blockquote><pre>local_iterator begin(size_type n) const;
+</pre></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-The following function templates shall have additional overloads:
+Change the synopsis in 23.5.1 [unord.map], 23.5.2 [unord.multimap], and 23.5.4 [unord.multiset]:
</p>
-<blockquote><pre>arg norm
-conj <del>polar</del> <ins>proj</ins>
-imag real
-</pre></blockquote>
-</blockquote>
+<blockquote><pre>local_iterator begin(size_type n)<del> const</del>;
+</pre></blockquote>
<hr>
-<h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<h3><a name="856"></a>856. Removal of <tt>aligned_union</tt></h3>
+<p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-06-12 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Part of the resolution of n2423, issue 8 was the proposal to
-extend the <tt>seed_seq</tt> constructor accepting an input range
-as follows (which is now part of N2461):
+With the arrival of extended unions
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf">N2544</a>),
+there is no
+known use of <tt>aligned_union</tt> that couldn't be handled by
+the "extended unions" core-language facility.
</p>
-<blockquote><pre>template<class InputIterator,
-size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
-seed_seq(InputIterator begin, InputIterator end);
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-First, the expression <tt>iterator_traits<InputIterator>::value_type</tt>
-is invalid due to missing <tt>typename</tt> keyword, which is easy to
-fix.
+Remove the following signature from 20.6.2 [meta.type.synop]:
</p>
+<blockquote><pre>template <std::size_t Len, class... Types> struct aligned_union;
+</pre></blockquote>
<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).
+Remove the second row from table 51 in 20.6.7 [meta.trans.other],
+starting with:
</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>
+<blockquote><pre>template <std::size_t Len,
+class... Types>
+struct aligned_union;
+</pre></blockquote>
+
-<p><i>[
-Bellevue:
-]</i></p>
+
+<hr>
+<h3><a name="858"></a>858. Wording for Minimal Support for Garbage Collection</h3>
+<p><b>Section:</b> 20.8.13.7 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-06-21 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The first sentence of the Effects clause for <tt>undeclare_reachable</tt> seems
+to be missing some words. I can't parse
+</p>
<blockquote>
+... for all non-null <tt>p</tt> referencing the argument is no longer declared reachable...
+</blockquote>
<p>
-Fermilab does not have a strong opinion. Would prefer to go with
-solution A. Bill agrees that solution A is a lot simpler and does the
-job.
+I take it the intent is that <tt>undeclare_reachable</tt> should be called only
+when there has been a corresponding call to <tt>declare_reachable</tt>. In
+particular, although the wording seems to allow it, I assume that code
+shouldn't call <tt>declare_reachable</tt> once then call <tt>undeclare_reachable</tt>
+twice.
</p>
<p>
-Proposed Resolution: Accept Solution A.
+I don't know what "shall be live" in the Requires clause means.
</p>
-</blockquote>
-
<p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> claims to make this issue moot.
+In the final Note for <tt>undeclare_reachable</tt>, what does "cannot be
+deallocated" mean? Is this different from "will not be able to collect"?
</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<ol type="A">
-<li>
<p>
-In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace:
+For the wording on nesting of <tt>declare_reachable</tt> and
+<tt>undeclare_reachable</tt>, the words for locking and unlocking recursive
+mutexes probably are a good model.
</p>
-<blockquote><pre>class seed_seq
-{
-public:
- ...
- template<class InputIterator<del>,
- size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
- seed_seq(InputIterator begin, InputIterator end<ins>,
- size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</ins>);
- ...
-};
-</pre></blockquote>
+<p><i>[
+San Francisco:
+]</i></p>
+
+<blockquote>
<p>
-and do a similar replacement in the member description between
-p.3 and p.4.
+Nick: what does "shall be live" mean?
</p>
-</li>
-
-<li>
<p>
-In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the
-member description between p.3 and p.4 replace:
+Hans: I can provide an appropriate cross-reference to the Project Editor
+to clarify the intent.
</p>
+</blockquote>
-<blockquote><pre>template<class InputIterator<del>,
- size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
- seed_seq(InputIterator begin, InputIterator end);
-<ins>template<class InputIterator, size_t u>
-seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins>
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-In 26.4.2 [rand.synopsis], header <tt><random></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:
+In 20.8.13.7 [util.dynamic.safety]
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm">N2670</a>,
+Minimal Support for Garbage Collection)
+</p>
+<p>
+Add at the beginning, before paragraph 39
</p>
-<blockquote><pre>template<size_t u, class InputIterator>
- seed_seq make_seed_seq(InputIterator begin, InputIterator end);
-</pre></blockquote>
+<blockquote>
+A complete object is <i>declared reachable</i> while the number of calls
+to <tt>declare_reachable</tt> with an argument referencing the object exceeds the
+number of <tt>undeclare_reachable</tt> calls with pointers to the same complete
+object.
+</blockquote>
<p>
-In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
+Change paragraph 42 (Requires clause for <tt>undeclare_reachable</tt>)
</p>
<blockquote>
-<p>
-The first constructor behaves as if it would provide an
-integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value
-<tt>numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</tt>.
-</p>
-<p>
-The second constructor uses an implementation-defined mechanism
-to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and
-is called by the function <tt>make_seed_seq</tt>.
-</p>
+If <tt>p</tt> is not null, <del><tt>declare_reachable(p)</tt> was previously called</del>
+<ins>the complete object referenced by <tt>p</tt> shall have
+been previously declared reachable</ins>, and shall
+be live <ins>(3.8 [basic.life])</ins> from the time of the call until the last <tt>undeclare_reachable(p)</tt>
+call on the object.
</blockquote>
<p>
-In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
+Change the first sentence in paragraph 44 (Effects clause for
+<tt>undeclare_reachable</tt>):
</p>
<blockquote>
-<pre>template<size_t u, class InputIterator>
- seed_seq make_seed_seq(InputIterator begin, InputIterator end);
-</pre>
-<blockquote>
+<i>Effects:</i>
+<del>Once the number of calls to
+<tt>undeclare_reachable(p)</tt> equals the number of calls to
+<tt>declare_reachable(p)</tt>
+for all non-null <tt>p</tt> referencing
+the argument is no longer declared reachable. When this happens,
+pointers to the object referenced by p may not be subsequently
+dereferenced.</del>
+<ins>
+After a call to <tt>undeclare_reachable(p)</tt>, if <tt>p</tt> is not null and the object <tt>q</tt>
+referenced by <tt>p</tt> is no longer declared reachable, then
+dereferencing any pointer to <tt>q</tt> that is not safely derived
+results in undefined behavior.
+</ins> ...
+</blockquote>
+
<p>
-where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type.
+Change the final note:
</p>
<p>
-<i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>;
+[<i>Note:</i> It is expected that calls to <tt>declare_reachable(p)</tt>
+will consume a small amount of memory<ins>, in addition to that occupied
+by the referenced object, </ins> until the matching call to
+<tt>undeclare_reachable(p)</tt> is encountered. <del>In addition, the
+referenced object cannot be deallocated during this period, and garbage
+collecting implementations will not be able to collect the object while
+it is declared reachable.</del> Long running programs should arrange
+that calls <ins>for short-lived objects</ins> are matched. <i>--end
+note</i>]
</p>
-</blockquote>
-</blockquote>
-
-</li>
-</ol>
<hr>
-<h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3>
-<p><b>Section:</b> 30.2.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Hans Boehm <b>Date:</b> 2008-02-01</p>
+<h3><a name="866"></a>866. Qualification of placement new-expressions</h3>
+<p><b>Section:</b> 20.8.11 [specialized.algorithms], 20.8.13.2.6 [util.smartptr.shared.create] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-14 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#specialized.algorithms">issues</a> in [specialized.algorithms].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The current working paper
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>,
-integrated just before Bellevue) is
-not completely clear whether a given <tt>thread::id</tt> value may be reused once
-a thread has exited and has been joined or detached. Posix allows
-thread ids (<tt>pthread_t</tt> values) to be reused in this case. Although it is
-not completely clear whether this originally was the right decision, it
-is clearly the established practice, and we believe it was always the
-intent of the C++ threads API to follow Posix and allow this. Howard
-Hinnant's example implementation implicitly relies on allowing reuse
-of ids, since it uses Posix thread ids directly.
+LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> replaced "<tt>new</tt>" with "<tt>::new</tt>" in the placement
+new-expression in 20.8.6.1 [allocator.members]. I believe the rationale
+given in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> applies also to the following other contexts:
</p>
-
+<ul>
+<li>
<p>
-It is important to be clear on this point, since it the reuse of thread
-ids often requires extra care in client code, which would not be
-necessary if thread ids were unique across all time. For example, a
-hash table indexed by thread id may have to be careful not to associate
-data values from an old thread with a new one that happens to reuse the
-id. Simply removing the old entry after joining a thread may not be
-sufficient, if it creates a visible window between the join and removal
-during which a new thread with the same id could have been created and
-added to the table.
+in 20.8.11 [specialized.algorithms], all four algorithms <tt>unitialized_copy</tt>,
+<tt>unitialized_copy_n</tt>, <tt>unitialized_fill</tt> and <tt>unitialized_fill_n</tt> use
+the unqualified placement new-expression in some variation of the form:
+</p>
+<blockquote><pre>new (static_cast<void*>(&*result)) typename iterator_traits<ForwardIterator>::value_type(*first);
+</pre></blockquote>
+</li>
+<li>
+<p>
+in 20.8.13.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
+</p>
+<blockquote><pre>new (pv) T(std::forward<Args>(args)...),
+</pre></blockquote>
+</li>
+</ul>
+<p>
+I suggest to add qualification in all those places. As far as I know,
+these are all the remaining places in the whole library that explicitly
+use a placement new-expression. Should other uses come out, they should
+be qualified as well.
+</p>
+<p>
+As an aside, a qualified placement new-expression does not need
+additional requirements to be compiled in a constrained context. By
+adding qualification, the <tt>HasPlacementNew</tt> concept introduced recently in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2677.pdf">N2677 (Foundational Concepts)</a>
+would no longer be needed by library and
+should therefore be removed.
</p>
<p><i>[
-post Bellevue Peter adds:
+San Francisco:
]</i></p>
<blockquote>
-<p>
-There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to
-reconsider fixing this by disallowing reuse, rather than explicitly allowing
-it. Dealing with thread id reuse is an incredibly painful exercise that
-would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over
-and over.
-</p>
-<p>
-In addition, it would be nice if a <tt>thread::id</tt> could be manipulated
-atomically in a lock-free manner, as motivated by the recursive lock
-example:
-</p>
+Detlef: If we move this to Ready, it's likely that we'll forget about
+the side comment about the <tt>HasPlacementNew</tt> concept.
+</blockquote>
-<p>
-<a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a>
-</p>
+<p><i>[
+post San Francisco:
+]</i></p>
+
+
+<blockquote>
+Daniel: <tt>HasPlacementNew</tt> has been removed from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774 (Foundational Concepts)</a>.
</blockquote>
<p><b>Proposed resolution:</b></p>
<p>
-Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
+Replace "<tt>new</tt>" with "<tt>::new</tt>" in:
</p>
+<ul>
+<li>
+20.8.11.2 [uninitialized.copy], paragraphs 1 and 3
+</li>
+<li>
+20.8.11.3 [uninitialized.fill] paragraph 1
+</li>
+<li>
+20.8.11.4 [uninitialized.fill.n] paragraph 1
+</li>
+<li>
+20.8.13.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2.
+</li>
+</ul>
-<blockquote>
-<p>
-An object of type <code>thread::id</code> provides
-a unique identifier for each thread of execution
-and a single distinct value for all thread objects
-that do not represent a thread of execution ([thread.threads.class]).
-Each thread of execution has a <code>thread::id</code>
-that is not equal to the <code>thread::id</code>
-of other threads of execution
-and that is not equal to
-the <code>thread::id</code> of <code>std::thread</code> objects
-that do not represent threads of execution.
-<ins>The library may reuse the value of a <code>thread::id</code> of a
-terminated thread that can no longer be joined.</ins>
-</p>
-</blockquote>
<hr>
-<h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3>
-<p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<h3><a name="882"></a>882. <tt>duration</tt> non-member arithmetic requirements</h3>
+<p><b>Section:</b> 20.9.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
+ <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-09-08 <b>Last modified:</b> 2008-09-26</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-<tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.)
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
+specified the following requirements for the non-member <tt>duration</tt>
+arithmetic:
</p>
-<p><i>[
-Bellevue:
-]</i></p>
+<blockquote>
+
+<pre>template <class Rep1, class Period, class Rep2>
+ duration<typename common_type<Rep1, Rep2>::type, Period>
+ operator*(const duration<Rep1, Period>& d, const Rep2& s);
+</pre>
+<blockquote>
+<i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of <tt>Rep1</tt> and
+<tt>Rep2</tt>. Both <tt>Rep1</tt> and <tt>Rep2</tt> shall be implicitly convertible
+to CR, diagnostic required.
+</blockquote>
+<pre>template <class Rep1, class Period, class Rep2>
+ duration<typename common_type<Rep1, Rep2>::type, Period>
+ operator*(const Rep1& s, const duration<Rep2, Period>& d);
+</pre>
<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.
+<i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of
+<tt>Rep1</tt> and <tt>Rep2</tt>. Both <tt>Rep1</tt> and <tt>Rep2</tt>
+shall be implicitly convertible to <tt>CR</tt>, diagnostic required.
</blockquote>
+<pre>template <class Rep1, class Period, class Rep2>
+ duration<typename common_type<Rep1, Rep2>::type, Period>
+ operator/(const duration<Rep1, Period>& d, const Rep2& s);
+</pre>
+
+<blockquote>
+<i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of
+<tt>Rep1</tt> and <tt>Rep2</tt>. Both <tt>Rep1</tt> and <tt>Rep2</tt> shall be
+implicitly convertible to <tt>CR</tt>, and <tt>Rep2</tt> shall not be an
+instantiation of <tt>duration</tt>, diagnostic required.
+</blockquote>
+
+</blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
-Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
+During transcription into the working paper, the requirements clauses on these
+three functions was changed to:
</p>
+
+<blockquote>
+<i>Requires:</i> <tt>CR(Rep1, Rep2)</tt> shall exist. Diagnostic required.
+</blockquote>
+
<p>
-Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>.
+This is a non editorial change with respect to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
+as user written representations which are used in <tt>duration</tt> need not be
+implicitly convertible to or from arithmetic types in order to interoperate with
+<tt>duration</tt>s based on arithmetic types. An explicit conversion will do
+fine for most expressions as long as there exists a <tt>common_type</tt> specialization
+relating the user written representation and the arithmetic type. For example:
</p>
+<blockquote><pre>class saturate
+{
+public:
+ explicit saturate(long long i);
+ ...
+};
+
+namespace std {
+template <>
+struct common_type<saturate, long long>
+{
+ typedef saturate type;
+};
+template <>
+struct common_type<long long, saturate>
+{
+ typedef saturate type;
+};
+} // std
+
+millisecond ms(3); // integral-based duration
+duration<saturate, milli> my_ms = ms; // ok, even with explicit conversions
+my_ms = my_ms + ms; // ok, even with explicit conversions
+</pre></blockquote>
-<hr>
-<h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3>
-<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-<tt>piecewise_constant_distribution</tt> is undefined for a range with just one
-endpoint. (Probably should be the same as an empty range.)
+However, when dealing with multiplication of a duration and its representation,
+implicit convertibility is required between the rhs and the lhs's representation
+for the member <tt>*=</tt> operator:
</p>
+<blockquote><pre>template <class Rep, class Period = ratio<1>>
+class duration {
+public:
+ ...
+ duration& operator*=(const rep& rhs);
+ ...
+};
+...
+ms *= 2; // ok, 2 is implicitly convertible to long long
+my_ms *= saturate(2); // ok, rhs is lhs's representation
+my_ms *= 2; // error, 2 is not implicitly convertible to saturate
+</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
-Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
+The last line does not (and should not) compile. And we want non-member multiplication
+to have the same behavior as member arithmetic:
</p>
-<blockquote>
-b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>,
-</blockquote>
-
+<blockquote><pre>my_ms = my_ms * saturate(2); // ok, rhs is lhs's representation
+my_ms = my_ms * 2; // <em>should be</em> error, 2 is not implicitly convertible to saturate
+</pre></blockquote>
+<p>
+The requirements clauses of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
+make the last line an error as expected. However the latest working draft at
+this time
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
+allows the last line to compile.
+</p>
+<p>
+All that being said, there does appear to be an error in these requirements clauses
+as specified by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>.
+</p>
+<blockquote>
+<i>Requires:</i> ... <em>Both</em> <tt>Rep1</tt> and <tt>Rep2</tt> shall be implicitly convertible
+to CR, diagnostic required.
+</blockquote>
-<hr>
-<h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3>
-<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
<p>
-<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 -> 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.
+It is not necessary for both <tt>Rep</tt>s to be <i>implicitly</i> convertible to
+the <tt>CR</tt>. It is only necessary for the rhs <tt>Rep</tt> to be implicitly
+convertible to the <tt>CR</tt>. The <tt>Rep</tt> within the <tt>duration</tt>
+should be allowed to only be explicitly convertible to the <tt>CR</tt>. The
+explicit-conversion-requirement is covered under 20.9.3.7 [time.duration.cast].
</p>
+
<p><b>Proposed resolution:</b></p>
<p>
-Change D.8.1 [depr.lib.binder.1st]:
+Change the requirements clauses under 20.9.3.5 [time.duration.nonmember]:
</p>
<blockquote>
-<pre>template <class Fn>
-class binder1st
- : public unary_function<typename Fn::second_argument_type,
- typename Fn::result_type> {
-protected:
- Fn <del>fn</del> <ins>op</ins>;
- typename Fn::first_argument_type value;
-public:
- binder1st(const Fn& x,
- const typename Fn::first_argument_type& y);
- typename Fn::result_type
- operator()(const typename Fn::second_argument_type& x) const;
- typename Fn::result_type
- operator()(typename Fn::second_argument_type& x) const;
-};
+
+<pre>template <class Rep1, class Period, class Rep2>
+ duration<typename common_type<Rep1, Rep2>::type, Period>
+ operator*(const duration<Rep1, Period>& d, const Rep2& s);
</pre>
<blockquote>
-<p>
--1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
-</p>
-<p>
--2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
-</p>
-</blockquote>
+<i>Requires:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist.</del>
+<ins><tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.</ins>
+Diagnostic required.
</blockquote>
-<p>
-Change D.8.3 [depr.lib.binder.2nd]:
-</p>
+<pre>template <class Rep1, class Period, class Rep2>
+ duration<typename common_type<Rep1, Rep2>::type, Period>
+ operator*(const Rep1& s, const duration<Rep2, Period>& d);
+</pre>
<blockquote>
-<pre>template <class Fn>
-class binder2nd
- : public unary_function<typename Fn::first_argument_type,
- typename Fn::result_type> {
-protected:
- Fn <del>fn</del> <ins>op</ins>;
- typename Fn::second_argument_type value;
-public:
- binder2nd(const Fn& x,
- const typename Fn::second_argument_type& y);
- typename Fn::result_type
- operator()(const typename Fn::first_argument_type& x) const;
- typename Fn::result_type
- operator()(typename Fn::first_argument_type& x) const;
-};
+<i>Require<ins>s</ins><del>d behavior</del>:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist.</del>
+<ins><tt>Rep1</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.</ins>
+Diagnostic required.
+</blockquote>
+
+<pre>template <class Rep1, class Period, class Rep2>
+ duration<typename common_type<Rep1, Rep2>::type, Period>
+ operator/(const duration<Rep1, Period>& d, const Rep2& s);
</pre>
<blockquote>
+<i>Requires:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist</del>
+<ins><tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt></ins>
+and <tt>Rep2</tt> shall not
+be an instantiation of <tt>duration</tt>. Diagnostic required.
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="894"></a>894. longjmp and destructors</h3>
+<p><b>Section:</b> 18.10 [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, Alisdair Meredith <b>Opened:</b> 2008-09-17 <b>Last modified:</b> 2009-03-09</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.runtime">issues</a> in [support.runtime].</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>
--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>.
+The interaction between <tt>longjmp</tt> and exceptions seems unnecessarily
+restrictive and not in keeping with existing practice.
</p>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
--2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
+Edit paragraph 4 of 18.10 [support.runtime] as follows:
</p>
-</blockquote>
-</blockquote>
+<blockquote>
+The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
+restricted behavior in this International Standard. A
+<tt>setjmp/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 <del>destroy</del>
+<ins>invoke any non-trivial destructors for</ins>
+any automatic objects.
+</blockquote>
projects / platform / upstream / linaro-gcc.git / commitdiff