<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>C++ Standard Library Active Issues List</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
</style>
</head>
<body>
<table>
<tr>
  <td align="left">Doc. no.</td>
  <td align="left">N3438=12-0128</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2012-09-24</td>
</tr>
<tr>
  <td align="left">Project:</td>
  <td align="left">Programming Language C++</td>
</tr>
<tr>
  <td align="left">Reply to:</td>
  <td align="left">Alisdair Meredith &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<h1>C++ Standard Library Active Issues List (Revision R79)</h1>
<p>Revised 2012-09-24 at 14:09:21 UTC</p>

  <p>Reference ISO/IEC IS 14882:2011(E)</p>
  <p>Also see:</p>
  <ul>
      <li><a href="lwg-toc.html">Table of Contents</a> for all library issues.</li>
      <li><a href="lwg-index.html">Index by Section</a> for all library issues.</li>
      <li><a href="lwg-status.html">Index by Status</a> for all library issues.</li>
      <li><a href="lwg-defects.html">Library Defect Reports List</a></li>
      <li><a href="lwg-closed.html">Library Closed Issues List</a></li>
  </ul>
  <p>The purpose of this document is to record the status of issues
  which have come before the Library Working Group (LWG) of the INCITS PL22.16
  and ISO WG21 C++ Standards Committee. Issues represent
  potential defects in the ISO/IEC IS 14882:2011(E) document.  
  </p>

  <p>This document contains only library issues which are actively being
  considered by the Library Working Group, i.e., issues which have a
  status of <a href="lwg-active.html#New">New</a>, <a href="lwg-active.html#Open">Open</a>, 
  <a href="lwg-active.html#Ready">Ready</a>, or <a href="lwg-active.html#Review">Review</a>. See
  <a href="lwg-defects.html">Library Defect Reports List</a> for issues considered defects and 
  <a href="lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>

  <p>The issues in these lists are not necessarily formal ISO Defect
  Reports (DR's). While some issues will eventually be elevated to
  official Defect Report status, other issues will be disposed of in
  other ways. See <a href="#Status">Issue Status</a>.</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
  into a single version.</p>

  <p>This document includes <i>[bracketed italicized notes]</i> as a
  reminder to the LWG of current progress on issues. Such notes are
  strictly unofficial and should be read with caution as they may be
  incomplete or incorrect. Be aware that LWG support for a particular
  resolution can quickly change if new viewpoints or killer examples are
  presented in subsequent discussions.</p>

  <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:2011(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.
  </p>

<p><a name="submit_issue"></a><b>How to submit an issue</b></p>

<ol style="list-style-type:upper-alpha">
<li><a name="submit_issue_A"></a>
Mail your issue to the author of this list.
</li>
<li><a name="submit_issue_B"></a>
Specify a short descriptive title.  If you fail to do so, the subject line of your
mail will be used as the issue title.
</li>
<li><a name="submit_issue_C"></a>
If the "From" on your email is not the name you wish to appear as issue submitter,
then specify issue submitter.
</li>
<li><a name="submit_issue_D"></a>
Provide a brief discussion of the problem you wish to correct.  Refer to the latest
working draft or standard using [section.tag] and paragraph numbers where appropriate.
</li>
<li><a name="submit_issue_E"></a>
Provide proposed wording.  This should indicate exactly how you want the standard
to be changed.  General solution statements belong in the discussion area.  This
area contains very clear and specific directions on how to modify the current
draft.  If you are not sure how to word a solution, you may omit this part.
But your chances of a successful issue greatly increase if you attempt wording.
</li>
<li><a name="submit_issue_F"></a>
It is not necessary for you to use html markup.  However, if you want to, you can
&lt;ins&gt;<ins>insert text like this</ins>&lt;/ins&gt; and &lt;del&gt;<del>delete text like
this</del>&lt;/del&gt;.  The only strict requirement is to communicate clearly to
the list maintainer exactly how you want your issue to look.
</li>
<li><a name="submit_issue_G"></a>
It is not necessary for you to specify other html font/formatting
mark-up, but if you do the list maintainer will attempt to respect your
formatting wishes (as described by html markup, or other common idioms).
</li>
<li><a name="submit_issue_H"></a>
It is not necessary for you to specify open date or last modified date (the date
of your mail will be used).
</li>
<li><a name="submit_issue_I"></a>
It is not necessary for you to cross reference other issues, but you can if you
like.  You do not need to form the hyperlinks when you do, the list maintainer will
take care of that.
</li>
<li><a name="submit_issue_J"></a>
One issue per email is best.
</li>
<li><a name="submit_issue_K"></a>
Between the time you submit the issue, and the next mailing deadline
(date at the top of the Revision History), you <em>own</em> this issue. 
You control the content, the stuff that is right, the stuff that is
wrong, the format, the misspellings, etc.  You can even make the issue
disappear if you want.  Just let the list maintainer know how you want
it to look, and he will try his best to accommodate you.  After the
issue appears in an official mailing, you no longer enjoy exclusive
ownership of it.
</li>
</ol>


<h2>Revision History</h2>
<ul>
<li>R79: 2012-09-24 pre-Portland mailing<ul>
<li><b>Summary:</b><ul>
<li>136 open issues, up by 60.</li>
<li>1576 closed issues, up by 0.</li>
<li>1712 issues total, up by 60.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 60 New issues: <a href="lwg-active.html#2130">2130</a>, <a href="lwg-active.html#2131">2131</a>, <a href="lwg-active.html#2132">2132</a>, <a href="lwg-active.html#2133">2133</a>, <a href="lwg-active.html#2134">2134</a>, <a href="lwg-active.html#2135">2135</a>, <a href="lwg-active.html#2136">2136</a>, <a href="lwg-active.html#2137">2137</a>, <a href="lwg-active.html#2138">2138</a>, <a href="lwg-active.html#2139">2139</a>, <a href="lwg-active.html#2140">2140</a>, <a href="lwg-active.html#2141">2141</a>, <a href="lwg-active.html#2142">2142</a>, <a href="lwg-active.html#2143">2143</a>, <a href="lwg-active.html#2144">2144</a>, <a href="lwg-active.html#2145">2145</a>, <a href="lwg-active.html#2146">2146</a>, <a href="lwg-active.html#2147">2147</a>, <a href="lwg-active.html#2148">2148</a>, <a href="lwg-active.html#2149">2149</a>, <a href="lwg-active.html#2150">2150</a>, <a href="lwg-active.html#2151">2151</a>, <a href="lwg-active.html#2152">2152</a>, <a href="lwg-active.html#2153">2153</a>, <a href="lwg-active.html#2154">2154</a>, <a href="lwg-active.html#2155">2155</a>, <a href="lwg-active.html#2156">2156</a>, <a href="lwg-active.html#2157">2157</a>, <a href="lwg-active.html#2158">2158</a>, <a href="lwg-active.html#2159">2159</a>, <a href="lwg-active.html#2160">2160</a>, <a href="lwg-active.html#2161">2161</a>, <a href="lwg-active.html#2162">2162</a>, <a href="lwg-active.html#2163">2163</a>, <a href="lwg-active.html#2164">2164</a>, <a href="lwg-active.html#2165">2165</a>, <a href="lwg-active.html#2166">2166</a>, <a href="lwg-active.html#2167">2167</a>, <a href="lwg-active.html#2168">2168</a>, <a href="lwg-active.html#2169">2169</a>, <a href="lwg-active.html#2170">2170</a>, <a href="lwg-active.html#2171">2171</a>, <a href="lwg-active.html#2172">2172</a>, <a href="lwg-active.html#2173">2173</a>, <a href="lwg-active.html#2174">2174</a>, <a href="lwg-active.html#2175">2175</a>, <a href="lwg-active.html#2176">2176</a>, <a href="lwg-active.html#2177">2177</a>, <a href="lwg-active.html#2178">2178</a>, <a href="lwg-active.html#2179">2179</a>, <a href="lwg-active.html#2180">2180</a>, <a href="lwg-active.html#2181">2181</a>, <a href="lwg-active.html#2182">2182</a>, <a href="lwg-active.html#2183">2183</a>, <a href="lwg-active.html#2184">2184</a>, <a href="lwg-active.html#2185">2185</a>, <a href="lwg-active.html#2186">2186</a>, <a href="lwg-active.html#2187">2187</a>, <a href="lwg-active.html#2188">2188</a>, <a href="lwg-active.html#2189">2189</a>.</li>
<li>No issues changed.</li>
</ul></li>
</ul>
</li>
<li>R78: 
2012-02-27 post-Kona mailing
<ul>
<li><b>Summary:</b><ul>
<li>76 open issues, down by 20.</li>
<li>1576 closed issues, up by 26.</li>
<li>1652 issues total, up by 6.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 2 New issues: <a href="lwg-active.html#2125">2125</a>, <a href="lwg-active.html#2126">2126</a>.</li>
<li>Added the following 3 Open issues: <a href="lwg-active.html#2127">2127</a>, <a href="lwg-active.html#2128">2128</a>, <a href="lwg-active.html#2129">2129</a>.</li>
<li>Added the following Tentatively NAD issue: <a href="lwg-active.html#2124">2124</a>.</li>
<li>Changed the following 5 issues from New to NAD: <a href="lwg-closed.html#2073">2073</a>, <a href="lwg-closed.html#2082">2082</a>, <a href="lwg-closed.html#2090">2090</a>, <a href="lwg-closed.html#2107">2107</a>, <a href="lwg-closed.html#2113">2113</a>.</li>
<li>Changed the following issue from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#2060">2060</a>.</li>
<li>Changed the following issue from Deferred to Open: <a href="lwg-active.html#1526">1526</a>.</li>
<li>Changed the following 15 issues from New to Open: <a href="lwg-active.html#2072">2072</a>, <a href="lwg-active.html#2077">2077</a>, <a href="lwg-active.html#2088">2088</a>, <a href="lwg-active.html#2089">2089</a>, <a href="lwg-active.html#2101">2101</a>, <a href="lwg-active.html#2108">2108</a>, <a href="lwg-active.html#2111">2111</a>, <a href="lwg-active.html#2112">2112</a>, <a href="lwg-active.html#2114">2114</a>, <a href="lwg-active.html#2115">2115</a>, <a href="lwg-active.html#2116">2116</a>, <a href="lwg-active.html#2117">2117</a>, <a href="lwg-active.html#2118">2118</a>, <a href="lwg-active.html#2119">2119</a>, <a href="lwg-active.html#2122">2122</a>.</li>
<li>Changed the following 2 issues from Review to Open: <a href="lwg-active.html#1169">1169</a>, <a href="lwg-active.html#2059">2059</a>.</li>
<li>Changed the following 10 issues from New to Ready: <a href="lwg-active.html#2071">2071</a>, <a href="lwg-active.html#2074">2074</a>, <a href="lwg-active.html#2081">2081</a>, <a href="lwg-active.html#2083">2083</a>, <a href="lwg-active.html#2086">2086</a>, <a href="lwg-active.html#2099">2099</a>, <a href="lwg-active.html#2103">2103</a>, <a href="lwg-active.html#2105">2105</a>, <a href="lwg-active.html#2110">2110</a>, <a href="lwg-active.html#2123">2123</a>.</li>
<li>Changed the following issue from Tentatively Resolved to Resolved: <a href="lwg-defects.html#2066">2066</a>.</li>
<li>Changed the following 7 issues from New to Review: <a href="lwg-active.html#2080">2080</a>, <a href="lwg-active.html#2091">2091</a>, <a href="lwg-active.html#2092">2092</a>, <a href="lwg-active.html#2093">2093</a>, <a href="lwg-active.html#2094">2094</a>, <a href="lwg-active.html#2106">2106</a>, <a href="lwg-active.html#2109">2109</a>.</li>
<li>Changed the following issue from Ready to Review: <a href="lwg-active.html#2013">2013</a>.</li>
<li>Changed the following 6 issues from Review to Tentatively Ready: <a href="lwg-active.html#2005">2005</a>, <a href="lwg-active.html#2011">2011</a>, <a href="lwg-active.html#2048">2048</a>, <a href="lwg-active.html#2049">2049</a>, <a href="lwg-active.html#2056">2056</a>, <a href="lwg-active.html#2058">2058</a>.</li>
<li>Changed the following 18 issues from Ready to WP: <a href="lwg-defects.html#1214">1214</a>, <a href="lwg-defects.html#2009">2009</a>, <a href="lwg-defects.html#2010">2010</a>, <a href="lwg-defects.html#2015">2015</a>, <a href="lwg-defects.html#2021">2021</a>, <a href="lwg-defects.html#2028">2028</a>, <a href="lwg-defects.html#2033">2033</a>, <a href="lwg-defects.html#2039">2039</a>, <a href="lwg-defects.html#2044">2044</a>, <a href="lwg-defects.html#2045">2045</a>, <a href="lwg-defects.html#2047">2047</a>, <a href="lwg-defects.html#2050">2050</a>, <a href="lwg-defects.html#2053">2053</a>, <a href="lwg-defects.html#2061">2061</a>, <a href="lwg-defects.html#2064">2064</a>, <a href="lwg-defects.html#2065">2065</a>, <a href="lwg-defects.html#2067">2067</a>, <a href="lwg-defects.html#2069">2069</a>.</li>
<li>Changed the following 2 issues from Tentatively Ready to WP: <a href="lwg-defects.html#2096">2096</a>, <a href="lwg-defects.html#2102">2102</a>.</li>
</ul></li>
</ul>
</li>
<li>R77: 
2012-01-16 pre-Kona mailing
<ul>
<li><b>Summary:</b><ul>
<li>96 open issues, up by 52.</li>
<li>1550 closed issues, up by 1.</li>
<li>1646 issues total, up by 53.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issue: <a href="lwg-closed.html#2084">2084</a>.</li>
<li>Added the following 50 New issues: <a href="lwg-active.html#2071">2071</a>, <a href="lwg-active.html#2072">2072</a>, <a href="lwg-active.html#2073">2073</a>, <a href="lwg-active.html#2074">2074</a>, <a href="lwg-active.html#2075">2075</a>, <a href="lwg-active.html#2076">2076</a>, <a href="lwg-active.html#2077">2077</a>, <a href="lwg-active.html#2078">2078</a>, <a href="lwg-active.html#2079">2079</a>, <a href="lwg-active.html#2080">2080</a>, <a href="lwg-active.html#2081">2081</a>, <a href="lwg-active.html#2082">2082</a>, <a href="lwg-active.html#2083">2083</a>, <a href="lwg-active.html#2085">2085</a>, <a href="lwg-active.html#2086">2086</a>, <a href="lwg-active.html#2087">2087</a>, <a href="lwg-active.html#2088">2088</a>, <a href="lwg-active.html#2089">2089</a>, <a href="lwg-active.html#2090">2090</a>, <a href="lwg-active.html#2091">2091</a>, <a href="lwg-active.html#2092">2092</a>, <a href="lwg-active.html#2093">2093</a>, <a href="lwg-active.html#2094">2094</a>, <a href="lwg-active.html#2095">2095</a>, <a href="lwg-active.html#2097">2097</a>, <a href="lwg-active.html#2098">2098</a>, <a href="lwg-active.html#2099">2099</a>, <a href="lwg-active.html#2100">2100</a>, <a href="lwg-active.html#2101">2101</a>, <a href="lwg-active.html#2103">2103</a>, <a href="lwg-active.html#2104">2104</a>, <a href="lwg-active.html#2105">2105</a>, <a href="lwg-active.html#2106">2106</a>, <a href="lwg-active.html#2107">2107</a>, <a href="lwg-active.html#2108">2108</a>, <a href="lwg-active.html#2109">2109</a>, <a href="lwg-active.html#2110">2110</a>, <a href="lwg-active.html#2111">2111</a>, <a href="lwg-active.html#2112">2112</a>, <a href="lwg-active.html#2113">2113</a>, <a href="lwg-active.html#2114">2114</a>, <a href="lwg-active.html#2115">2115</a>, <a href="lwg-active.html#2116">2116</a>, <a href="lwg-active.html#2117">2117</a>, <a href="lwg-active.html#2118">2118</a>, <a href="lwg-active.html#2119">2119</a>, <a href="lwg-active.html#2120">2120</a>, <a href="lwg-active.html#2121">2121</a>, <a href="lwg-active.html#2122">2122</a>, <a href="lwg-active.html#2123">2123</a>.</li>
<li>Added the following 2 Tentatively Ready issues: <a href="lwg-active.html#2096">2096</a>, <a href="lwg-active.html#2102">2102</a>.</li>
<li>No issues changed.</li>
</ul></li>
</ul>
</li>
<li>R76: 
2011-09-06 post-Bloomington mailing
<ul>
<li><b>Summary:</b><ul>
<li>44 open issues, up by 19.</li>
<li>1549 closed issues, up by 9.</li>
<li>1593 issues total, up by 28.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 2 NAD issues: <a href="lwg-closed.html#2043">2043</a>, <a href="lwg-closed.html#2068">2068</a>.</li>
<li>Added the following 2 NAD Future issues: <a href="lwg-closed.html#2051">2051</a>, <a href="lwg-closed.html#2055">2055</a>.</li>
<li>Added the following 6 Open issues: <a href="lwg-active.html#2052">2052</a>, <a href="lwg-active.html#2054">2054</a>, <a href="lwg-active.html#2057">2057</a>, <a href="lwg-active.html#2062">2062</a>, <a href="lwg-active.html#2063">2063</a>, <a href="lwg-active.html#2070">2070</a>.</li>
<li>Added the following Pending NAD issue: <a href="lwg-closed.html#2046">2046</a>.</li>
<li>Added the following Pending NAD Editorial issue: <a href="lwg-closed.html#2060">2060</a>.</li>
<li>Added the following 10 Ready issues: <a href="lwg-active.html#2044">2044</a>, <a href="lwg-active.html#2045">2045</a>, <a href="lwg-active.html#2047">2047</a>, <a href="lwg-active.html#2050">2050</a>, <a href="lwg-active.html#2053">2053</a>, <a href="lwg-active.html#2061">2061</a>, <a href="lwg-active.html#2064">2064</a>, <a href="lwg-active.html#2065">2065</a>, <a href="lwg-active.html#2067">2067</a>, <a href="lwg-active.html#2069">2069</a>.</li>
<li>Added the following 5 Review issues: <a href="lwg-active.html#2048">2048</a>, <a href="lwg-active.html#2049">2049</a>, <a href="lwg-active.html#2056">2056</a>, <a href="lwg-active.html#2058">2058</a>, <a href="lwg-active.html#2059">2059</a>.</li>
<li>Added the following Tentatively Resolved issue: <a href="lwg-active.html#2066">2066</a>.</li>
<li>Changed the following 322 issues from WP to C++11: <a href="lwg-defects.html#149">149</a>, <a href="lwg-defects.html#296">296</a>, <a href="lwg-defects.html#419">419</a>, <a href="lwg-defects.html#427">427</a>, <a href="lwg-defects.html#430">430</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-defects.html#473">473</a>, <a href="lwg-defects.html#498">498</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#696">696</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-defects.html#723">723</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#753">753</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#765">765</a>, <a href="lwg-defects.html#774">774</a>, <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#788">788</a>, <a href="lwg-defects.html#810">810</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-defects.html#814">814</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-defects.html#821">821</a>, <a href="lwg-defects.html#835">835</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#838">838</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#861">861</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#866">866</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#869">869</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-defects.html#872">872</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-defects.html#878">878</a>, <a href="lwg-defects.html#881">881</a>, <a href="lwg-defects.html#883">883</a>, <a href="lwg-defects.html#885">885</a>, <a href="lwg-defects.html#886">886</a>, <a href="lwg-defects.html#888">888</a>, <a href="lwg-defects.html#890">890</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#894">894</a>, <a href="lwg-defects.html#896">896</a>, <a href="lwg-defects.html#898">898</a>, <a href="lwg-defects.html#899">899</a>, <a href="lwg-defects.html#900">900</a>, <a href="lwg-defects.html#904">904</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-defects.html#911">911</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#922">922</a>, <a href="lwg-defects.html#925">925</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#931">931</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-defects.html#938">938</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>, <a href="lwg-defects.html#951">951</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-defects.html#956">956</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#975">975</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#981">981</a>, <a href="lwg-defects.html#982">982</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-defects.html#986">986</a>, <a href="lwg-defects.html#987">987</a>, <a href="lwg-defects.html#990">990</a>, <a href="lwg-defects.html#991">991</a>, <a href="lwg-defects.html#993">993</a>, <a href="lwg-defects.html#994">994</a>, <a href="lwg-defects.html#997">997</a>, <a href="lwg-defects.html#998">998</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-defects.html#1004">1004</a>, <a href="lwg-defects.html#1006">1006</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-defects.html#1014">1014</a>, <a href="lwg-defects.html#1019">1019</a>, <a href="lwg-defects.html#1021">1021</a>, <a href="lwg-defects.html#1030">1030</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1034">1034</a>, <a href="lwg-defects.html#1037">1037</a>, <a href="lwg-defects.html#1038">1038</a>, <a href="lwg-defects.html#1039">1039</a>, <a href="lwg-defects.html#1040">1040</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-defects.html#1065">1065</a>, <a href="lwg-defects.html#1066">1066</a>, <a href="lwg-defects.html#1070">1070</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-defects.html#1073">1073</a>, <a href="lwg-defects.html#1079">1079</a>, <a href="lwg-defects.html#1089">1089</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-defects.html#1098">1098</a>, <a href="lwg-defects.html#1103">1103</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-defects.html#1110">1110</a>, <a href="lwg-defects.html#1113">1113</a>, <a href="lwg-defects.html#1114">1114</a>, <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-defects.html#1123">1123</a>, <a href="lwg-defects.html#1126">1126</a>, <a href="lwg-defects.html#1130">1130</a>, <a href="lwg-defects.html#1131">1131</a>, <a href="lwg-defects.html#1133">1133</a>, <a href="lwg-defects.html#1134">1134</a>, <a href="lwg-defects.html#1136">1136</a>, <a href="lwg-defects.html#1137">1137</a>, <a href="lwg-defects.html#1138">1138</a>, <a href="lwg-defects.html#1144">1144</a>, <a href="lwg-defects.html#1152">1152</a>, <a href="lwg-defects.html#1157">1157</a>, <a href="lwg-defects.html#1158">1158</a>, <a href="lwg-defects.html#1159">1159</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-defects.html#1177">1177</a>, <a href="lwg-defects.html#1178">1178</a>, <a href="lwg-defects.html#1180">1180</a>, <a href="lwg-defects.html#1181">1181</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-defects.html#1187">1187</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1192">1192</a>, <a href="lwg-defects.html#1193">1193</a>, <a href="lwg-defects.html#1194">1194</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-defects.html#1198">1198</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-defects.html#1204">1204</a>, <a href="lwg-defects.html#1205">1205</a>, <a href="lwg-defects.html#1206">1206</a>, <a href="lwg-defects.html#1207">1207</a>, <a href="lwg-defects.html#1208">1208</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-defects.html#1215">1215</a>, <a href="lwg-defects.html#1216">1216</a>, <a href="lwg-defects.html#1218">1218</a>, <a href="lwg-defects.html#1220">1220</a>, <a href="lwg-defects.html#1221">1221</a>, <a href="lwg-defects.html#1222">1222</a>, <a href="lwg-defects.html#1227">1227</a>, <a href="lwg-defects.html#1231">1231</a>, <a href="lwg-defects.html#1234">1234</a>, <a href="lwg-defects.html#1237">1237</a>, <a href="lwg-defects.html#1240">1240</a>, <a href="lwg-defects.html#1241">1241</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-defects.html#1247">1247</a>, <a href="lwg-defects.html#1249">1249</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-defects.html#1252">1252</a>, <a href="lwg-defects.html#1253">1253</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>, <a href="lwg-defects.html#1261">1261</a>, <a href="lwg-defects.html#1262">1262</a>, <a href="lwg-defects.html#1264">1264</a>, <a href="lwg-defects.html#1267">1267</a>, <a href="lwg-defects.html#1270">1270</a>, <a href="lwg-defects.html#1271">1271</a>, <a href="lwg-defects.html#1276">1276</a>, <a href="lwg-defects.html#1277">1277</a>, <a href="lwg-defects.html#1278">1278</a>, <a href="lwg-defects.html#1279">1279</a>, <a href="lwg-defects.html#1280">1280</a>, <a href="lwg-defects.html#1284">1284</a>, <a href="lwg-defects.html#1285">1285</a>, <a href="lwg-defects.html#1286">1286</a>, <a href="lwg-defects.html#1287">1287</a>, <a href="lwg-defects.html#1288">1288</a>, <a href="lwg-defects.html#1292">1292</a>, <a href="lwg-defects.html#1294">1294</a>, <a href="lwg-defects.html#1295">1295</a>, <a href="lwg-defects.html#1298">1298</a>, <a href="lwg-defects.html#1299">1299</a>, <a href="lwg-defects.html#1303">1303</a>, <a href="lwg-defects.html#1306">1306</a>, <a href="lwg-defects.html#1309">1309</a>, <a href="lwg-defects.html#1310">1310</a>, <a href="lwg-defects.html#1312">1312</a>, <a href="lwg-defects.html#1316">1316</a>, <a href="lwg-defects.html#1319">1319</a>, <a href="lwg-defects.html#1323">1323</a>, <a href="lwg-defects.html#1325">1325</a>, <a href="lwg-defects.html#1332">1332</a>, <a href="lwg-defects.html#1333">1333</a>, <a href="lwg-defects.html#1334">1334</a>, <a href="lwg-defects.html#1335">1335</a>, <a href="lwg-defects.html#1337">1337</a>, <a href="lwg-defects.html#1338">1338</a>, <a href="lwg-defects.html#1339">1339</a>, <a href="lwg-defects.html#1340">1340</a>, <a href="lwg-defects.html#1349">1349</a>, <a href="lwg-defects.html#1354">1354</a>, <a href="lwg-defects.html#1360">1360</a>, <a href="lwg-defects.html#1362">1362</a>, <a href="lwg-defects.html#1363">1363</a>, <a href="lwg-defects.html#1367">1367</a>, <a href="lwg-defects.html#1368">1368</a>, <a href="lwg-defects.html#1370">1370</a>, <a href="lwg-defects.html#1372">1372</a>, <a href="lwg-defects.html#1381">1381</a>, <a href="lwg-defects.html#1384">1384</a>, <a href="lwg-defects.html#1385">1385</a>, <a href="lwg-defects.html#1386">1386</a>, <a href="lwg-defects.html#1387">1387</a>, <a href="lwg-defects.html#1388">1388</a>, <a href="lwg-defects.html#1399">1399</a>, <a href="lwg-defects.html#1400">1400</a>, <a href="lwg-defects.html#1401">1401</a>, <a href="lwg-defects.html#1402">1402</a>, <a href="lwg-defects.html#1403">1403</a>, <a href="lwg-defects.html#1404">1404</a>, <a href="lwg-defects.html#1408">1408</a>, <a href="lwg-defects.html#1414">1414</a>, <a href="lwg-defects.html#1416">1416</a>, <a href="lwg-defects.html#1417">1417</a>, <a href="lwg-defects.html#1418">1418</a>, <a href="lwg-defects.html#1420">1420</a>, <a href="lwg-defects.html#1423">1423</a>, <a href="lwg-defects.html#1424">1424</a>, <a href="lwg-defects.html#1425">1425</a>, <a href="lwg-defects.html#1426">1426</a>, <a href="lwg-defects.html#1427">1427</a>, <a href="lwg-defects.html#1428">1428</a>, <a href="lwg-defects.html#1429">1429</a>, <a href="lwg-defects.html#1430">1430</a>, <a href="lwg-defects.html#1431">1431</a>, <a href="lwg-defects.html#1432">1432</a>, <a href="lwg-defects.html#1435">1435</a>, <a href="lwg-defects.html#1436">1436</a>, <a href="lwg-defects.html#1437">1437</a>, <a href="lwg-defects.html#1438">1438</a>, <a href="lwg-defects.html#1439">1439</a>, <a href="lwg-defects.html#1440">1440</a>, <a href="lwg-defects.html#1441">1441</a>, <a href="lwg-defects.html#1448">1448</a>, <a href="lwg-defects.html#1449">1449</a>, <a href="lwg-defects.html#1474">1474</a>, <a href="lwg-defects.html#1478">1478</a>, <a href="lwg-defects.html#1479">1479</a>, <a href="lwg-defects.html#1480">1480</a>, <a href="lwg-defects.html#1487">1487</a>, <a href="lwg-defects.html#1494">1494</a>, <a href="lwg-defects.html#1497">1497</a>, <a href="lwg-defects.html#1514">1514</a>, <a href="lwg-defects.html#1516">1516</a>, <a href="lwg-defects.html#1517">1517</a>, <a href="lwg-defects.html#1518">1518</a>, <a href="lwg-defects.html#1519">1519</a>, <a href="lwg-defects.html#1520">1520</a>, <a href="lwg-defects.html#1522">1522</a>, <a href="lwg-defects.html#1524">1524</a>, <a href="lwg-defects.html#1525">1525</a>, <a href="lwg-defects.html#2000">2000</a>, <a href="lwg-defects.html#2001">2001</a>, <a href="lwg-defects.html#2004">2004</a>, <a href="lwg-defects.html#2007">2007</a>, <a href="lwg-defects.html#2008">2008</a>, <a href="lwg-defects.html#2014">2014</a>, <a href="lwg-defects.html#2017">2017</a>, <a href="lwg-defects.html#2019">2019</a>, <a href="lwg-defects.html#2020">2020</a>, <a href="lwg-defects.html#2022">2022</a>, <a href="lwg-defects.html#2027">2027</a>, <a href="lwg-defects.html#2029">2029</a>, <a href="lwg-defects.html#2030">2030</a>, <a href="lwg-defects.html#2031">2031</a>, <a href="lwg-defects.html#2032">2032</a>, <a href="lwg-defects.html#2041">2041</a>, <a href="lwg-defects.html#2042">2042</a>.</li>
<li>Changed the following issue from Deferred to NAD: <a href="lwg-closed.html#1330">1330</a>.</li>
<li>Changed the following issue from Deferred to NAD Future: <a href="lwg-closed.html#1521">1521</a>.</li>
<li>Changed the following issue from Open to NAD Future: <a href="lwg-closed.html#2040">2040</a>.</li>
<li>Changed the following issue from Deferred to Open: <a href="lwg-active.html#1450">1450</a>.</li>
<li>Changed the following issue from Deferred to Ready: <a href="lwg-active.html#1214">1214</a>.</li>
<li>Changed the following 2 issues from New to Ready: <a href="lwg-active.html#2013">2013</a>, <a href="lwg-active.html#2015">2015</a>.</li>
<li>Changed the following 2 issues from Open to Ready: <a href="lwg-active.html#2010">2010</a>, <a href="lwg-active.html#2033">2033</a>.</li>
<li>Changed the following issue from Review to Ready: <a href="lwg-active.html#2021">2021</a>.</li>
<li>Changed the following 2 issues from Deferred to Review: <a href="lwg-active.html#1169">1169</a>, <a href="lwg-active.html#1175">1175</a>.</li>
<li>Changed the following issue from Open to Review: <a href="lwg-active.html#2011">2011</a>.</li>
</ul></li>
</ul>
</li>
<li>R75: 
2011-03-28 post-Madrid mailing
<ul>
<li><b>Summary:</b><ul>
<li>25 open issues, down by 71.</li>
<li>1540 closed issues, up by 80.</li>
<li>1565 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issue: <a href="lwg-closed.html#2036">2036</a>.</li>
<li>Added the following 2 Open issues: <a href="lwg-active.html#2038">2038</a>, <a href="lwg-closed.html#2040">2040</a>.</li>
<li>Added the following Ready issue: <a href="lwg-defects.html#2039">2039</a>.</li>
<li>Added the following Resolved issue: <a href="lwg-defects.html#2037">2037</a>.</li>
<li>Added the following 2 WP issues: <a href="lwg-defects.html#2041">2041</a>, <a href="lwg-defects.html#2042">2042</a>.</li>
<li>Changed the following issue from New to Deferred: <a href="lwg-closed.html#1521">1521</a>.</li>
<li>Changed the following 2 issues from Open to Deferred: <a href="lwg-active.html#1169">1169</a>, <a href="lwg-active.html#1175">1175</a>.</li>
<li>Changed the following 7 issues from Open to NAD: <a href="lwg-closed.html#1318">1318</a>, <a href="lwg-closed.html#1348">1348</a>, <a href="lwg-closed.html#1358">1358</a>, <a href="lwg-closed.html#1369">1369</a>, <a href="lwg-closed.html#1374">1374</a>, <a href="lwg-closed.html#1452">1452</a>, <a href="lwg-closed.html#1461">1461</a>.</li>
<li>Changed the following 6 issues from Tentatively NAD to NAD: <a href="lwg-closed.html#1371">1371</a>, <a href="lwg-closed.html#1413">1413</a>, <a href="lwg-closed.html#1485">1485</a>, <a href="lwg-closed.html#1486">1486</a>, <a href="lwg-closed.html#2006">2006</a>, <a href="lwg-closed.html#2026">2026</a>.</li>
<li>Changed the following issue from Tentatively Ready to NAD: <a href="lwg-closed.html#1456">1456</a>.</li>
<li>Changed the following 2 issues from Open to NAD Future: <a href="lwg-closed.html#1396">1396</a>, <a href="lwg-closed.html#1459">1459</a>.</li>
<li>Changed the following issue from Tentatively NAD Future to NAD Future: <a href="lwg-closed.html#1320">1320</a>.</li>
<li>Changed the following 4 issues from New to Open: <a href="lwg-active.html#2012">2012</a>, <a href="lwg-active.html#2018">2018</a>, <a href="lwg-defects.html#2033">2033</a>, <a href="lwg-active.html#2035">2035</a>.</li>
<li>Changed the following issue from New to Ready: <a href="lwg-defects.html#2028">2028</a>.</li>
<li>Changed the following issue from Review to Ready: <a href="lwg-defects.html#2009">2009</a>.</li>
<li>Changed the following issue from NAD to Resolved: <a href="lwg-defects.html#343">343</a>.</li>
<li>Changed the following issue from NAD Editorial to Resolved: <a href="lwg-defects.html#485">485</a>.</li>
<li>Changed the following 3 issues from New to Resolved: <a href="lwg-defects.html#1523">1523</a>, <a href="lwg-defects.html#2025">2025</a>, <a href="lwg-defects.html#2034">2034</a>.</li>
<li>Changed the following 13 issues from Open to Resolved: <a href="lwg-defects.html#964">964</a>, <a href="lwg-defects.html#966">966</a>, <a href="lwg-defects.html#985">985</a>, <a href="lwg-defects.html#1297">1297</a>, <a href="lwg-defects.html#1345">1345</a>, <a href="lwg-defects.html#1353">1353</a>, <a href="lwg-defects.html#1364">1364</a>, <a href="lwg-defects.html#1421">1421</a>, <a href="lwg-defects.html#1460">1460</a>, <a href="lwg-defects.html#1502">1502</a>, <a href="lwg-defects.html#1504">1504</a>, <a href="lwg-defects.html#1505">1505</a>, <a href="lwg-defects.html#1507">1507</a>.</li>
<li>Changed the following 4 issues from Tentatively Ready to Resolved: <a href="lwg-defects.html#1457">1457</a>, <a href="lwg-defects.html#1515">1515</a>, <a href="lwg-defects.html#2023">2023</a>, <a href="lwg-defects.html#2024">2024</a>.</li>
<li>Changed the following issue from New to Review: <a href="lwg-defects.html#2021">2021</a>.</li>
<li>Changed the following issue from Open to Review: <a href="lwg-active.html#2005">2005</a>.</li>
<li>Changed the following 3 issues from New to WP: <a href="lwg-defects.html#1524">1524</a>, <a href="lwg-defects.html#2008">2008</a>, <a href="lwg-defects.html#2032">2032</a>.</li>
<li>Changed the following 5 issues from Open to WP: <a href="lwg-defects.html#1252">1252</a>, <a href="lwg-defects.html#1349">1349</a>, <a href="lwg-defects.html#1448">1448</a>, <a href="lwg-defects.html#1478">1478</a>, <a href="lwg-defects.html#1487">1487</a>.</li>
<li>Changed the following 8 issues from Ready to WP: <a href="lwg-defects.html#1279">1279</a>, <a href="lwg-defects.html#1332">1332</a>, <a href="lwg-defects.html#1385">1385</a>, <a href="lwg-defects.html#1401">1401</a>, <a href="lwg-defects.html#1408">1408</a>, <a href="lwg-defects.html#1418">1418</a>, <a href="lwg-defects.html#1420">1420</a>, <a href="lwg-defects.html#1438">1438</a>.</li>
<li>Changed the following 22 issues from Tentatively Ready to WP: <a href="lwg-defects.html#1215">1215</a>, <a href="lwg-defects.html#1253">1253</a>, <a href="lwg-defects.html#1310">1310</a>, <a href="lwg-defects.html#1474">1474</a>, <a href="lwg-defects.html#1479">1479</a>, <a href="lwg-defects.html#1480">1480</a>, <a href="lwg-defects.html#1494">1494</a>, <a href="lwg-defects.html#1497">1497</a>, <a href="lwg-defects.html#1514">1514</a>, <a href="lwg-defects.html#2000">2000</a>, <a href="lwg-defects.html#2001">2001</a>, <a href="lwg-defects.html#2004">2004</a>, <a href="lwg-defects.html#2007">2007</a>, <a href="lwg-defects.html#2014">2014</a>, <a href="lwg-defects.html#2017">2017</a>, <a href="lwg-defects.html#2019">2019</a>, <a href="lwg-defects.html#2020">2020</a>, <a href="lwg-defects.html#2022">2022</a>, <a href="lwg-defects.html#2027">2027</a>, <a href="lwg-defects.html#2029">2029</a>, <a href="lwg-defects.html#2030">2030</a>, <a href="lwg-defects.html#2031">2031</a>.</li>
</ul></li>
</ul>
</li>
<li>R74: 
2011-02-28 pre-Madrid mailing
<ul>
<li><b>Summary:</b><ul>
<li>96 open issues, up by 16.</li>
<li>1460 closed issues, up by 1.</li>
<li>1556 issues total, up by 17.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 7 New issues: <a href="lwg-defects.html#2021">2021</a>, <a href="lwg-defects.html#2025">2025</a>, <a href="lwg-defects.html#2028">2028</a>, <a href="lwg-defects.html#2032">2032</a>, <a href="lwg-defects.html#2033">2033</a>, <a href="lwg-defects.html#2034">2034</a>, <a href="lwg-active.html#2035">2035</a>.</li>
<li>Added the following Tentatively NAD issue: <a href="lwg-closed.html#2026">2026</a>.</li>
<li>Added the following 8 Tentatively Ready issues: <a href="lwg-defects.html#2020">2020</a>, <a href="lwg-defects.html#2022">2022</a>, <a href="lwg-defects.html#2023">2023</a>, <a href="lwg-defects.html#2024">2024</a>, <a href="lwg-defects.html#2027">2027</a>, <a href="lwg-defects.html#2029">2029</a>, <a href="lwg-defects.html#2030">2030</a>, <a href="lwg-defects.html#2031">2031</a>.</li>
<li>Changed the following issue from Open to NAD Editorial: <a href="lwg-closed.html#1503">1503</a>.</li>
<li>Changed the following issue from New to Open: <a href="lwg-active.html#2016">2016</a>.</li>
<li>Changed the following issue from Ready to Open: <a href="lwg-closed.html#1318">1318</a>.</li>
<li>Changed the following issue from NAD to Resolved: <a href="lwg-defects.html#1229">1229</a>.</li>
<li>Changed the following 65 issues from NAD Editorial to Resolved: <a href="lwg-defects.html#732">732</a>, <a href="lwg-defects.html#756">756</a>, <a href="lwg-defects.html#767">767</a>, <a href="lwg-defects.html#793">793</a>, <a href="lwg-defects.html#794">794</a>, <a href="lwg-defects.html#800">800</a>, <a href="lwg-defects.html#803">803</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-defects.html#828">828</a>, <a href="lwg-defects.html#874">874</a>, <a href="lwg-defects.html#875">875</a>, <a href="lwg-defects.html#880">880</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#897">897</a>, <a href="lwg-defects.html#908">908</a>, <a href="lwg-defects.html#923">923</a>, <a href="lwg-defects.html#924">924</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#944">944</a>, <a href="lwg-defects.html#958">958</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-defects.html#1043">1043</a>, <a href="lwg-defects.html#1046">1046</a>, <a href="lwg-defects.html#1047">1047</a>, <a href="lwg-defects.html#1048">1048</a>, <a href="lwg-defects.html#1049">1049</a>, <a href="lwg-defects.html#1050">1050</a>, <a href="lwg-defects.html#1088">1088</a>, <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-defects.html#1093">1093</a>, <a href="lwg-defects.html#1106">1106</a>, <a href="lwg-defects.html#1129">1129</a>, <a href="lwg-defects.html#1143">1143</a>, <a href="lwg-defects.html#1145">1145</a>, <a href="lwg-defects.html#1146">1146</a>, <a href="lwg-defects.html#1147">1147</a>, <a href="lwg-defects.html#1160">1160</a>, <a href="lwg-defects.html#1161">1161</a>, <a href="lwg-defects.html#1162">1162</a>, <a href="lwg-defects.html#1163">1163</a>, <a href="lwg-defects.html#1165">1165</a>, <a href="lwg-defects.html#1166">1166</a>, <a href="lwg-defects.html#1172">1172</a>, <a href="lwg-defects.html#1185">1185</a>, <a href="lwg-defects.html#1196">1196</a>, <a href="lwg-defects.html#1210">1210</a>, <a href="lwg-defects.html#1211">1211</a>, <a href="lwg-defects.html#1212">1212</a>, <a href="lwg-defects.html#1225">1225</a>, <a href="lwg-defects.html#1226">1226</a>, <a href="lwg-defects.html#1244">1244</a>, <a href="lwg-defects.html#1248">1248</a>, <a href="lwg-defects.html#1266">1266</a>, <a href="lwg-defects.html#1269">1269</a>, <a href="lwg-defects.html#1272">1272</a>, <a href="lwg-defects.html#1273">1273</a>, <a href="lwg-defects.html#1274">1274</a>, <a href="lwg-defects.html#1275">1275</a>, <a href="lwg-defects.html#1281">1281</a>, <a href="lwg-defects.html#1291">1291</a>, <a href="lwg-defects.html#1300">1300</a>, <a href="lwg-defects.html#1304">1304</a>, <a href="lwg-defects.html#1305">1305</a>, <a href="lwg-defects.html#1311">1311</a>, <a href="lwg-defects.html#1329">1329</a>.</li>
<li>Changed the following 2 issues from Open to Tentatively NAD: <a href="lwg-closed.html#1485">1485</a>, <a href="lwg-closed.html#1486">1486</a>.</li>
<li>Changed the following 3 issues from New to Tentatively Ready: <a href="lwg-defects.html#2014">2014</a>, <a href="lwg-defects.html#2017">2017</a>, <a href="lwg-defects.html#2019">2019</a>.</li>
<li>Changed the following 8 issues from Open to Tentatively Ready: <a href="lwg-closed.html#1456">1456</a>, <a href="lwg-defects.html#1457">1457</a>, <a href="lwg-defects.html#1474">1474</a>, <a href="lwg-defects.html#1479">1479</a>, <a href="lwg-defects.html#1494">1494</a>, <a href="lwg-defects.html#1514">1514</a>, <a href="lwg-defects.html#1515">1515</a>, <a href="lwg-defects.html#2001">2001</a>.</li>
<li>Changed the following issue from Review to Tentatively Ready: <a href="lwg-defects.html#1480">1480</a>.</li>
</ul></li>
</ul>
</li>
<li>R73: 
2010-11-29 Post-Batavia mailing.
<ul>
<li><b>Summary:</b><ul>
<li>80 open issues, down by 126.</li>
<li>1459 closed issues, up by 145.</li>
<li>1539 issues total, up by 19.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 11 New issues: <a href="lwg-closed.html#1521">1521</a>, <a href="lwg-defects.html#1523">1523</a>, <a href="lwg-defects.html#2008">2008</a>, <a href="lwg-active.html#2012">2012</a>, <a href="lwg-active.html#2013">2013</a>, <a href="lwg-defects.html#2014">2014</a>, <a href="lwg-defects.html#2015">2015</a>, <a href="lwg-active.html#2016">2016</a>, <a href="lwg-defects.html#2017">2017</a>, <a href="lwg-active.html#2018">2018</a>, <a href="lwg-defects.html#2019">2019</a>.</li>
<li>Added the following 5 Open issues: <a href="lwg-defects.html#2001">2001</a>, <a href="lwg-active.html#2003">2003</a>, <a href="lwg-active.html#2005">2005</a>, <a href="lwg-defects.html#2010">2010</a>, <a href="lwg-active.html#2011">2011</a>.</li>
<li>Added the following Resolved issue: <a href="lwg-defects.html#2002">2002</a>.</li>
<li>Added the following Review issue: <a href="lwg-defects.html#2009">2009</a>.</li>
<li>Added the following Tentatively NAD issue: <a href="lwg-closed.html#2006">2006</a>.</li>
<li>Added the following 3 Tentatively Ready issues: <a href="lwg-defects.html#2000">2000</a>, <a href="lwg-defects.html#2004">2004</a>, <a href="lwg-defects.html#2007">2007</a>.</li>
<li>Added the following WP issue: <a href="lwg-defects.html#1522">1522</a>.</li>
<li>Changed the following 3 issues from New to Deferred: <a href="lwg-active.html#1213">1213</a>, <a href="lwg-defects.html#1214">1214</a>, <a href="lwg-closed.html#1330">1330</a>.</li>
<li>Changed the following issue from Open to Deferred: <a href="lwg-active.html#1450">1450</a>.</li>
<li>Changed the following 14 issues from Open to Dup: <a href="lwg-closed.html#1350">1350</a>, <a href="lwg-closed.html#1351">1351</a>, <a href="lwg-closed.html#1352">1352</a>, <a href="lwg-closed.html#1375">1375</a>, <a href="lwg-closed.html#1411">1411</a>, <a href="lwg-closed.html#1443">1443</a>, <a href="lwg-closed.html#1451">1451</a>, <a href="lwg-closed.html#1454">1454</a>, <a href="lwg-closed.html#1458">1458</a>, <a href="lwg-closed.html#1463">1463</a>, <a href="lwg-closed.html#1470">1470</a>, <a href="lwg-closed.html#1475">1475</a>, <a href="lwg-closed.html#1476">1476</a>, <a href="lwg-closed.html#1477">1477</a>.</li>
<li>Changed the following issue from New to NAD: <a href="lwg-closed.html#1331">1331</a>.</li>
<li>Changed the following 8 issues from Open to NAD: <a href="lwg-closed.html#579">579</a>, <a href="lwg-closed.html#1359">1359</a>, <a href="lwg-closed.html#1361">1361</a>, <a href="lwg-closed.html#1373">1373</a>, <a href="lwg-closed.html#1376">1376</a>, <a href="lwg-closed.html#1398">1398</a>, <a href="lwg-closed.html#1446">1446</a>, <a href="lwg-closed.html#1473">1473</a>.</li>
<li>Changed the following 2 issues from Tentatively NAD to NAD: <a href="lwg-closed.html#1190">1190</a>, <a href="lwg-closed.html#1200">1200</a>.</li>
<li>Changed the following issue from WP to NAD: <a href="lwg-closed.html#822">822</a>.</li>
<li>Changed the following 11 issues from Open to NAD Editorial: <a href="lwg-closed.html#1395">1395</a>, <a href="lwg-closed.html#1442">1442</a>, <a href="lwg-closed.html#1471">1471</a>, <a href="lwg-closed.html#1472">1472</a>, <a href="lwg-closed.html#1489">1489</a>, <a href="lwg-closed.html#1495">1495</a>, <a href="lwg-closed.html#1496">1496</a>, <a href="lwg-closed.html#1509">1509</a>, <a href="lwg-closed.html#1510">1510</a>, <a href="lwg-closed.html#1511">1511</a>, <a href="lwg-closed.html#1512">1512</a>.</li>
<li>Changed the following issue from Review to NAD Editorial: <a href="lwg-defects.html#1281">1281</a>.</li>
<li>Changed the following issue from New to NAD Future: <a href="lwg-closed.html#1289">1289</a>.</li>
<li>Changed the following 6 issues from Open to NAD Future: <a href="lwg-closed.html#1406">1406</a>, <a href="lwg-closed.html#1422">1422</a>, <a href="lwg-closed.html#1484">1484</a>, <a href="lwg-closed.html#1488">1488</a>, <a href="lwg-closed.html#1493">1493</a>, <a href="lwg-closed.html#1499">1499</a>.</li>
<li>Changed the following 2 issues from Tentatively NAD Future to NAD Future: <a href="lwg-closed.html#1173">1173</a>, <a href="lwg-closed.html#1188">1188</a>.</li>
<li>Changed the following 2 issues from New to Open: <a href="lwg-defects.html#1252">1252</a>, <a href="lwg-defects.html#1297">1297</a>.</li>
<li>Changed the following 3 issues from New to Ready: <a href="lwg-defects.html#1279">1279</a>, <a href="lwg-closed.html#1318">1318</a>, <a href="lwg-defects.html#1332">1332</a>.</li>
<li>Changed the following 6 issues from Open to Ready: <a href="lwg-defects.html#1385">1385</a>, <a href="lwg-defects.html#1401">1401</a>, <a href="lwg-defects.html#1408">1408</a>, <a href="lwg-defects.html#1418">1418</a>, <a href="lwg-defects.html#1420">1420</a>, <a href="lwg-defects.html#1438">1438</a>.</li>
<li>Changed the following 42 issues from NAD Editorial to Resolved: <a href="lwg-defects.html#353">353</a>, <a href="lwg-defects.html#431">431</a>, <a href="lwg-defects.html#482">482</a>, <a href="lwg-defects.html#525">525</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-defects.html#625">625</a>, <a href="lwg-defects.html#635">635</a>, <a href="lwg-defects.html#658">658</a>, <a href="lwg-defects.html#697">697</a>, <a href="lwg-defects.html#719">719</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-defects.html#786">786</a>, <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#823">823</a>, <a href="lwg-defects.html#827">827</a>, <a href="lwg-defects.html#834">834</a>, <a href="lwg-defects.html#884">884</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#947">947</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#953">953</a>, <a href="lwg-defects.html#983">983</a>, <a href="lwg-defects.html#1054">1054</a>, <a href="lwg-defects.html#1055">1055</a>, <a href="lwg-defects.html#1075">1075</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-defects.html#1116">1116</a>, <a href="lwg-defects.html#1117">1117</a>, <a href="lwg-defects.html#1122">1122</a>, <a href="lwg-defects.html#1135">1135</a>, <a href="lwg-defects.html#1151">1151</a>, <a href="lwg-defects.html#1174">1174</a>, <a href="lwg-defects.html#1258">1258</a>, <a href="lwg-defects.html#1260">1260</a>, <a href="lwg-defects.html#1283">1283</a>, <a href="lwg-defects.html#1293">1293</a>, <a href="lwg-defects.html#1307">1307</a>, <a href="lwg-defects.html#1321">1321</a>, <a href="lwg-defects.html#1394">1394</a>, <a href="lwg-defects.html#1405">1405</a>, <a href="lwg-defects.html#1407">1407</a>.</li>
<li>Changed the following 5 issues from New to Resolved: <a href="lwg-defects.html#1290">1290</a>, <a href="lwg-defects.html#1322">1322</a>, <a href="lwg-defects.html#1324">1324</a>, <a href="lwg-defects.html#1326">1326</a>, <a href="lwg-defects.html#1328">1328</a>.</li>
<li>Changed the following 46 issues from Open to Resolved: <a href="lwg-defects.html#801">801</a>, <a href="lwg-defects.html#1268">1268</a>, <a href="lwg-defects.html#1327">1327</a>, <a href="lwg-defects.html#1344">1344</a>, <a href="lwg-defects.html#1346">1346</a>, <a href="lwg-defects.html#1347">1347</a>, <a href="lwg-defects.html#1355">1355</a>, <a href="lwg-defects.html#1356">1356</a>, <a href="lwg-defects.html#1357">1357</a>, <a href="lwg-defects.html#1365">1365</a>, <a href="lwg-defects.html#1366">1366</a>, <a href="lwg-defects.html#1377">1377</a>, <a href="lwg-defects.html#1378">1378</a>, <a href="lwg-defects.html#1379">1379</a>, <a href="lwg-defects.html#1380">1380</a>, <a href="lwg-defects.html#1382">1382</a>, <a href="lwg-defects.html#1383">1383</a>, <a href="lwg-defects.html#1389">1389</a>, <a href="lwg-defects.html#1390">1390</a>, <a href="lwg-defects.html#1391">1391</a>, <a href="lwg-defects.html#1392">1392</a>, <a href="lwg-defects.html#1393">1393</a>, <a href="lwg-defects.html#1397">1397</a>, <a href="lwg-defects.html#1409">1409</a>, <a href="lwg-defects.html#1410">1410</a>, <a href="lwg-defects.html#1412">1412</a>, <a href="lwg-defects.html#1445">1445</a>, <a href="lwg-defects.html#1447">1447</a>, <a href="lwg-defects.html#1453">1453</a>, <a href="lwg-defects.html#1455">1455</a>, <a href="lwg-defects.html#1462">1462</a>, <a href="lwg-defects.html#1464">1464</a>, <a href="lwg-defects.html#1465">1465</a>, <a href="lwg-defects.html#1466">1466</a>, <a href="lwg-defects.html#1467">1467</a>, <a href="lwg-defects.html#1468">1468</a>, <a href="lwg-defects.html#1469">1469</a>, <a href="lwg-defects.html#1481">1481</a>, <a href="lwg-defects.html#1482">1482</a>, <a href="lwg-defects.html#1490">1490</a>, <a href="lwg-defects.html#1491">1491</a>, <a href="lwg-defects.html#1492">1492</a>, <a href="lwg-defects.html#1498">1498</a>, <a href="lwg-defects.html#1501">1501</a>, <a href="lwg-defects.html#1508">1508</a>, <a href="lwg-defects.html#1513">1513</a>.</li>
<li>Changed the following issue from Open to Review: <a href="lwg-defects.html#1480">1480</a>.</li>
<li>Changed the following 2 issues from Open to Tentatively NAD: <a href="lwg-closed.html#1371">1371</a>, <a href="lwg-closed.html#1413">1413</a>.</li>
<li>Changed the following issue from New to Tentatively NAD Future: <a href="lwg-closed.html#1320">1320</a>.</li>
<li>Changed the following 3 issues from New to Tentatively Ready: <a href="lwg-defects.html#1215">1215</a>, <a href="lwg-defects.html#1253">1253</a>, <a href="lwg-defects.html#1310">1310</a>.</li>
<li>Changed the following issue from Open to Tentatively Ready: <a href="lwg-defects.html#1497">1497</a>.</li>
<li>Changed the following 24 issues from NAD Editorial to WP: <a href="lwg-defects.html#1360">1360</a>, <a href="lwg-defects.html#1363">1363</a>, <a href="lwg-defects.html#1367">1367</a>, <a href="lwg-defects.html#1372">1372</a>, <a href="lwg-defects.html#1381">1381</a>, <a href="lwg-defects.html#1384">1384</a>, <a href="lwg-defects.html#1386">1386</a>, <a href="lwg-defects.html#1387">1387</a>, <a href="lwg-defects.html#1388">1388</a>, <a href="lwg-defects.html#1399">1399</a>, <a href="lwg-defects.html#1400">1400</a>, <a href="lwg-defects.html#1402">1402</a>, <a href="lwg-defects.html#1403">1403</a>, <a href="lwg-defects.html#1416">1416</a>, <a href="lwg-defects.html#1417">1417</a>, <a href="lwg-defects.html#1423">1423</a>, <a href="lwg-defects.html#1424">1424</a>, <a href="lwg-defects.html#1425">1425</a>, <a href="lwg-defects.html#1426">1426</a>, <a href="lwg-defects.html#1427">1427</a>, <a href="lwg-defects.html#1429">1429</a>, <a href="lwg-defects.html#1430">1430</a>, <a href="lwg-defects.html#1431">1431</a>, <a href="lwg-defects.html#1441">1441</a>.</li>
<li>Changed the following issue from New to WP: <a href="lwg-defects.html#1294">1294</a>.</li>
<li>Changed the following 10 issues from Open to WP: <a href="lwg-defects.html#1354">1354</a>, <a href="lwg-defects.html#1362">1362</a>, <a href="lwg-defects.html#1368">1368</a>, <a href="lwg-defects.html#1370">1370</a>, <a href="lwg-defects.html#1428">1428</a>, <a href="lwg-defects.html#1435">1435</a>, <a href="lwg-defects.html#1436">1436</a>, <a href="lwg-defects.html#1437">1437</a>, <a href="lwg-defects.html#1439">1439</a>, <a href="lwg-defects.html#1440">1440</a>.</li>
<li>Changed the following 2 issues from Ready to WP: <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#951">951</a>.</li>
<li>Changed the following 33 issues from Tentatively Ready to WP: <a href="lwg-defects.html#956">956</a>, <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-defects.html#1181">1181</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1198">1198</a>, <a href="lwg-defects.html#1207">1207</a>, <a href="lwg-defects.html#1234">1234</a>, <a href="lwg-defects.html#1240">1240</a>, <a href="lwg-defects.html#1249">1249</a>, <a href="lwg-defects.html#1292">1292</a>, <a href="lwg-defects.html#1295">1295</a>, <a href="lwg-defects.html#1316">1316</a>, <a href="lwg-defects.html#1319">1319</a>, <a href="lwg-defects.html#1323">1323</a>, <a href="lwg-defects.html#1325">1325</a>, <a href="lwg-defects.html#1333">1333</a>, <a href="lwg-defects.html#1334">1334</a>, <a href="lwg-defects.html#1335">1335</a>, <a href="lwg-defects.html#1337">1337</a>, <a href="lwg-defects.html#1338">1338</a>, <a href="lwg-defects.html#1339">1339</a>, <a href="lwg-defects.html#1340">1340</a>, <a href="lwg-defects.html#1404">1404</a>, <a href="lwg-defects.html#1414">1414</a>, <a href="lwg-defects.html#1432">1432</a>, <a href="lwg-defects.html#1449">1449</a>, <a href="lwg-defects.html#1516">1516</a>, <a href="lwg-defects.html#1517">1517</a>, <a href="lwg-defects.html#1518">1518</a>, <a href="lwg-defects.html#1519">1519</a>, <a href="lwg-defects.html#1520">1520</a>.</li>
</ul></li>
</ul>
</li>
<li>R72: 
2010-10-18 pre-Batavia mailing.
<ul>
<li><b>Summary:</b><ul>
<li>206 open issues, up by 141.</li>
<li>1314 closed issues, up by 36.</li>
<li>1520 issues total, up by 177.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Dup issues: <a href="lwg-closed.html#1433">1433</a>, <a href="lwg-closed.html#1444">1444</a>.</li>
<li>Added the following NAD Editorial issues: <a href="lwg-defects.html#1360">1360</a>, <a href="lwg-defects.html#1363">1363</a>, <a href="lwg-defects.html#1367">1367</a>, <a href="lwg-defects.html#1372">1372</a>, <a href="lwg-defects.html#1381">1381</a>, <a href="lwg-defects.html#1384">1384</a>, <a href="lwg-defects.html#1386">1386</a>, <a href="lwg-defects.html#1387">1387</a>, <a href="lwg-defects.html#1388">1388</a>, <a href="lwg-defects.html#1394">1394</a>, <a href="lwg-defects.html#1399">1399</a>, <a href="lwg-defects.html#1400">1400</a>, <a href="lwg-defects.html#1402">1402</a>, <a href="lwg-defects.html#1403">1403</a>, <a href="lwg-defects.html#1405">1405</a>, <a href="lwg-defects.html#1407">1407</a>, <a href="lwg-closed.html#1415">1415</a>, <a href="lwg-defects.html#1416">1416</a>, <a href="lwg-defects.html#1417">1417</a>, <a href="lwg-closed.html#1419">1419</a>, <a href="lwg-defects.html#1423">1423</a>, <a href="lwg-defects.html#1424">1424</a>, <a href="lwg-defects.html#1425">1425</a>, <a href="lwg-defects.html#1426">1426</a>, <a href="lwg-defects.html#1427">1427</a>, <a href="lwg-defects.html#1429">1429</a>, <a href="lwg-defects.html#1430">1430</a>, <a href="lwg-defects.html#1431">1431</a>, <a href="lwg-closed.html#1434">1434</a>, <a href="lwg-defects.html#1441">1441</a>, <a href="lwg-closed.html#1483">1483</a>, <a href="lwg-closed.html#1500">1500</a>, <a href="lwg-closed.html#1506">1506</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#1344">1344</a>, <a href="lwg-defects.html#1345">1345</a>, <a href="lwg-defects.html#1346">1346</a>, <a href="lwg-defects.html#1347">1347</a>, <a href="lwg-closed.html#1348">1348</a>, <a href="lwg-defects.html#1349">1349</a>, <a href="lwg-closed.html#1350">1350</a>, <a href="lwg-closed.html#1351">1351</a>, <a href="lwg-closed.html#1352">1352</a>, <a href="lwg-defects.html#1353">1353</a>, <a href="lwg-defects.html#1354">1354</a>, <a href="lwg-defects.html#1355">1355</a>, <a href="lwg-defects.html#1356">1356</a>, <a href="lwg-defects.html#1357">1357</a>, <a href="lwg-closed.html#1358">1358</a>, <a href="lwg-closed.html#1359">1359</a>, <a href="lwg-closed.html#1361">1361</a>, <a href="lwg-defects.html#1362">1362</a>, <a href="lwg-defects.html#1364">1364</a>, <a href="lwg-defects.html#1365">1365</a>, <a href="lwg-defects.html#1366">1366</a>, <a href="lwg-defects.html#1368">1368</a>, <a href="lwg-closed.html#1369">1369</a>, <a href="lwg-defects.html#1370">1370</a>, <a href="lwg-closed.html#1371">1371</a>, <a href="lwg-closed.html#1373">1373</a>, <a href="lwg-closed.html#1374">1374</a>, <a href="lwg-closed.html#1375">1375</a>, <a href="lwg-closed.html#1376">1376</a>, <a href="lwg-defects.html#1377">1377</a>, <a href="lwg-defects.html#1378">1378</a>, <a href="lwg-defects.html#1379">1379</a>, <a href="lwg-defects.html#1380">1380</a>, <a href="lwg-defects.html#1382">1382</a>, <a href="lwg-defects.html#1383">1383</a>, <a href="lwg-defects.html#1385">1385</a>, <a href="lwg-defects.html#1389">1389</a>, <a href="lwg-defects.html#1390">1390</a>, <a href="lwg-defects.html#1391">1391</a>, <a href="lwg-defects.html#1392">1392</a>, <a href="lwg-defects.html#1393">1393</a>, <a href="lwg-closed.html#1395">1395</a>, <a href="lwg-closed.html#1396">1396</a>, <a href="lwg-defects.html#1397">1397</a>, <a href="lwg-closed.html#1398">1398</a>, <a href="lwg-defects.html#1401">1401</a>, <a href="lwg-closed.html#1406">1406</a>, <a href="lwg-defects.html#1408">1408</a>, <a href="lwg-defects.html#1409">1409</a>, <a href="lwg-defects.html#1410">1410</a>, <a href="lwg-closed.html#1411">1411</a>, <a href="lwg-defects.html#1412">1412</a>, <a href="lwg-closed.html#1413">1413</a>, <a href="lwg-defects.html#1418">1418</a>, <a href="lwg-defects.html#1420">1420</a>, <a href="lwg-defects.html#1421">1421</a>, <a href="lwg-closed.html#1422">1422</a>, <a href="lwg-defects.html#1428">1428</a>, <a href="lwg-defects.html#1435">1435</a>, <a href="lwg-defects.html#1436">1436</a>, <a href="lwg-defects.html#1437">1437</a>, <a href="lwg-defects.html#1438">1438</a>, <a href="lwg-defects.html#1439">1439</a>, <a href="lwg-defects.html#1440">1440</a>, <a href="lwg-closed.html#1442">1442</a>, <a href="lwg-closed.html#1443">1443</a>, <a href="lwg-defects.html#1445">1445</a>, <a href="lwg-closed.html#1446">1446</a>, <a href="lwg-defects.html#1447">1447</a>, <a href="lwg-defects.html#1448">1448</a>, <a href="lwg-active.html#1450">1450</a>, <a href="lwg-closed.html#1451">1451</a>, <a href="lwg-closed.html#1452">1452</a>, <a href="lwg-defects.html#1453">1453</a>, <a href="lwg-closed.html#1454">1454</a>, <a href="lwg-defects.html#1455">1455</a>, <a href="lwg-closed.html#1456">1456</a>, <a href="lwg-defects.html#1457">1457</a>, <a href="lwg-closed.html#1458">1458</a>, <a href="lwg-closed.html#1459">1459</a>, <a href="lwg-defects.html#1460">1460</a>, <a href="lwg-closed.html#1461">1461</a>, <a href="lwg-defects.html#1462">1462</a>, <a href="lwg-closed.html#1463">1463</a>, <a href="lwg-defects.html#1464">1464</a>, <a href="lwg-defects.html#1465">1465</a>, <a href="lwg-defects.html#1466">1466</a>, <a href="lwg-defects.html#1467">1467</a>, <a href="lwg-defects.html#1468">1468</a>, <a href="lwg-defects.html#1469">1469</a>, <a href="lwg-closed.html#1470">1470</a>, <a href="lwg-closed.html#1471">1471</a>, <a href="lwg-closed.html#1472">1472</a>, <a href="lwg-closed.html#1473">1473</a>, <a href="lwg-defects.html#1474">1474</a>, <a href="lwg-closed.html#1475">1475</a>, <a href="lwg-closed.html#1476">1476</a>, <a href="lwg-closed.html#1477">1477</a>, <a href="lwg-defects.html#1478">1478</a>, <a href="lwg-defects.html#1479">1479</a>, <a href="lwg-defects.html#1480">1480</a>, <a href="lwg-defects.html#1481">1481</a>, <a href="lwg-defects.html#1482">1482</a>, <a href="lwg-closed.html#1484">1484</a>, <a href="lwg-closed.html#1485">1485</a>, <a href="lwg-closed.html#1486">1486</a>, <a href="lwg-defects.html#1487">1487</a>, <a href="lwg-closed.html#1488">1488</a>, <a href="lwg-closed.html#1489">1489</a>, <a href="lwg-defects.html#1490">1490</a>, <a href="lwg-defects.html#1491">1491</a>, <a href="lwg-defects.html#1492">1492</a>, <a href="lwg-closed.html#1493">1493</a>, <a href="lwg-defects.html#1494">1494</a>, <a href="lwg-closed.html#1495">1495</a>, <a href="lwg-closed.html#1496">1496</a>, <a href="lwg-defects.html#1497">1497</a>, <a href="lwg-defects.html#1498">1498</a>, <a href="lwg-closed.html#1499">1499</a>, <a href="lwg-defects.html#1501">1501</a>, <a href="lwg-defects.html#1502">1502</a>, <a href="lwg-closed.html#1503">1503</a>, <a href="lwg-defects.html#1504">1504</a>, <a href="lwg-defects.html#1505">1505</a>, <a href="lwg-defects.html#1507">1507</a>, <a href="lwg-defects.html#1508">1508</a>, <a href="lwg-closed.html#1509">1509</a>, <a href="lwg-closed.html#1510">1510</a>, <a href="lwg-closed.html#1511">1511</a>, <a href="lwg-closed.html#1512">1512</a>, <a href="lwg-defects.html#1513">1513</a>, <a href="lwg-defects.html#1514">1514</a>, <a href="lwg-defects.html#1515">1515</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="lwg-defects.html#1404">1404</a>, <a href="lwg-defects.html#1414">1414</a>, <a href="lwg-defects.html#1432">1432</a>, <a href="lwg-defects.html#1449">1449</a>, <a href="lwg-defects.html#1516">1516</a>, <a href="lwg-defects.html#1517">1517</a>, <a href="lwg-defects.html#1518">1518</a>, <a href="lwg-defects.html#1519">1519</a>, <a href="lwg-defects.html#1520">1520</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#1260">1260</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#1181">1181</a>, <a href="lwg-defects.html#1240">1240</a>, <a href="lwg-defects.html#1249">1249</a>, <a href="lwg-defects.html#1292">1292</a>, <a href="lwg-defects.html#1295">1295</a>, <a href="lwg-defects.html#1316">1316</a>, <a href="lwg-defects.html#1319">1319</a>, <a href="lwg-defects.html#1323">1323</a>, <a href="lwg-defects.html#1325">1325</a>, <a href="lwg-defects.html#1333">1333</a>, <a href="lwg-defects.html#1334">1334</a>, <a href="lwg-defects.html#1335">1335</a>, <a href="lwg-defects.html#1337">1337</a>, <a href="lwg-defects.html#1338">1338</a>, <a href="lwg-defects.html#1339">1339</a>, <a href="lwg-defects.html#1340">1340</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#956">956</a>, <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-defects.html#1234">1234</a>.</li>
</ul></li>
</ul>
</li>
<li>R71: 
2010-08-25 post-Rapperswil mailing.
<ul>
<li><b>Summary:</b><ul>
<li>65 open issues, up by 2.</li>
<li>1278 closed issues, up by 7.</li>
<li>1343 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#1335">1335</a>, <a href="lwg-defects.html#2008">2008</a>, <a href="lwg-defects.html#1337">1337</a>, <a href="lwg-defects.html#1338">1338</a>, <a href="lwg-defects.html#1339">1339</a>, <a href="lwg-defects.html#1340">1340</a>, <a href="lwg-defects.html#2009">2009</a>, <a href="lwg-defects.html#2010">2010</a>, <a href="lwg-active.html#2011">2011</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#996">996</a>, <a href="lwg-closed.html#1119">1119</a>.</li>
<li>Changed the following issues from Open to NAD Concepts: <a href="lwg-closed.html#1076">1076</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#953">953</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-active.html#1169">1169</a>, <a href="lwg-active.html#1175">1175</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#951">951</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#868">868</a>.</li>
<li>Changed the following issues from New to Tentatively NAD: <a href="lwg-closed.html#1190">1190</a>, <a href="lwg-closed.html#1200">1200</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Future: <a href="lwg-closed.html#1188">1188</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="lwg-closed.html#1173">1173</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#1198">1198</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1207">1207</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#1187">1187</a>, <a href="lwg-defects.html#1206">1206</a>, <a href="lwg-defects.html#1278">1278</a>.</li>
</ul></li>
</ul>
</li>
<li>R70: 
2010-03-26 post-Pittsburgh mailing.
<ul>
<li><b>Summary:</b><ul>
<li>63 open issues, down by 203.</li>
<li>1271 closed issues, up by 219.</li>
<li>1334 issues total, up by 16.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD Editorial issues: <a href="lwg-defects.html#1321">1321</a>, <a href="lwg-defects.html#1329">1329</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#1319">1319</a>, <a href="lwg-closed.html#1320">1320</a>, <a href="lwg-defects.html#1322">1322</a>, <a href="lwg-defects.html#1323">1323</a>, <a href="lwg-defects.html#1324">1324</a>, <a href="lwg-defects.html#1325">1325</a>, <a href="lwg-defects.html#1326">1326</a>, <a href="lwg-defects.html#1328">1328</a>, <a href="lwg-closed.html#1330">1330</a>, <a href="lwg-closed.html#1331">1331</a>, <a href="lwg-defects.html#1332">1332</a>, <a href="lwg-defects.html#1333">1333</a>, <a href="lwg-defects.html#1334">1334</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#1327">1327</a>.</li>
<li>Changed the following issues from Tentatively Dup to Dup: <a href="lwg-closed.html#1219">1219</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#1302">1302</a>, <a href="lwg-closed.html#1308">1308</a>, <a href="lwg-closed.html#1313">1313</a>, <a href="lwg-closed.html#1314">1314</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#887">887</a>, <a href="lwg-closed.html#1008">1008</a>, <a href="lwg-closed.html#1068">1068</a>, <a href="lwg-closed.html#1069">1069</a>, <a href="lwg-closed.html#1153">1153</a>, <a href="lwg-closed.html#1156">1156</a>, <a href="lwg-closed.html#1228">1228</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD: <a href="lwg-closed.html#631">631</a>, <a href="lwg-closed.html#726">726</a>, <a href="lwg-closed.html#959">959</a>, <a href="lwg-closed.html#1056">1056</a>, <a href="lwg-closed.html#1099">1099</a>, <a href="lwg-closed.html#1125">1125</a>, <a href="lwg-closed.html#1176">1176</a>, <a href="lwg-closed.html#1202">1202</a>, <a href="lwg-closed.html#1223">1223</a>, <a href="lwg-closed.html#1224">1224</a>, <a href="lwg-closed.html#1246">1246</a>, <a href="lwg-closed.html#1251">1251</a>, <a href="lwg-closed.html#1259">1259</a>, <a href="lwg-closed.html#1263">1263</a>, <a href="lwg-closed.html#1265">1265</a>, <a href="lwg-closed.html#1296">1296</a>.</li>
<li>Changed the following issues from Tentatively NAD Concepts to NAD Concepts: <a href="lwg-closed.html#910">910</a>, <a href="lwg-closed.html#1186">1186</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#1185">1185</a>, <a href="lwg-defects.html#1210">1210</a>, <a href="lwg-defects.html#1212">1212</a>, <a href="lwg-defects.html#1225">1225</a>, <a href="lwg-defects.html#1244">1244</a>, <a href="lwg-defects.html#1266">1266</a>, <a href="lwg-defects.html#1269">1269</a>, <a href="lwg-defects.html#1272">1272</a>, <a href="lwg-defects.html#1275">1275</a>, <a href="lwg-defects.html#1291">1291</a>, <a href="lwg-defects.html#1305">1305</a>, <a href="lwg-defects.html#1307">1307</a>, <a href="lwg-defects.html#1311">1311</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#299">299</a>, <a href="lwg-closed.html#397">397</a>, <a href="lwg-closed.html#408">408</a>, <a href="lwg-closed.html#446">446</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-defects.html#625">625</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-defects.html#834">834</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-defects.html#1093">1093</a>, <a href="lwg-defects.html#1151">1151</a>, <a href="lwg-defects.html#1211">1211</a>, <a href="lwg-defects.html#1248">1248</a>.</li>
<li>Changed the following issues from Ready to NAD Editorial: <a href="lwg-defects.html#485">485</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#983">983</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-defects.html#1135">1135</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Editorial: <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#1106">1106</a>, <a href="lwg-closed.html#1115">1115</a>, <a href="lwg-closed.html#1233">1233</a>, <a href="lwg-closed.html#1239">1239</a>, <a href="lwg-defects.html#1258">1258</a>, <a href="lwg-defects.html#1283">1283</a>, <a href="lwg-closed.html#1301">1301</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-defects.html#1226">1226</a>, <a href="lwg-defects.html#1273">1273</a>, <a href="lwg-defects.html#1274">1274</a>, <a href="lwg-defects.html#1293">1293</a>, <a href="lwg-defects.html#1300">1300</a>, <a href="lwg-defects.html#1304">1304</a>, <a href="lwg-closed.html#1315">1315</a>.</li>
<li>Changed the following issues from New to NAD Future: <a href="lwg-closed.html#1154">1154</a>, <a href="lwg-closed.html#1317">1317</a>.</li>
<li>Changed the following issues from Ready to NAD Future: <a href="lwg-closed.html#1052">1052</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="lwg-closed.html#1112">1112</a>, <a href="lwg-closed.html#1121">1121</a>, <a href="lwg-closed.html#1201">1201</a>, <a href="lwg-closed.html#1238">1238</a>, <a href="lwg-closed.html#1282">1282</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#1234">1234</a>, <a href="lwg-defects.html#1268">1268</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="lwg-closed.html#579">579</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#1187">1187</a>, <a href="lwg-defects.html#1206">1206</a>, <a href="lwg-defects.html#1278">1278</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#1281">1281</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="lwg-defects.html#868">868</a>.</li>
<li>Changed the following issues from New to WP: <a href="lwg-defects.html#1159">1159</a>.</li>
<li>Changed the following issues from Open to WP: <a href="lwg-defects.html#427">427</a>, <a href="lwg-defects.html#430">430</a>, <a href="lwg-defects.html#774">774</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-defects.html#835">835</a>, <a href="lwg-defects.html#861">861</a>, <a href="lwg-defects.html#885">885</a>, <a href="lwg-defects.html#896">896</a>, <a href="lwg-defects.html#900">900</a>, <a href="lwg-defects.html#911">911</a>, <a href="lwg-defects.html#1079">1079</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#296">296</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-defects.html#473">473</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-defects.html#872">872</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-defects.html#1030">1030</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-defects.html#1098">1098</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-defects.html#1123">1123</a>, <a href="lwg-defects.html#1134">1134</a>, <a href="lwg-defects.html#1136">1136</a>, <a href="lwg-defects.html#1144">1144</a>, <a href="lwg-defects.html#1157">1157</a>, <a href="lwg-defects.html#1194">1194</a>, <a href="lwg-defects.html#1204">1204</a>, <a href="lwg-defects.html#1216">1216</a>, <a href="lwg-defects.html#1227">1227</a>, <a href="lwg-defects.html#1237">1237</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#556">556</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#987">987</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1034">1034</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-defects.html#1089">1089</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-defects.html#1110">1110</a>, <a href="lwg-defects.html#1113">1113</a>, <a href="lwg-defects.html#1114">1114</a>, <a href="lwg-defects.html#1126">1126</a>, <a href="lwg-defects.html#1130">1130</a>, <a href="lwg-defects.html#1131">1131</a>, <a href="lwg-defects.html#1133">1133</a>, <a href="lwg-defects.html#1137">1137</a>, <a href="lwg-defects.html#1138">1138</a>, <a href="lwg-defects.html#1152">1152</a>, <a href="lwg-defects.html#1158">1158</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-defects.html#1177">1177</a>, <a href="lwg-defects.html#1180">1180</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-defects.html#1192">1192</a>, <a href="lwg-defects.html#1193">1193</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-defects.html#1205">1205</a>, <a href="lwg-defects.html#1208">1208</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-defects.html#1218">1218</a>, <a href="lwg-defects.html#1220">1220</a>, <a href="lwg-defects.html#1221">1221</a>, <a href="lwg-defects.html#1222">1222</a>, <a href="lwg-defects.html#1231">1231</a>, <a href="lwg-defects.html#1241">1241</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-defects.html#1247">1247</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>, <a href="lwg-defects.html#1261">1261</a>, <a href="lwg-defects.html#1262">1262</a>, <a href="lwg-defects.html#1264">1264</a>, <a href="lwg-defects.html#1267">1267</a>, <a href="lwg-defects.html#1270">1270</a>, <a href="lwg-defects.html#1271">1271</a>, <a href="lwg-defects.html#1276">1276</a>, <a href="lwg-defects.html#1277">1277</a>, <a href="lwg-defects.html#1280">1280</a>, <a href="lwg-defects.html#1284">1284</a>, <a href="lwg-defects.html#1285">1285</a>, <a href="lwg-defects.html#1286">1286</a>, <a href="lwg-defects.html#1287">1287</a>, <a href="lwg-defects.html#1288">1288</a>, <a href="lwg-defects.html#1298">1298</a>, <a href="lwg-defects.html#1299">1299</a>, <a href="lwg-defects.html#1303">1303</a>, <a href="lwg-defects.html#1306">1306</a>, <a href="lwg-defects.html#1309">1309</a>, <a href="lwg-defects.html#1312">1312</a>.</li>
</ul></li>
</ul>
</li>
<li>R69: 
2010-02-12 pre-Pittsburgh mailing.
<ul>
<li><b>Summary:</b><ul>
<li>266 open issues, up by 61.</li>
<li>1052 closed issues, down by 3.</li>
<li>1318 issues total, up by 58.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#1266">1266</a>, <a href="lwg-defects.html#1268">1268</a>, <a href="lwg-defects.html#1269">1269</a>, <a href="lwg-defects.html#1272">1272</a>, <a href="lwg-defects.html#1275">1275</a>, <a href="lwg-defects.html#1278">1278</a>, <a href="lwg-defects.html#1279">1279</a>, <a href="lwg-defects.html#1281">1281</a>, <a href="lwg-closed.html#1289">1289</a>, <a href="lwg-defects.html#1290">1290</a>, <a href="lwg-defects.html#1291">1291</a>, <a href="lwg-defects.html#1292">1292</a>, <a href="lwg-defects.html#1294">1294</a>, <a href="lwg-defects.html#1295">1295</a>, <a href="lwg-defects.html#1297">1297</a>, <a href="lwg-closed.html#1302">1302</a>, <a href="lwg-defects.html#1305">1305</a>, <a href="lwg-defects.html#1307">1307</a>, <a href="lwg-closed.html#1308">1308</a>, <a href="lwg-defects.html#1310">1310</a>, <a href="lwg-defects.html#1311">1311</a>, <a href="lwg-closed.html#1313">1313</a>, <a href="lwg-closed.html#1314">1314</a>, <a href="lwg-defects.html#1316">1316</a>, <a href="lwg-closed.html#1317">1317</a>, <a href="lwg-closed.html#1318">1318</a>.</li>
<li>Added the following Tentatively NAD issues: <a href="lwg-closed.html#1263">1263</a>, <a href="lwg-closed.html#1265">1265</a>, <a href="lwg-closed.html#1296">1296</a>.</li>
<li>Added the following Tentatively NAD Editorial issues: <a href="lwg-defects.html#1283">1283</a>, <a href="lwg-closed.html#1301">1301</a>.</li>
<li>Added the following Tentatively NAD Future issues: <a href="lwg-closed.html#1282">1282</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="lwg-defects.html#1261">1261</a>, <a href="lwg-defects.html#1262">1262</a>, <a href="lwg-defects.html#1264">1264</a>, <a href="lwg-defects.html#1267">1267</a>, <a href="lwg-defects.html#1270">1270</a>, <a href="lwg-defects.html#1271">1271</a>, <a href="lwg-defects.html#1273">1273</a>, <a href="lwg-defects.html#1274">1274</a>, <a href="lwg-defects.html#1276">1276</a>, <a href="lwg-defects.html#1277">1277</a>, <a href="lwg-defects.html#1280">1280</a>, <a href="lwg-defects.html#1284">1284</a>, <a href="lwg-defects.html#1285">1285</a>, <a href="lwg-defects.html#1286">1286</a>, <a href="lwg-defects.html#1287">1287</a>, <a href="lwg-defects.html#1288">1288</a>, <a href="lwg-defects.html#1293">1293</a>, <a href="lwg-defects.html#1298">1298</a>, <a href="lwg-defects.html#1299">1299</a>, <a href="lwg-defects.html#1300">1300</a>, <a href="lwg-defects.html#1303">1303</a>, <a href="lwg-defects.html#1304">1304</a>, <a href="lwg-defects.html#1306">1306</a>, <a href="lwg-defects.html#1309">1309</a>, <a href="lwg-defects.html#1312">1312</a>, <a href="lwg-closed.html#1315">1315</a>.</li>
<li>Changed the following issues from NAD to NAD Editorial: <a href="lwg-closed.html#101">101</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="lwg-defects.html#1248">1248</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#1207">1207</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#1079">1079</a>.</li>
<li>Changed the following issues from New to Tentatively Dup: <a href="lwg-closed.html#1219">1219</a>.</li>
<li>Changed the following issues from New to Tentatively NAD: <a href="lwg-closed.html#1125">1125</a>, <a href="lwg-closed.html#1176">1176</a>, <a href="lwg-closed.html#1202">1202</a>, <a href="lwg-closed.html#1223">1223</a>, <a href="lwg-closed.html#1224">1224</a>, <a href="lwg-closed.html#1246">1246</a>, <a href="lwg-closed.html#1251">1251</a>, <a href="lwg-closed.html#1259">1259</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="lwg-closed.html#726">726</a>, <a href="lwg-closed.html#959">959</a>.</li>
<li>Changed the following issues from Review to Tentatively NAD: <a href="lwg-closed.html#631">631</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Concepts: <a href="lwg-closed.html#910">910</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="lwg-defects.html#1258">1258</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#1106">1106</a>.</li>
<li>Changed the following issues from Ready to Tentatively NAD Editorial: <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#889">889</a>.</li>
<li>Changed the following issues from NAD to Tentatively Ready: <a href="lwg-closed.html#579">579</a>.</li>
<li>Changed the following issues from NAD Editorial to Tentatively Ready: <a href="lwg-defects.html#1195">1195</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#1131">1131</a>, <a href="lwg-defects.html#1133">1133</a>, <a href="lwg-defects.html#1137">1137</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-defects.html#1180">1180</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-defects.html#1193">1193</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-defects.html#1205">1205</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-defects.html#1218">1218</a>, <a href="lwg-defects.html#1221">1221</a>, <a href="lwg-defects.html#1222">1222</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1034">1034</a>, <a href="lwg-defects.html#1089">1089</a>, <a href="lwg-defects.html#1110">1110</a>.</li>
<li>Changed the following issues from Ready to Tentatively Ready: <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#1177">1177</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="lwg-defects.html#556">556</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#1130">1130</a>, <a href="lwg-defects.html#1247">1247</a>.</li>
<li>Changed the following issues from Pending WP to WP: <a href="lwg-defects.html#970">970</a>.</li>
</ul></li>
</ul>
</li>
<li>R68: 
2009-11-06 post-Santa Cruz mailing.
<ul>
<li><b>Summary:</b><ul>
<li>205 open issues, down by 77.</li>
<li>1055 closed issues, up by 120.</li>
<li>1260 issues total, up by 43.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Dup issues: <a href="lwg-closed.html#1230">1230</a>.</li>
<li>Added the following NAD issues: <a href="lwg-defects.html#1229">1229</a>, <a href="lwg-closed.html#1236">1236</a>, <a href="lwg-closed.html#1243">1243</a>.</li>
<li>Added the following NAD Editorial issues: <a href="lwg-closed.html#1232">1232</a>.</li>
<li>Added the following NAD Future issues: <a href="lwg-closed.html#1235">1235</a>, <a href="lwg-closed.html#1242">1242</a>, <a href="lwg-defects.html#1248">1248</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#1218">1218</a>, <a href="lwg-closed.html#1219">1219</a>, <a href="lwg-defects.html#1221">1221</a>, <a href="lwg-defects.html#1222">1222</a>, <a href="lwg-closed.html#1223">1223</a>, <a href="lwg-closed.html#1224">1224</a>, <a href="lwg-defects.html#1225">1225</a>, <a href="lwg-defects.html#1234">1234</a>, <a href="lwg-defects.html#1240">1240</a>, <a href="lwg-defects.html#1244">1244</a>, <a href="lwg-defects.html#1245">1245</a>, <a href="lwg-closed.html#1246">1246</a>, <a href="lwg-defects.html#1249">1249</a>, <a href="lwg-defects.html#1250">1250</a>, <a href="lwg-closed.html#1251">1251</a>, <a href="lwg-defects.html#1252">1252</a>, <a href="lwg-defects.html#1253">1253</a>, <a href="lwg-defects.html#1254">1254</a>, <a href="lwg-defects.html#1255">1255</a>, <a href="lwg-defects.html#1256">1256</a>, <a href="lwg-defects.html#1257">1257</a>, <a href="lwg-defects.html#1258">1258</a>, <a href="lwg-closed.html#1259">1259</a>, <a href="lwg-defects.html#1260">1260</a>.</li>
<li>Added the following Open issues: <a href="lwg-closed.html#1228">1228</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#1227">1227</a>, <a href="lwg-defects.html#1237">1237</a>.</li>
<li>Added the following Review issues: <a href="lwg-defects.html#1247">1247</a>.</li>
<li>Added the following Tentatively NAD Editorial issues: <a href="lwg-closed.html#1233">1233</a>, <a href="lwg-closed.html#1239">1239</a>.</li>
<li>Added the following Tentatively NAD Future issues: <a href="lwg-closed.html#1238">1238</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="lwg-defects.html#1220">1220</a>, <a href="lwg-defects.html#1226">1226</a>, <a href="lwg-defects.html#1231">1231</a>, <a href="lwg-defects.html#1241">1241</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#1132">1132</a>, <a href="lwg-closed.html#1148">1148</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#96">96</a>, <a href="lwg-closed.html#458">458</a>, <a href="lwg-closed.html#463">463</a>, <a href="lwg-closed.html#916">916</a>, <a href="lwg-closed.html#917">917</a>, <a href="lwg-closed.html#919">919</a>, <a href="lwg-closed.html#955">955</a>, <a href="lwg-closed.html#977">977</a>, <a href="lwg-closed.html#1009">1009</a>, <a href="lwg-closed.html#1020">1020</a>, <a href="lwg-closed.html#1035">1035</a>, <a href="lwg-closed.html#1042">1042</a>, <a href="lwg-closed.html#1051">1051</a>, <a href="lwg-closed.html#1064">1064</a>.</li>
<li>Changed the following issues from Review to NAD: <a href="lwg-closed.html#668">668</a>, <a href="lwg-closed.html#930">930</a>, <a href="lwg-closed.html#1091">1091</a>, <a href="lwg-closed.html#1102">1102</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD: <a href="lwg-closed.html#588">588</a>, <a href="lwg-closed.html#617">617</a>, <a href="lwg-closed.html#971">971</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to NAD: <a href="lwg-closed.html#1062">1062</a>.</li>
<li>Changed the following issues from NAD Concepts to NAD Editorial: <a href="lwg-defects.html#1143">1143</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#1116">1116</a>, <a href="lwg-defects.html#1117">1117</a>, <a href="lwg-defects.html#1122">1122</a>, <a href="lwg-defects.html#1129">1129</a>, <a href="lwg-defects.html#1145">1145</a>, <a href="lwg-defects.html#1146">1146</a>, <a href="lwg-defects.html#1147">1147</a>, <a href="lwg-closed.html#1155">1155</a>, <a href="lwg-defects.html#1166">1166</a>, <a href="lwg-defects.html#1172">1172</a>, <a href="lwg-defects.html#1174">1174</a>, <a href="lwg-closed.html#1179">1179</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-defects.html#1196">1196</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#431">431</a>, <a href="lwg-closed.html#580">580</a>, <a href="lwg-defects.html#635">635</a>, <a href="lwg-defects.html#719">719</a>, <a href="lwg-defects.html#823">823</a>, <a href="lwg-defects.html#827">827</a>, <a href="lwg-closed.html#879">879</a>, <a href="lwg-defects.html#880">880</a>, <a href="lwg-defects.html#908">908</a>, <a href="lwg-defects.html#923">923</a>, <a href="lwg-defects.html#924">924</a>, <a href="lwg-closed.html#926">926</a>, <a href="lwg-defects.html#944">944</a>, <a href="lwg-defects.html#947">947</a>, <a href="lwg-defects.html#958">958</a>, <a href="lwg-defects.html#1046">1046</a>, <a href="lwg-defects.html#1048">1048</a>, <a href="lwg-defects.html#1054">1054</a>, <a href="lwg-defects.html#1055">1055</a>, <a href="lwg-defects.html#1075">1075</a>, <a href="lwg-defects.html#1088">1088</a>, <a href="lwg-defects.html#1160">1160</a>, <a href="lwg-defects.html#1161">1161</a>, <a href="lwg-defects.html#1162">1162</a>, <a href="lwg-defects.html#1163">1163</a>, <a href="lwg-defects.html#1165">1165</a>.</li>
<li>Changed the following issues from Review to NAD Editorial: <a href="lwg-defects.html#828">828</a>, <a href="lwg-defects.html#897">897</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-defects.html#1043">1043</a>, <a href="lwg-defects.html#1047">1047</a>, <a href="lwg-defects.html#1049">1049</a>, <a href="lwg-defects.html#1050">1050</a>.</li>
<li>Changed the following issues from New to NAD Future: <a href="lwg-closed.html#1120">1120</a>, <a href="lwg-closed.html#1150">1150</a>, <a href="lwg-closed.html#1184">1184</a>, <a href="lwg-closed.html#1203">1203</a>, <a href="lwg-closed.html#1217">1217</a>.</li>
<li>Changed the following issues from Open to NAD Future: <a href="lwg-closed.html#484">484</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-closed.html#851">851</a>, <a href="lwg-closed.html#933">933</a>, <a href="lwg-closed.html#935">935</a>, <a href="lwg-closed.html#936">936</a>, <a href="lwg-closed.html#961">961</a>, <a href="lwg-closed.html#1041">1041</a>, <a href="lwg-closed.html#1053">1053</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="lwg-closed.html#1031">1031</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-closed.html#1119">1119</a>, <a href="lwg-defects.html#1151">1151</a>, <a href="lwg-closed.html#1153">1153</a>, <a href="lwg-closed.html#1156">1156</a>, <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-closed.html#1173">1173</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1211">1211</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#430">430</a>, <a href="lwg-defects.html#834">834</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-closed.html#397">397</a>, <a href="lwg-closed.html#408">408</a>, <a href="lwg-defects.html#835">835</a>.</li>
<li>Changed the following issues from Tentatively NAD to Open: <a href="lwg-defects.html#625">625</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#1123">1123</a>, <a href="lwg-defects.html#1134">1134</a>, <a href="lwg-defects.html#1135">1135</a>, <a href="lwg-defects.html#1136">1136</a>, <a href="lwg-defects.html#1144">1144</a>, <a href="lwg-defects.html#1177">1177</a>, <a href="lwg-defects.html#1194">1194</a>, <a href="lwg-defects.html#1204">1204</a>, <a href="lwg-defects.html#1216">1216</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#296">296</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-defects.html#485">485</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#872">872</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-defects.html#1030">1030</a>, <a href="lwg-defects.html#1079">1079</a>, <a href="lwg-defects.html#1098">1098</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#473">473</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>, <a href="lwg-defects.html#983">983</a>, <a href="lwg-closed.html#1052">1052</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-defects.html#1157">1157</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#1130">1130</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#556">556</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#929">929</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="lwg-closed.html#1056">1056</a>, <a href="lwg-closed.html#1099">1099</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Concepts: <a href="lwg-closed.html#1186">1186</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="lwg-closed.html#1115">1115</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Future: <a href="lwg-closed.html#1121">1121</a>, <a href="lwg-closed.html#1201">1201</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="lwg-closed.html#1112">1112</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#1126">1126</a>, <a href="lwg-defects.html#1138">1138</a>, <a href="lwg-defects.html#1152">1152</a>, <a href="lwg-defects.html#1158">1158</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-defects.html#1192">1192</a>, <a href="lwg-defects.html#1208">1208</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#987">987</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-defects.html#1113">1113</a>, <a href="lwg-defects.html#1114">1114</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#149">149</a>, <a href="lwg-defects.html#419">419</a>, <a href="lwg-defects.html#498">498</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-defects.html#696">696</a>, <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-defects.html#723">723</a>, <a href="lwg-defects.html#788">788</a>, <a href="lwg-closed.html#822">822</a>, <a href="lwg-defects.html#838">838</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-defects.html#881">881</a>, <a href="lwg-defects.html#883">883</a>, <a href="lwg-defects.html#886">886</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-defects.html#1004">1004</a>, <a href="lwg-defects.html#1178">1178</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-defects.html#1019">1019</a>.</li>
</ul></li>
</ul>
</li>
<li>R67: 
2009-09-25 pre-Santa Cruz mailing.
<ul>
<li><b>Summary:</b><ul>
<li>282 open issues, up by 32.</li>
<li>935 closed issues, down by 1.</li>
<li>1217 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#1187">1187</a>, <a href="lwg-closed.html#1188">1188</a>, <a href="lwg-defects.html#1189">1189</a>, <a href="lwg-closed.html#1190">1190</a>, <a href="lwg-defects.html#1191">1191</a>, <a href="lwg-defects.html#1192">1192</a>, <a href="lwg-defects.html#1193">1193</a>, <a href="lwg-defects.html#1194">1194</a>, <a href="lwg-defects.html#1195">1195</a>, <a href="lwg-defects.html#1196">1196</a>, <a href="lwg-defects.html#1197">1197</a>, <a href="lwg-defects.html#1198">1198</a>, <a href="lwg-defects.html#1199">1199</a>, <a href="lwg-closed.html#1200">1200</a>, <a href="lwg-closed.html#1201">1201</a>, <a href="lwg-closed.html#1202">1202</a>, <a href="lwg-closed.html#1203">1203</a>, <a href="lwg-defects.html#1204">1204</a>, <a href="lwg-defects.html#1205">1205</a>, <a href="lwg-defects.html#1206">1206</a>, <a href="lwg-defects.html#1207">1207</a>, <a href="lwg-defects.html#1208">1208</a>, <a href="lwg-defects.html#1209">1209</a>, <a href="lwg-defects.html#1210">1210</a>, <a href="lwg-defects.html#1211">1211</a>, <a href="lwg-defects.html#1212">1212</a>, <a href="lwg-active.html#1213">1213</a>, <a href="lwg-defects.html#1214">1214</a>, <a href="lwg-defects.html#1215">1215</a>, <a href="lwg-defects.html#1216">1216</a>, <a href="lwg-closed.html#1217">1217</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="lwg-defects.html#296">296</a>.</li>
<li>Changed the following issues from WP to Pending WP: <a href="lwg-defects.html#970">970</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#976">976</a>, <a href="lwg-closed.html#1052">1052</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="lwg-defects.html#780">780</a>.</li>
</ul></li>
</ul>
</li>
<li>R66: 
2009-07-31 post-Frankfurt mailing.
<ul>
<li><b>Summary:</b><ul>
<li>250 open issues, down by 128.</li>
<li>936 closed issues, up by 171.</li>
<li>1186 issues total, up by 43.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issues: <a href="lwg-closed.html#1164">1164</a>.</li>
<li>Added the following NAD Concepts issues: <a href="lwg-closed.html#1149">1149</a>, <a href="lwg-closed.html#1167">1167</a>.</li>
<li>Added the following NAD Editorial issues: <a href="lwg-closed.html#1168">1168</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#1144">1144</a>, <a href="lwg-defects.html#1145">1145</a>, <a href="lwg-defects.html#1146">1146</a>, <a href="lwg-defects.html#1147">1147</a>, <a href="lwg-closed.html#1148">1148</a>, <a href="lwg-closed.html#1150">1150</a>, <a href="lwg-defects.html#1151">1151</a>, <a href="lwg-defects.html#1152">1152</a>, <a href="lwg-closed.html#1153">1153</a>, <a href="lwg-closed.html#1154">1154</a>, <a href="lwg-closed.html#1155">1155</a>, <a href="lwg-closed.html#1156">1156</a>, <a href="lwg-defects.html#1158">1158</a>, <a href="lwg-defects.html#1159">1159</a>, <a href="lwg-defects.html#1166">1166</a>, <a href="lwg-active.html#1169">1169</a>, <a href="lwg-defects.html#1170">1170</a>, <a href="lwg-defects.html#1171">1171</a>, <a href="lwg-defects.html#1172">1172</a>, <a href="lwg-closed.html#1173">1173</a>, <a href="lwg-defects.html#1174">1174</a>, <a href="lwg-active.html#1175">1175</a>, <a href="lwg-closed.html#1176">1176</a>, <a href="lwg-defects.html#1177">1177</a>, <a href="lwg-closed.html#1179">1179</a>, <a href="lwg-defects.html#1180">1180</a>, <a href="lwg-defects.html#1181">1181</a>, <a href="lwg-defects.html#1182">1182</a>, <a href="lwg-defects.html#1183">1183</a>, <a href="lwg-closed.html#1184">1184</a>, <a href="lwg-defects.html#1185">1185</a>, <a href="lwg-closed.html#1186">1186</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#1160">1160</a>, <a href="lwg-defects.html#1161">1161</a>, <a href="lwg-defects.html#1162">1162</a>, <a href="lwg-defects.html#1163">1163</a>, <a href="lwg-defects.html#1165">1165</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#1178">1178</a>.</li>
<li>Added the following Review issues: <a href="lwg-defects.html#1157">1157</a>.</li>
<li>Changed the following issues from Open to Dup: <a href="lwg-closed.html#750">750</a>, <a href="lwg-closed.html#895">895</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#111">111</a>, <a href="lwg-closed.html#128">128</a>, <a href="lwg-closed.html#138">138</a>, <a href="lwg-closed.html#190">190</a>, <a href="lwg-closed.html#219">219</a>, <a href="lwg-closed.html#290">290</a>, <a href="lwg-closed.html#309">309</a>, <a href="lwg-closed.html#342">342</a>, <a href="lwg-defects.html#343">343</a>, <a href="lwg-closed.html#382">382</a>, <a href="lwg-closed.html#394">394</a>, <a href="lwg-closed.html#398">398</a>, <a href="lwg-closed.html#417">417</a>, <a href="lwg-closed.html#418">418</a>, <a href="lwg-closed.html#421">421</a>, <a href="lwg-closed.html#459">459</a>, <a href="lwg-closed.html#466">466</a>, <a href="lwg-closed.html#492">492</a>, <a href="lwg-closed.html#502">502</a>, <a href="lwg-closed.html#503">503</a>, <a href="lwg-closed.html#546">546</a>, <a href="lwg-closed.html#573">573</a>, <a href="lwg-closed.html#582">582</a>, <a href="lwg-closed.html#585">585</a>, <a href="lwg-closed.html#597">597</a>, <a href="lwg-closed.html#606">606</a>, <a href="lwg-closed.html#614">614</a>, <a href="lwg-closed.html#632">632</a>, <a href="lwg-closed.html#721">721</a>, <a href="lwg-closed.html#747">747</a>, <a href="lwg-closed.html#751">751</a>, <a href="lwg-closed.html#833">833</a>, <a href="lwg-closed.html#941">941</a>, <a href="lwg-closed.html#992">992</a>.</li>
<li>Changed the following issues from Review to NAD: <a href="lwg-closed.html#1003">1003</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD: <a href="lwg-closed.html#568">568</a>, <a href="lwg-closed.html#644">644</a>, <a href="lwg-closed.html#667">667</a>, <a href="lwg-closed.html#669">669</a>, <a href="lwg-closed.html#701">701</a>, <a href="lwg-closed.html#702">702</a>, <a href="lwg-closed.html#785">785</a>, <a href="lwg-closed.html#863">863</a>, <a href="lwg-closed.html#901">901</a>, <a href="lwg-closed.html#903">903</a>, <a href="lwg-closed.html#946">946</a>, <a href="lwg-closed.html#988">988</a>, <a href="lwg-closed.html#995">995</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD: <a href="lwg-closed.html#1002">1002</a>.</li>
<li>Changed the following issues from New to NAD Concepts: <a href="lwg-closed.html#1124">1124</a>, <a href="lwg-closed.html#1127">1127</a>, <a href="lwg-closed.html#1128">1128</a>, <a href="lwg-closed.html#1139">1139</a>, <a href="lwg-closed.html#1140">1140</a>, <a href="lwg-closed.html#1141">1141</a>, <a href="lwg-closed.html#1142">1142</a>, <a href="lwg-defects.html#1143">1143</a>.</li>
<li>Changed the following issues from Open to NAD Concepts: <a href="lwg-closed.html#902">902</a>, <a href="lwg-closed.html#989">989</a>, <a href="lwg-closed.html#1000">1000</a>, <a href="lwg-closed.html#1007">1007</a>, <a href="lwg-closed.html#1010">1010</a>, <a href="lwg-closed.html#1015">1015</a>, <a href="lwg-closed.html#1016">1016</a>, <a href="lwg-closed.html#1017">1017</a>, <a href="lwg-closed.html#1018">1018</a>, <a href="lwg-closed.html#1026">1026</a>, <a href="lwg-closed.html#1027">1027</a>, <a href="lwg-closed.html#1028">1028</a>, <a href="lwg-closed.html#1029">1029</a>, <a href="lwg-closed.html#1032">1032</a>, <a href="lwg-closed.html#1036">1036</a>, <a href="lwg-closed.html#1057">1057</a>, <a href="lwg-closed.html#1059">1059</a>, <a href="lwg-closed.html#1072">1072</a>, <a href="lwg-closed.html#1078">1078</a>, <a href="lwg-closed.html#1081">1081</a>, <a href="lwg-closed.html#1082">1082</a>, <a href="lwg-closed.html#1083">1083</a>, <a href="lwg-closed.html#1084">1084</a>, <a href="lwg-closed.html#1085">1085</a>, <a href="lwg-closed.html#1086">1086</a>, <a href="lwg-closed.html#1092">1092</a>, <a href="lwg-closed.html#1096">1096</a>, <a href="lwg-closed.html#1105">1105</a>.</li>
<li>Changed the following issues from Review to NAD Concepts: <a href="lwg-closed.html#1001">1001</a>, <a href="lwg-closed.html#1005">1005</a>, <a href="lwg-closed.html#1080">1080</a>, <a href="lwg-closed.html#1087">1087</a>, <a href="lwg-closed.html#1111">1111</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD Concepts: <a href="lwg-closed.html#912">912</a>, <a href="lwg-closed.html#918">918</a>, <a href="lwg-closed.html#1074">1074</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Concepts: <a href="lwg-closed.html#927">927</a>, <a href="lwg-closed.html#1109">1109</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Concepts: <a href="lwg-closed.html#906">906</a>, <a href="lwg-closed.html#913">913</a>, <a href="lwg-closed.html#914">914</a>, <a href="lwg-closed.html#928">928</a>, <a href="lwg-closed.html#1024">1024</a>, <a href="lwg-closed.html#1063">1063</a>, <a href="lwg-closed.html#1067">1067</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#718">718</a>, <a href="lwg-closed.html#873">873</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Editorial: <a href="lwg-closed.html#424">424</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-closed.html#837">837</a>, <a href="lwg-closed.html#862">862</a>, <a href="lwg-closed.html#867">867</a>, <a href="lwg-defects.html#884">884</a>, <a href="lwg-closed.html#945">945</a>, <a href="lwg-closed.html#952">952</a>, <a href="lwg-closed.html#969">969</a>, <a href="lwg-closed.html#972">972</a>, <a href="lwg-closed.html#973">973</a>, <a href="lwg-closed.html#979">979</a>, <a href="lwg-closed.html#1023">1023</a>, <a href="lwg-closed.html#1058">1058</a>, <a href="lwg-closed.html#1060">1060</a>, <a href="lwg-closed.html#1061">1061</a>, <a href="lwg-closed.html#1077">1077</a>, <a href="lwg-closed.html#1101">1101</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="lwg-closed.html#1013">1013</a>, <a href="lwg-closed.html#1107">1107</a>.</li>
<li>Changed the following issues from Open to NAD Future: <a href="lwg-closed.html#255">255</a>, <a href="lwg-closed.html#423">423</a>, <a href="lwg-closed.html#523">523</a>, <a href="lwg-closed.html#708">708</a>, <a href="lwg-closed.html#760">760</a>, <a href="lwg-closed.html#839">839</a>, <a href="lwg-closed.html#877">877</a>.</li>
<li>Changed the following issues from CD1 to Open: <a href="lwg-defects.html#823">823</a>.</li>
<li>Changed the following issues from NAD Editorial to Open: <a href="lwg-closed.html#299">299</a>, <a href="lwg-closed.html#484">484</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#872">872</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-closed.html#879">879</a>, <a href="lwg-closed.html#919">919</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#987">987</a>, <a href="lwg-closed.html#1009">1009</a>, <a href="lwg-defects.html#1093">1093</a>.</li>
<li>Changed the following issues from Tentatively NAD to Open: <a href="lwg-closed.html#458">458</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to Open: <a href="lwg-closed.html#96">96</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="lwg-closed.html#910">910</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-defects.html#1011">1011</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#149">149</a>, <a href="lwg-defects.html#419">419</a>, <a href="lwg-defects.html#430">430</a>, <a href="lwg-defects.html#498">498</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-defects.html#696">696</a>, <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-defects.html#723">723</a>, <a href="lwg-defects.html#788">788</a>, <a href="lwg-defects.html#834">834</a>, <a href="lwg-defects.html#838">838</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-defects.html#881">881</a>, <a href="lwg-defects.html#883">883</a>, <a href="lwg-defects.html#886">886</a>, <a href="lwg-defects.html#1004">1004</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#780">780</a>.</li>
<li>Changed the following issues from Tentatively NAD to Ready: <a href="lwg-closed.html#822">822</a>.</li>
<li>Changed the following issues from Tentatively Ready to Ready: <a href="lwg-defects.html#934">934</a>.</li>
<li>Changed the following issues from NAD to Review: <a href="lwg-defects.html#871">871</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-closed.html#397">397</a>, <a href="lwg-closed.html#408">408</a>, <a href="lwg-defects.html#473">473</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-closed.html#930">930</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>.</li>
<li>Changed the following issues from Tentatively NAD to Review: <a href="lwg-closed.html#668">668</a>.</li>
<li>Changed the following issues from Tentatively Ready to Review: <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#1100">1100</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="lwg-closed.html#588">588</a>, <a href="lwg-closed.html#617">617</a>, <a href="lwg-defects.html#625">625</a>, <a href="lwg-closed.html#971">971</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="lwg-closed.html#1031">1031</a>, <a href="lwg-closed.html#1062">1062</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-defects.html#1019">1019</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#765">765</a>, <a href="lwg-defects.html#810">810</a>, <a href="lwg-defects.html#814">814</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#869">869</a>, <a href="lwg-defects.html#878">878</a>, <a href="lwg-defects.html#888">888</a>, <a href="lwg-defects.html#890">890</a>, <a href="lwg-defects.html#898">898</a>, <a href="lwg-defects.html#899">899</a>, <a href="lwg-defects.html#904">904</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-defects.html#922">922</a>, <a href="lwg-defects.html#925">925</a>, <a href="lwg-defects.html#931">931</a>, <a href="lwg-defects.html#938">938</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-defects.html#975">975</a>, <a href="lwg-defects.html#981">981</a>, <a href="lwg-defects.html#982">982</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-defects.html#986">986</a>, <a href="lwg-defects.html#990">990</a>, <a href="lwg-defects.html#991">991</a>, <a href="lwg-defects.html#993">993</a>, <a href="lwg-defects.html#994">994</a>, <a href="lwg-defects.html#997">997</a>, <a href="lwg-defects.html#998">998</a>, <a href="lwg-defects.html#1006">1006</a>, <a href="lwg-defects.html#1014">1014</a>, <a href="lwg-defects.html#1021">1021</a>, <a href="lwg-defects.html#1037">1037</a>, <a href="lwg-defects.html#1038">1038</a>, <a href="lwg-defects.html#1039">1039</a>, <a href="lwg-defects.html#1040">1040</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-defects.html#1065">1065</a>, <a href="lwg-defects.html#1066">1066</a>, <a href="lwg-defects.html#1070">1070</a>, <a href="lwg-defects.html#1073">1073</a>, <a href="lwg-defects.html#1103">1103</a>.</li>
</ul></li>
</ul>
</li>
<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="lwg-closed.html#1115">1115</a>, <a href="lwg-defects.html#1116">1116</a>, <a href="lwg-defects.html#1117">1117</a>, <a href="lwg-defects.html#1118">1118</a>, <a href="lwg-closed.html#1119">1119</a>, <a href="lwg-closed.html#1120">1120</a>, <a href="lwg-closed.html#1121">1121</a>, <a href="lwg-defects.html#1122">1122</a>, <a href="lwg-defects.html#1123">1123</a>, <a href="lwg-closed.html#1124">1124</a>, <a href="lwg-closed.html#1125">1125</a>, <a href="lwg-defects.html#1126">1126</a>, <a href="lwg-closed.html#1127">1127</a>, <a href="lwg-closed.html#1128">1128</a>, <a href="lwg-defects.html#1129">1129</a>, <a href="lwg-defects.html#1130">1130</a>, <a href="lwg-defects.html#1131">1131</a>, <a href="lwg-closed.html#1132">1132</a>, <a href="lwg-defects.html#1133">1133</a>, <a href="lwg-defects.html#1134">1134</a>, <a href="lwg-defects.html#1135">1135</a>, <a href="lwg-defects.html#1136">1136</a>, <a href="lwg-defects.html#1137">1137</a>, <a href="lwg-defects.html#1138">1138</a>, <a href="lwg-closed.html#1139">1139</a>, <a href="lwg-closed.html#1140">1140</a>, <a href="lwg-closed.html#1141">1141</a>, <a href="lwg-closed.html#1142">1142</a>, <a href="lwg-defects.html#1143">1143</a>.</li>
<li>Added the following Open issues: <a href="lwg-closed.html#1112">1112</a>, <a href="lwg-defects.html#1113">1113</a>, <a href="lwg-defects.html#1114">1114</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#937">937</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#696">696</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#900">900</a>, <a href="lwg-defects.html#911">911</a>, <a href="lwg-closed.html#916">916</a>, <a href="lwg-closed.html#917">917</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-closed.html#933">933</a>, <a href="lwg-closed.html#935">935</a>, <a href="lwg-closed.html#941">941</a>, <a href="lwg-defects.html#947">947</a>, <a href="lwg-defects.html#951">951</a>, <a href="lwg-defects.html#953">953</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-closed.html#955">955</a>, <a href="lwg-defects.html#956">956</a>, <a href="lwg-closed.html#977">977</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-defects.html#985">985</a>, <a href="lwg-closed.html#989">989</a>, <a href="lwg-closed.html#996">996</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1054">1054</a>, <a href="lwg-closed.html#1056">1056</a>, <a href="lwg-closed.html#1057">1057</a>, <a href="lwg-closed.html#1059">1059</a>, <a href="lwg-closed.html#1062">1062</a>, <a href="lwg-closed.html#1068">1068</a>, <a href="lwg-closed.html#1069">1069</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-closed.html#1072">1072</a>, <a href="lwg-closed.html#1076">1076</a>, <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-closed.html#1092">1092</a>, <a href="lwg-closed.html#1096">1096</a>, <a href="lwg-defects.html#1098">1098</a>, <a href="lwg-closed.html#1099">1099</a>, <a href="lwg-closed.html#1105">1105</a>, <a href="lwg-defects.html#1106">1106</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-defects.html#1110">1110</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-defects.html#817">817</a>, <a href="lwg-closed.html#971">971</a>, <a href="lwg-closed.html#992">992</a>, <a href="lwg-defects.html#1004">1004</a>, <a href="lwg-closed.html#1010">1010</a>, <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-closed.html#1015">1015</a>, <a href="lwg-defects.html#1019">1019</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#835">835</a>, <a href="lwg-defects.html#897">897</a>, <a href="lwg-closed.html#919">919</a>, <a href="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#983">983</a>, <a href="lwg-closed.html#1001">1001</a>, <a href="lwg-closed.html#1080">1080</a>, <a href="lwg-closed.html#1091">1091</a>, <a href="lwg-defects.html#1093">1093</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-closed.html#1102">1102</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-closed.html#1111">1111</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#987">987</a>, <a href="lwg-closed.html#1087">1087</a>.</li>
<li>Changed the following issues from New to Tentatively NAD: <a href="lwg-closed.html#568">568</a>, <a href="lwg-closed.html#701">701</a>, <a href="lwg-closed.html#702">702</a>, <a href="lwg-closed.html#785">785</a>, <a href="lwg-closed.html#863">863</a>, <a href="lwg-closed.html#903">903</a>, <a href="lwg-closed.html#912">912</a>, <a href="lwg-closed.html#918">918</a>, <a href="lwg-closed.html#946">946</a>, <a href="lwg-closed.html#995">995</a>, <a href="lwg-closed.html#1074">1074</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="lwg-closed.html#458">458</a>, <a href="lwg-closed.html#644">644</a>, <a href="lwg-closed.html#667">667</a>, <a href="lwg-closed.html#668">668</a>, <a href="lwg-closed.html#669">669</a>.</li>
<li>Changed the following issues from Review to Tentatively NAD: <a href="lwg-closed.html#901">901</a>.</li>
<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="lwg-closed.html#822">822</a>, <a href="lwg-closed.html#988">988</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="lwg-closed.html#837">837</a>, <a href="lwg-closed.html#862">862</a>, <a href="lwg-closed.html#867">867</a>, <a href="lwg-closed.html#927">927</a>, <a href="lwg-closed.html#945">945</a>, <a href="lwg-closed.html#952">952</a>, <a href="lwg-closed.html#969">969</a>, <a href="lwg-closed.html#972">972</a>, <a href="lwg-closed.html#973">973</a>, <a href="lwg-closed.html#979">979</a>, <a href="lwg-closed.html#1058">1058</a>, <a href="lwg-closed.html#1060">1060</a>, <a href="lwg-closed.html#1061">1061</a>, <a href="lwg-closed.html#1077">1077</a>, <a href="lwg-closed.html#1101">1101</a>, <a href="lwg-closed.html#1109">1109</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="lwg-closed.html#424">424</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-defects.html#884">884</a>.</li>
<li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="lwg-closed.html#1023">1023</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="lwg-closed.html#96">96</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#810">810</a>, <a href="lwg-defects.html#898">898</a>, <a href="lwg-closed.html#906">906</a>, <a href="lwg-closed.html#910">910</a>, <a href="lwg-closed.html#913">913</a>, <a href="lwg-closed.html#914">914</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-defects.html#925">925</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-defects.html#981">981</a>, <a href="lwg-defects.html#982">982</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-defects.html#990">990</a>, <a href="lwg-defects.html#998">998</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-closed.html#1063">1063</a>, <a href="lwg-closed.html#1067">1067</a>, <a href="lwg-defects.html#1070">1070</a>, <a href="lwg-defects.html#1073">1073</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-defects.html#1103">1103</a>, <a href="lwg-closed.html#1107">1107</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#814">814</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="lwg-defects.html#899">899</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-defects.html#938">938</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-defects.html#975">975</a>, <a href="lwg-defects.html#986">986</a>, <a href="lwg-defects.html#991">991</a>, <a href="lwg-defects.html#993">993</a>, <a href="lwg-defects.html#994">994</a>, <a href="lwg-defects.html#997">997</a>, <a href="lwg-closed.html#1002">1002</a>, <a href="lwg-defects.html#1006">1006</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-closed.html#1013">1013</a>, <a href="lwg-defects.html#1014">1014</a>, <a href="lwg-defects.html#1021">1021</a>, <a href="lwg-closed.html#1024">1024</a>, <a href="lwg-defects.html#1037">1037</a>, <a href="lwg-defects.html#1038">1038</a>, <a href="lwg-defects.html#1039">1039</a>, <a href="lwg-defects.html#1040">1040</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-defects.html#1065">1065</a>, <a href="lwg-defects.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="lwg-defects.html#1093">1093</a>, <a href="lwg-defects.html#1094">1094</a>, <a href="lwg-defects.html#1095">1095</a>, <a href="lwg-closed.html#1096">1096</a>, <a href="lwg-defects.html#1097">1097</a>, <a href="lwg-defects.html#1098">1098</a>, <a href="lwg-closed.html#1099">1099</a>, <a href="lwg-defects.html#1100">1100</a>, <a href="lwg-closed.html#1101">1101</a>, <a href="lwg-closed.html#1102">1102</a>, <a href="lwg-defects.html#1103">1103</a>, <a href="lwg-defects.html#1104">1104</a>, <a href="lwg-closed.html#1105">1105</a>, <a href="lwg-defects.html#1106">1106</a>, <a href="lwg-closed.html#1107">1107</a>, <a href="lwg-defects.html#1108">1108</a>, <a href="lwg-closed.html#1109">1109</a>, <a href="lwg-defects.html#1110">1110</a>, <a href="lwg-closed.html#1111">1111</a>.</li>
<li>Changed the following issues from DR to CD1: <a href="lwg-defects.html#130">130</a>, <a href="lwg-defects.html#386">386</a>, <a href="lwg-defects.html#406">406</a>, <a href="lwg-defects.html#409">409</a>, <a href="lwg-defects.html#413">413</a>, <a href="lwg-defects.html#434">434</a>, <a href="lwg-defects.html#438">438</a>, <a href="lwg-defects.html#444">444</a>, <a href="lwg-defects.html#445">445</a>, <a href="lwg-defects.html#455">455</a>, <a href="lwg-defects.html#457">457</a>, <a href="lwg-defects.html#460">460</a>, <a href="lwg-defects.html#469">469</a>, <a href="lwg-defects.html#533">533</a>.</li>
<li>Changed the following issues from Review to New: <a href="lwg-defects.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="lwg-closed.html#1022">1022</a>.</li>
<li>Added the following NAD Future issues: <a href="lwg-closed.html#1025">1025</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#983">983</a>, <a href="lwg-defects.html#984">984</a>, <a href="lwg-defects.html#985">985</a>, <a href="lwg-closed.html#989">989</a>, <a href="lwg-defects.html#990">990</a>, <a href="lwg-closed.html#995">995</a>, <a href="lwg-closed.html#996">996</a>, <a href="lwg-defects.html#998">998</a>, <a href="lwg-defects.html#999">999</a>, <a href="lwg-closed.html#1001">1001</a>, <a href="lwg-defects.html#1033">1033</a>, <a href="lwg-defects.html#1054">1054</a>, <a href="lwg-closed.html#1056">1056</a>, <a href="lwg-closed.html#1057">1057</a>, <a href="lwg-closed.html#1058">1058</a>, <a href="lwg-closed.html#1059">1059</a>, <a href="lwg-closed.html#1060">1060</a>, <a href="lwg-closed.html#1061">1061</a>, <a href="lwg-closed.html#1062">1062</a>, <a href="lwg-closed.html#1063">1063</a>, <a href="lwg-closed.html#1067">1067</a>, <a href="lwg-closed.html#1068">1068</a>, <a href="lwg-closed.html#1069">1069</a>, <a href="lwg-defects.html#1071">1071</a>, <a href="lwg-closed.html#1072">1072</a>, <a href="lwg-defects.html#1073">1073</a>, <a href="lwg-closed.html#1074">1074</a>, <a href="lwg-closed.html#1076">1076</a>, <a href="lwg-closed.html#1077">1077</a>, <a href="lwg-closed.html#1080">1080</a>, <a href="lwg-defects.html#1090">1090</a>, <a href="lwg-closed.html#1091">1091</a>, <a href="lwg-closed.html#1092">1092</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#987">987</a>, <a href="lwg-closed.html#1000">1000</a>, <a href="lwg-closed.html#1007">1007</a>, <a href="lwg-closed.html#1008">1008</a>, <a href="lwg-closed.html#1016">1016</a>, <a href="lwg-closed.html#1017">1017</a>, <a href="lwg-closed.html#1018">1018</a>, <a href="lwg-closed.html#1020">1020</a>, <a href="lwg-closed.html#1026">1026</a>, <a href="lwg-closed.html#1027">1027</a>, <a href="lwg-closed.html#1028">1028</a>, <a href="lwg-closed.html#1029">1029</a>, <a href="lwg-defects.html#1030">1030</a>, <a href="lwg-closed.html#1031">1031</a>, <a href="lwg-closed.html#1032">1032</a>, <a href="lwg-defects.html#1034">1034</a>, <a href="lwg-closed.html#1035">1035</a>, <a href="lwg-closed.html#1036">1036</a>, <a href="lwg-closed.html#1041">1041</a>, <a href="lwg-closed.html#1042">1042</a>, <a href="lwg-defects.html#1046">1046</a>, <a href="lwg-defects.html#1048">1048</a>, <a href="lwg-closed.html#1051">1051</a>, <a href="lwg-closed.html#1052">1052</a>, <a href="lwg-closed.html#1053">1053</a>, <a href="lwg-defects.html#1055">1055</a>, <a href="lwg-closed.html#1064">1064</a>, <a href="lwg-defects.html#1075">1075</a>, <a href="lwg-closed.html#1078">1078</a>, <a href="lwg-defects.html#1079">1079</a>, <a href="lwg-closed.html#1081">1081</a>, <a href="lwg-closed.html#1082">1082</a>, <a href="lwg-closed.html#1083">1083</a>, <a href="lwg-closed.html#1084">1084</a>, <a href="lwg-closed.html#1085">1085</a>, <a href="lwg-closed.html#1086">1086</a>, <a href="lwg-closed.html#1087">1087</a>, <a href="lwg-defects.html#1088">1088</a>, <a href="lwg-defects.html#1089">1089</a>.</li>
<li>Added the following Review issues: <a href="lwg-defects.html#986">986</a>, <a href="lwg-defects.html#991">991</a>, <a href="lwg-closed.html#992">992</a>, <a href="lwg-defects.html#993">993</a>, <a href="lwg-defects.html#994">994</a>, <a href="lwg-defects.html#997">997</a>, <a href="lwg-closed.html#1002">1002</a>, <a href="lwg-closed.html#1003">1003</a>, <a href="lwg-defects.html#1004">1004</a>, <a href="lwg-closed.html#1005">1005</a>, <a href="lwg-defects.html#1006">1006</a>, <a href="lwg-closed.html#1009">1009</a>, <a href="lwg-closed.html#1010">1010</a>, <a href="lwg-defects.html#1011">1011</a>, <a href="lwg-defects.html#1012">1012</a>, <a href="lwg-closed.html#1013">1013</a>, <a href="lwg-defects.html#1014">1014</a>, <a href="lwg-closed.html#1015">1015</a>, <a href="lwg-defects.html#1019">1019</a>, <a href="lwg-defects.html#1021">1021</a>, <a href="lwg-closed.html#1023">1023</a>, <a href="lwg-closed.html#1024">1024</a>, <a href="lwg-defects.html#1037">1037</a>, <a href="lwg-defects.html#1038">1038</a>, <a href="lwg-defects.html#1039">1039</a>, <a href="lwg-defects.html#1040">1040</a>, <a href="lwg-defects.html#1043">1043</a>, <a href="lwg-defects.html#1044">1044</a>, <a href="lwg-defects.html#1045">1045</a>, <a href="lwg-defects.html#1047">1047</a>, <a href="lwg-defects.html#1049">1049</a>, <a href="lwg-defects.html#1050">1050</a>, <a href="lwg-defects.html#1065">1065</a>, <a href="lwg-defects.html#1066">1066</a>, <a href="lwg-defects.html#1070">1070</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="lwg-closed.html#988">988</a>.</li>
<li>Changed the following issues from New to Dup: <a href="lwg-closed.html#905">905</a>, <a href="lwg-closed.html#942">942</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#980">980</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#874">874</a>, <a href="lwg-defects.html#875">875</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#732">732</a>, <a href="lwg-defects.html#793">793</a>, <a href="lwg-defects.html#794">794</a>, <a href="lwg-defects.html#800">800</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#683">683</a>, <a href="lwg-closed.html#892">892</a>.</li>
<li>Changed the following issues from Ready to NAD Editorial: <a href="lwg-defects.html#803">803</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="lwg-closed.html#466">466</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="lwg-closed.html#111">111</a>, <a href="lwg-closed.html#138">138</a>, <a href="lwg-defects.html#149">149</a>, <a href="lwg-closed.html#219">219</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#880">880</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-closed.html#902">902</a>, <a href="lwg-defects.html#908">908</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#923">923</a>, <a href="lwg-defects.html#924">924</a>, <a href="lwg-closed.html#926">926</a>, <a href="lwg-closed.html#930">930</a>, <a href="lwg-closed.html#936">936</a>, <a href="lwg-defects.html#944">944</a>, <a href="lwg-defects.html#958">958</a>, <a href="lwg-closed.html#959">959</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-closed.html#961">961</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#964">964</a>, <a href="lwg-defects.html#966">966</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#788">788</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-closed.html#937">937</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-closed.html#879">879</a>, <a href="lwg-defects.html#899">899</a>, <a href="lwg-closed.html#901">901</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-defects.html#938">938</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-closed.html#971">971</a>, <a href="lwg-defects.html#975">975</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#817">817</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-defects.html#904">904</a>, <a href="lwg-defects.html#922">922</a>, <a href="lwg-closed.html#928">928</a>, <a href="lwg-defects.html#931">931</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#890">890</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="lwg-defects.html#765">765</a>, <a href="lwg-closed.html#822">822</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#869">869</a>, <a href="lwg-defects.html#878">878</a>, <a href="lwg-defects.html#888">888</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#753">753</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#821">821</a>, <a href="lwg-defects.html#866">866</a>, <a href="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="lwg-defects.html#939">939</a>, <a href="lwg-defects.html#940">940</a>, <a href="lwg-closed.html#941">941</a>, <a href="lwg-closed.html#942">942</a>, <a href="lwg-defects.html#943">943</a>, <a href="lwg-defects.html#944">944</a>, <a href="lwg-closed.html#945">945</a>, <a href="lwg-closed.html#946">946</a>, <a href="lwg-defects.html#947">947</a>, <a href="lwg-defects.html#948">948</a>, <a href="lwg-defects.html#949">949</a>, <a href="lwg-defects.html#950">950</a>, <a href="lwg-defects.html#951">951</a>, <a href="lwg-closed.html#952">952</a>, <a href="lwg-defects.html#953">953</a>, <a href="lwg-defects.html#954">954</a>, <a href="lwg-closed.html#955">955</a>, <a href="lwg-defects.html#956">956</a>, <a href="lwg-defects.html#957">957</a>, <a href="lwg-defects.html#958">958</a>, <a href="lwg-closed.html#959">959</a>, <a href="lwg-defects.html#960">960</a>, <a href="lwg-closed.html#961">961</a>, <a href="lwg-defects.html#962">962</a>, <a href="lwg-defects.html#963">963</a>, <a href="lwg-defects.html#964">964</a>, <a href="lwg-defects.html#965">965</a>, <a href="lwg-defects.html#966">966</a>, <a href="lwg-defects.html#967">967</a>, <a href="lwg-defects.html#968">968</a>, <a href="lwg-closed.html#969">969</a>, <a href="lwg-defects.html#970">970</a>, <a href="lwg-closed.html#971">971</a>, <a href="lwg-closed.html#972">972</a>, <a href="lwg-closed.html#973">973</a>, <a href="lwg-defects.html#974">974</a>, <a href="lwg-defects.html#975">975</a>, <a href="lwg-defects.html#976">976</a>, <a href="lwg-closed.html#977">977</a>, <a href="lwg-defects.html#978">978</a>, <a href="lwg-closed.html#979">979</a>, <a href="lwg-closed.html#980">980</a>, <a href="lwg-defects.html#981">981</a>, <a href="lwg-defects.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="lwg-closed.html#919">919</a>, <a href="lwg-defects.html#920">920</a>, <a href="lwg-defects.html#921">921</a>, <a href="lwg-defects.html#922">922</a>, <a href="lwg-defects.html#923">923</a>, <a href="lwg-defects.html#924">924</a>, <a href="lwg-defects.html#925">925</a>, <a href="lwg-closed.html#926">926</a>, <a href="lwg-closed.html#927">927</a>, <a href="lwg-closed.html#928">928</a>, <a href="lwg-defects.html#929">929</a>, <a href="lwg-closed.html#930">930</a>, <a href="lwg-defects.html#931">931</a>, <a href="lwg-defects.html#932">932</a>, <a href="lwg-closed.html#933">933</a>, <a href="lwg-defects.html#934">934</a>, <a href="lwg-closed.html#935">935</a>, <a href="lwg-closed.html#936">936</a>, <a href="lwg-closed.html#937">937</a>, <a href="lwg-defects.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="lwg-defects.html#882">882</a>.</li>
<li>Added the following New issues: <a href="lwg-closed.html#879">879</a>, <a href="lwg-defects.html#880">880</a>, <a href="lwg-defects.html#891">891</a>, <a href="lwg-defects.html#893">893</a>, <a href="lwg-defects.html#897">897</a>, <a href="lwg-defects.html#898">898</a>, <a href="lwg-defects.html#899">899</a>, <a href="lwg-defects.html#900">900</a>, <a href="lwg-closed.html#901">901</a>, <a href="lwg-closed.html#902">902</a>, <a href="lwg-closed.html#903">903</a>, <a href="lwg-defects.html#904">904</a>, <a href="lwg-closed.html#905">905</a>, <a href="lwg-closed.html#906">906</a>, <a href="lwg-defects.html#907">907</a>, <a href="lwg-defects.html#908">908</a>, <a href="lwg-defects.html#909">909</a>, <a href="lwg-closed.html#910">910</a>, <a href="lwg-defects.html#911">911</a>, <a href="lwg-closed.html#912">912</a>, <a href="lwg-closed.html#913">913</a>, <a href="lwg-closed.html#914">914</a>, <a href="lwg-closed.html#915">915</a>, <a href="lwg-closed.html#916">916</a>, <a href="lwg-closed.html#917">917</a>, <a href="lwg-closed.html#918">918</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#881">881</a>, <a href="lwg-defects.html#883">883</a>, <a href="lwg-defects.html#884">884</a>, <a href="lwg-defects.html#885">885</a>, <a href="lwg-defects.html#886">886</a>, <a href="lwg-closed.html#887">887</a>, <a href="lwg-defects.html#889">889</a>, <a href="lwg-defects.html#890">890</a>, <a href="lwg-closed.html#895">895</a>, <a href="lwg-defects.html#896">896</a>.</li>
<li>Added the following Pending NAD Editorial issues: <a href="lwg-closed.html#892">892</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#894">894</a>.</li>
<li>Added the following Review issues: <a href="lwg-defects.html#888">888</a>.</li>
<li>Changed the following issues from New to CD1: <a href="lwg-defects.html#818">818</a>, <a href="lwg-defects.html#820">820</a>, <a href="lwg-defects.html#843">843</a>, <a href="lwg-defects.html#845">845</a>, <a href="lwg-defects.html#846">846</a>, <a href="lwg-defects.html#856">856</a>, <a href="lwg-defects.html#858">858</a>.</li>
<li>Changed the following issues from Ready to CD1: <a href="lwg-defects.html#180">180</a>, <a href="lwg-defects.html#387">387</a>, <a href="lwg-defects.html#396">396</a>, <a href="lwg-defects.html#522">522</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#691">691</a>, <a href="lwg-defects.html#713">713</a>, <a href="lwg-defects.html#714">714</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-defects.html#728">728</a>, <a href="lwg-defects.html#762">762</a>, <a href="lwg-defects.html#769">769</a>, <a href="lwg-defects.html#771">771</a>, <a href="lwg-defects.html#772">772</a>, <a href="lwg-defects.html#776">776</a>, <a href="lwg-defects.html#779">779</a>, <a href="lwg-defects.html#787">787</a>, <a href="lwg-defects.html#805">805</a>, <a href="lwg-defects.html#806">806</a>, <a href="lwg-defects.html#807">807</a>, <a href="lwg-defects.html#808">808</a>, <a href="lwg-defects.html#809">809</a>, <a href="lwg-defects.html#813">813</a>, <a href="lwg-defects.html#824">824</a>, <a href="lwg-defects.html#829">829</a>, <a href="lwg-defects.html#842">842</a>, <a href="lwg-defects.html#844">844</a>, <a href="lwg-defects.html#848">848</a>, <a href="lwg-defects.html#850">850</a>, <a href="lwg-defects.html#852">852</a>.</li>
<li>Changed the following issues from Review to CD1: <a href="lwg-defects.html#23">23</a>, <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#692">692</a>, <a href="lwg-defects.html#698">698</a>, <a href="lwg-defects.html#709">709</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-defects.html#804">804</a>, <a href="lwg-defects.html#823">823</a>.</li>
<li>Changed the following issues from WP to CD1: <a href="lwg-defects.html#44">44</a>, <a href="lwg-defects.html#49">49</a>, <a href="lwg-defects.html#76">76</a>, <a href="lwg-defects.html#91">91</a>, <a href="lwg-defects.html#92">92</a>, <a href="lwg-defects.html#98">98</a>, <a href="lwg-defects.html#103">103</a>, <a href="lwg-defects.html#109">109</a>, <a href="lwg-defects.html#117">117</a>, <a href="lwg-defects.html#118">118</a>, <a href="lwg-defects.html#120">120</a>, <a href="lwg-defects.html#123">123</a>, <a href="lwg-defects.html#136">136</a>, <a href="lwg-defects.html#153">153</a>, <a href="lwg-defects.html#165">165</a>, <a href="lwg-defects.html#167">167</a>, <a href="lwg-defects.html#171">171</a>, <a href="lwg-defects.html#179">179</a>, <a href="lwg-defects.html#182">182</a>, <a href="lwg-defects.html#183">183</a>, <a href="lwg-defects.html#184">184</a>, <a href="lwg-defects.html#185">185</a>, <a href="lwg-defects.html#186">186</a>, <a href="lwg-defects.html#187">187</a>, <a href="lwg-defects.html#198">198</a>, <a href="lwg-defects.html#200">200</a>, <a href="lwg-defects.html#201">201</a>, <a href="lwg-defects.html#202">202</a>, <a href="lwg-defects.html#206">206</a>, <a href="lwg-defects.html#214">214</a>, <a href="lwg-defects.html#221">221</a>, <a href="lwg-defects.html#225">225</a>, <a href="lwg-defects.html#226">226</a>, <a href="lwg-defects.html#228">228</a>, <a href="lwg-defects.html#229">229</a>, <a href="lwg-defects.html#230">230</a>, <a href="lwg-defects.html#231">231</a>, <a href="lwg-defects.html#232">232</a>, <a href="lwg-defects.html#233">233</a>, <a href="lwg-defects.html#234">234</a>, <a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#237">237</a>, <a href="lwg-defects.html#238">238</a>, <a href="lwg-defects.html#239">239</a>, <a href="lwg-defects.html#240">240</a>, <a href="lwg-defects.html#241">241</a>, <a href="lwg-defects.html#242">242</a>, <a href="lwg-defects.html#243">243</a>, <a href="lwg-defects.html#247">247</a>, <a href="lwg-defects.html#248">248</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-defects.html#251">251</a>, <a href="lwg-defects.html#252">252</a>, <a href="lwg-defects.html#253">253</a>, <a href="lwg-defects.html#254">254</a>, <a href="lwg-defects.html#256">256</a>, <a href="lwg-defects.html#258">258</a>, <a href="lwg-defects.html#259">259</a>, <a href="lwg-defects.html#260">260</a>, <a href="lwg-defects.html#261">261</a>, <a href="lwg-defects.html#262">262</a>, <a href="lwg-defects.html#263">263</a>, <a href="lwg-defects.html#264">264</a>, <a href="lwg-defects.html#265">265</a>, <a href="lwg-defects.html#266">266</a>, <a href="lwg-defects.html#268">268</a>, <a href="lwg-defects.html#270">270</a>, <a href="lwg-defects.html#271">271</a>, <a href="lwg-defects.html#272">272</a>, <a href="lwg-defects.html#273">273</a>, <a href="lwg-defects.html#274">274</a>, <a href="lwg-defects.html#275">275</a>, <a href="lwg-defects.html#276">276</a>, <a href="lwg-defects.html#278">278</a>, <a href="lwg-defects.html#280">280</a>, <a href="lwg-defects.html#281">281</a>, <a href="lwg-defects.html#282">282</a>, <a href="lwg-defects.html#283">283</a>, <a href="lwg-defects.html#284">284</a>, <a href="lwg-defects.html#285">285</a>, <a href="lwg-defects.html#286">286</a>, <a href="lwg-defects.html#288">288</a>, <a href="lwg-defects.html#291">291</a>, <a href="lwg-defects.html#292">292</a>, <a href="lwg-defects.html#294">294</a>, <a href="lwg-defects.html#295">295</a>, <a href="lwg-defects.html#297">297</a>, <a href="lwg-defects.html#298">298</a>, <a href="lwg-defects.html#300">300</a>, <a href="lwg-defects.html#301">301</a>, <a href="lwg-defects.html#303">303</a>, <a href="lwg-defects.html#305">305</a>, <a href="lwg-defects.html#306">306</a>, <a href="lwg-defects.html#307">307</a>, <a href="lwg-defects.html#308">308</a>, <a href="lwg-defects.html#310">310</a>, <a href="lwg-defects.html#311">311</a>, <a href="lwg-defects.html#312">312</a>, <a href="lwg-defects.html#315">315</a>, <a href="lwg-defects.html#316">316</a>, <a href="lwg-defects.html#317">317</a>, <a href="lwg-defects.html#318">318</a>, <a href="lwg-defects.html#319">319</a>, <a href="lwg-defects.html#320">320</a>, <a href="lwg-defects.html#321">321</a>, <a href="lwg-defects.html#322">322</a>, <a href="lwg-defects.html#324">324</a>, <a href="lwg-defects.html#325">325</a>, <a href="lwg-defects.html#327">327</a>, <a href="lwg-defects.html#328">328</a>, <a href="lwg-defects.html#329">329</a>, <a href="lwg-defects.html#331">331</a>, <a href="lwg-defects.html#333">333</a>, <a href="lwg-defects.html#334">334</a>, <a href="lwg-defects.html#335">335</a>, <a href="lwg-defects.html#336">336</a>, <a href="lwg-defects.html#337">337</a>, <a href="lwg-defects.html#338">338</a>, <a href="lwg-defects.html#339">339</a>, <a href="lwg-defects.html#340">340</a>, <a href="lwg-defects.html#341">341</a>, <a href="lwg-defects.html#345">345</a>, <a href="lwg-defects.html#346">346</a>, <a href="lwg-defects.html#347">347</a>, <a href="lwg-defects.html#349">349</a>, <a href="lwg-defects.html#352">352</a>, <a href="lwg-defects.html#354">354</a>, <a href="lwg-defects.html#355">355</a>, <a href="lwg-defects.html#358">358</a>, <a href="lwg-defects.html#359">359</a>, <a href="lwg-defects.html#360">360</a>, <a href="lwg-defects.html#362">362</a>, <a href="lwg-defects.html#363">363</a>, <a href="lwg-defects.html#364">364</a>, <a href="lwg-defects.html#365">365</a>, <a href="lwg-defects.html#369">369</a>, <a href="lwg-defects.html#370">370</a>, <a href="lwg-defects.html#371">371</a>, <a href="lwg-defects.html#373">373</a>, <a href="lwg-defects.html#375">375</a>, <a href="lwg-defects.html#376">376</a>, <a href="lwg-defects.html#379">379</a>, <a href="lwg-defects.html#380">380</a>, <a href="lwg-defects.html#381">381</a>, <a href="lwg-defects.html#383">383</a>, <a href="lwg-defects.html#384">384</a>, <a href="lwg-defects.html#389">389</a>, <a href="lwg-defects.html#391">391</a>, <a href="lwg-defects.html#395">395</a>, <a href="lwg-defects.html#400">400</a>, <a href="lwg-defects.html#401">401</a>, <a href="lwg-defects.html#402">402</a>, <a href="lwg-defects.html#403">403</a>, <a href="lwg-defects.html#404">404</a>, <a href="lwg-defects.html#405">405</a>, <a href="lwg-defects.html#407">407</a>, <a href="lwg-defects.html#410">410</a>, <a href="lwg-defects.html#411">411</a>, <a href="lwg-defects.html#412">412</a>, <a href="lwg-defects.html#414">414</a>, <a href="lwg-defects.html#415">415</a>, <a href="lwg-defects.html#416">416</a>, <a href="lwg-defects.html#420">420</a>, <a href="lwg-defects.html#422">422</a>, <a href="lwg-defects.html#425">425</a>, <a href="lwg-defects.html#426">426</a>, <a href="lwg-defects.html#428">428</a>, <a href="lwg-defects.html#432">432</a>, <a href="lwg-defects.html#435">435</a>, <a href="lwg-defects.html#436">436</a>, <a href="lwg-defects.html#441">441</a>, <a href="lwg-defects.html#442">442</a>, <a href="lwg-defects.html#443">443</a>, <a href="lwg-defects.html#448">448</a>, <a href="lwg-defects.html#449">449</a>, <a href="lwg-defects.html#453">453</a>, <a href="lwg-defects.html#456">456</a>, <a href="lwg-defects.html#461">461</a>, <a href="lwg-defects.html#464">464</a>, <a href="lwg-defects.html#465">465</a>, <a href="lwg-defects.html#467">467</a>, <a href="lwg-defects.html#468">468</a>, <a href="lwg-defects.html#474">474</a>, <a href="lwg-defects.html#475">475</a>, <a href="lwg-defects.html#478">478</a>, <a href="lwg-defects.html#488">488</a>, <a href="lwg-defects.html#495">495</a>, <a href="lwg-defects.html#496">496</a>, <a href="lwg-defects.html#497">497</a>, <a href="lwg-defects.html#505">505</a>, <a href="lwg-defects.html#507">507</a>, <a href="lwg-defects.html#508">508</a>, <a href="lwg-defects.html#518">518</a>, <a href="lwg-defects.html#519">519</a>, <a href="lwg-defects.html#520">520</a>, <a href="lwg-defects.html#521">521</a>, <a href="lwg-defects.html#524">524</a>, <a href="lwg-defects.html#527">527</a>, <a href="lwg-defects.html#530">530</a>, <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#534">534</a>, <a href="lwg-defects.html#535">535</a>, <a href="lwg-defects.html#537">537</a>, <a href="lwg-defects.html#538">538</a>, <a href="lwg-defects.html#540">540</a>, <a href="lwg-defects.html#541">541</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#543">543</a>, <a href="lwg-defects.html#545">545</a>, <a href="lwg-defects.html#550">550</a>, <a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#552">552</a>, <a href="lwg-defects.html#559">559</a>, <a href="lwg-defects.html#561">561</a>, <a href="lwg-defects.html#562">562</a>, <a href="lwg-defects.html#563">563</a>, <a href="lwg-defects.html#566">566</a>, <a href="lwg-defects.html#567">567</a>, <a href="lwg-defects.html#574">574</a>, <a href="lwg-defects.html#575">575</a>, <a href="lwg-defects.html#576">576</a>, <a href="lwg-defects.html#577">577</a>, <a href="lwg-defects.html#578">578</a>, <a href="lwg-defects.html#581">581</a>, <a href="lwg-defects.html#586">586</a>, <a href="lwg-defects.html#589">589</a>, <a href="lwg-defects.html#593">593</a>, <a href="lwg-defects.html#595">595</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-defects.html#607">607</a>, <a href="lwg-defects.html#608">608</a>, <a href="lwg-defects.html#609">609</a>, <a href="lwg-defects.html#610">610</a>, <a href="lwg-defects.html#611">611</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-defects.html#613">613</a>, <a href="lwg-defects.html#616">616</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#619">619</a>, <a href="lwg-defects.html#620">620</a>, <a href="lwg-defects.html#621">621</a>, <a href="lwg-defects.html#622">622</a>, <a href="lwg-defects.html#623">623</a>, <a href="lwg-defects.html#624">624</a>, <a href="lwg-defects.html#628">628</a>, <a href="lwg-defects.html#634">634</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-defects.html#640">640</a>, <a href="lwg-defects.html#643">643</a>, <a href="lwg-defects.html#646">646</a>, <a href="lwg-defects.html#650">650</a>, <a href="lwg-defects.html#651">651</a>, <a href="lwg-defects.html#652">652</a>, <a href="lwg-defects.html#654">654</a>, <a href="lwg-defects.html#655">655</a>, <a href="lwg-defects.html#660">660</a>, <a href="lwg-defects.html#661">661</a>, <a href="lwg-defects.html#664">664</a>, <a href="lwg-defects.html#665">665</a>, <a href="lwg-defects.html#666">666</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-defects.html#673">673</a>, <a href="lwg-defects.html#674">674</a>, <a href="lwg-defects.html#677">677</a>, <a href="lwg-defects.html#678">678</a>, <a href="lwg-defects.html#679">679</a>, <a href="lwg-defects.html#680">680</a>, <a href="lwg-defects.html#681">681</a>, <a href="lwg-defects.html#682">682</a>, <a href="lwg-defects.html#685">685</a>, <a href="lwg-defects.html#687">687</a>, <a href="lwg-defects.html#689">689</a>, <a href="lwg-defects.html#693">693</a>, <a href="lwg-defects.html#694">694</a>, <a href="lwg-defects.html#695">695</a>, <a href="lwg-defects.html#699">699</a>, <a href="lwg-defects.html#700">700</a>, <a href="lwg-defects.html#703">703</a>, <a href="lwg-defects.html#705">705</a>, <a href="lwg-defects.html#706">706</a>, <a href="lwg-defects.html#710">710</a>, <a href="lwg-defects.html#712">712</a>, <a href="lwg-defects.html#715">715</a>, <a href="lwg-defects.html#722">722</a>, <a href="lwg-defects.html#740">740</a>, <a href="lwg-defects.html#743">743</a>, <a href="lwg-defects.html#744">744</a>, <a href="lwg-defects.html#746">746</a>, <a href="lwg-defects.html#749">749</a>, <a href="lwg-defects.html#755">755</a>, <a href="lwg-defects.html#759">759</a>, <a href="lwg-defects.html#761">761</a>, <a href="lwg-defects.html#766">766</a>, <a href="lwg-defects.html#768">768</a>, <a href="lwg-defects.html#770">770</a>, <a href="lwg-defects.html#775">775</a>, <a href="lwg-defects.html#777">777</a>, <a href="lwg-defects.html#778">778</a>, <a href="lwg-defects.html#781">781</a>, <a href="lwg-defects.html#782">782</a>, <a href="lwg-defects.html#783">783</a>, <a href="lwg-defects.html#789">789</a>, <a href="lwg-defects.html#792">792</a>, <a href="lwg-defects.html#798">798</a>.</li>
<li>Changed the following issues from Open to Dup: <a href="lwg-closed.html#670">670</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#849">849</a>, <a href="lwg-closed.html#855">855</a>, <a href="lwg-defects.html#871">871</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#454">454</a>, <a href="lwg-closed.html#832">832</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#811">811</a>, <a href="lwg-closed.html#812">812</a>, <a href="lwg-closed.html#841">841</a>, <a href="lwg-closed.html#864">864</a>, <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#872">872</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#299">299</a>, <a href="lwg-closed.html#484">484</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#742">742</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#532">532</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-closed.html#717">717</a>, <a href="lwg-closed.html#725">725</a>, <a href="lwg-closed.html#738">738</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#721">721</a>, <a href="lwg-closed.html#751">751</a>, <a href="lwg-defects.html#814">814</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-defects.html#827">827</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-defects.html#838">838</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#861">861</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-closed.html#873">873</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-closed.html#877">877</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to Open: <a href="lwg-closed.html#424">424</a>, <a href="lwg-defects.html#625">625</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-closed.html#851">851</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#788">788</a>, <a href="lwg-defects.html#821">821</a>, <a href="lwg-defects.html#866">866</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#753">753</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#803">803</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#765">765</a>, <a href="lwg-closed.html#822">822</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-defects.html#869">869</a>, <a href="lwg-defects.html#878">878</a>.</li>
<li>Changed the following issues from TC to TC1: <a href="lwg-defects.html#1">1</a>, <a href="lwg-defects.html#3">3</a>, <a href="lwg-defects.html#5">5</a>, <a href="lwg-defects.html#7">7</a>, <a href="lwg-defects.html#8">8</a>, <a href="lwg-defects.html#9">9</a>, <a href="lwg-defects.html#11">11</a>, <a href="lwg-defects.html#13">13</a>, <a href="lwg-defects.html#14">14</a>, <a href="lwg-defects.html#15">15</a>, <a href="lwg-defects.html#16">16</a>, <a href="lwg-defects.html#17">17</a>, <a href="lwg-defects.html#18">18</a>, <a href="lwg-defects.html#19">19</a>, <a href="lwg-defects.html#20">20</a>, <a href="lwg-defects.html#21">21</a>, <a href="lwg-defects.html#22">22</a>, <a href="lwg-defects.html#24">24</a>, <a href="lwg-defects.html#25">25</a>, <a href="lwg-defects.html#26">26</a>, <a href="lwg-defects.html#27">27</a>, <a href="lwg-defects.html#28">28</a>, <a href="lwg-defects.html#29">29</a>, <a href="lwg-defects.html#30">30</a>, <a href="lwg-defects.html#31">31</a>, <a href="lwg-defects.html#32">32</a>, <a href="lwg-defects.html#33">33</a>, <a href="lwg-defects.html#34">34</a>, <a href="lwg-defects.html#35">35</a>, <a href="lwg-defects.html#36">36</a>, <a href="lwg-defects.html#37">37</a>, <a href="lwg-defects.html#38">38</a>, <a href="lwg-defects.html#39">39</a>, <a href="lwg-defects.html#40">40</a>, <a href="lwg-defects.html#41">41</a>, <a href="lwg-defects.html#42">42</a>, <a href="lwg-defects.html#46">46</a>, <a href="lwg-defects.html#47">47</a>, <a href="lwg-defects.html#48">48</a>, <a href="lwg-defects.html#50">50</a>, <a href="lwg-defects.html#51">51</a>, <a href="lwg-defects.html#52">52</a>, <a href="lwg-defects.html#53">53</a>, <a href="lwg-defects.html#54">54</a>, <a href="lwg-defects.html#55">55</a>, <a href="lwg-defects.html#56">56</a>, <a href="lwg-defects.html#57">57</a>, <a href="lwg-defects.html#59">59</a>, <a href="lwg-defects.html#60">60</a>, <a href="lwg-defects.html#61">61</a>, <a href="lwg-defects.html#62">62</a>, <a href="lwg-defects.html#63">63</a>, <a href="lwg-defects.html#64">64</a>, <a href="lwg-defects.html#66">66</a>, <a href="lwg-defects.html#68">68</a>, <a href="lwg-defects.html#69">69</a>, <a href="lwg-defects.html#70">70</a>, <a href="lwg-defects.html#71">71</a>, <a href="lwg-defects.html#74">74</a>, <a href="lwg-defects.html#75">75</a>, <a href="lwg-defects.html#78">78</a>, <a href="lwg-defects.html#79">79</a>, <a href="lwg-defects.html#80">80</a>, <a href="lwg-defects.html#83">83</a>, <a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#90">90</a>, <a href="lwg-defects.html#106">106</a>, <a href="lwg-defects.html#108">108</a>, <a href="lwg-defects.html#110">110</a>, <a href="lwg-defects.html#112">112</a>, <a href="lwg-defects.html#114">114</a>, <a href="lwg-defects.html#115">115</a>, <a href="lwg-defects.html#119">119</a>, <a href="lwg-defects.html#122">122</a>, <a href="lwg-defects.html#124">124</a>, <a href="lwg-defects.html#125">125</a>, <a href="lwg-defects.html#126">126</a>, <a href="lwg-defects.html#127">127</a>, <a href="lwg-defects.html#129">129</a>, <a href="lwg-defects.html#132">132</a>, <a href="lwg-defects.html#133">133</a>, <a href="lwg-defects.html#134">134</a>, <a href="lwg-defects.html#137">137</a>, <a href="lwg-defects.html#139">139</a>, <a href="lwg-defects.html#141">141</a>, <a href="lwg-defects.html#142">142</a>, <a href="lwg-defects.html#144">144</a>, <a href="lwg-defects.html#146">146</a>, <a href="lwg-defects.html#147">147</a>, <a href="lwg-defects.html#148">148</a>, <a href="lwg-defects.html#150">150</a>, <a href="lwg-defects.html#151">151</a>, <a href="lwg-defects.html#152">152</a>, <a href="lwg-defects.html#154">154</a>, <a href="lwg-defects.html#155">155</a>, <a href="lwg-defects.html#156">156</a>, <a href="lwg-defects.html#158">158</a>, <a href="lwg-defects.html#159">159</a>, <a href="lwg-defects.html#160">160</a>, <a href="lwg-defects.html#161">161</a>, <a href="lwg-defects.html#164">164</a>, <a href="lwg-defects.html#168">168</a>, <a href="lwg-defects.html#169">169</a>, <a href="lwg-defects.html#170">170</a>, <a href="lwg-defects.html#172">172</a>, <a href="lwg-defects.html#173">173</a>, <a href="lwg-defects.html#174">174</a>, <a href="lwg-defects.html#175">175</a>, <a href="lwg-defects.html#176">176</a>, <a href="lwg-defects.html#181">181</a>, <a href="lwg-defects.html#189">189</a>, <a href="lwg-defects.html#193">193</a>, <a href="lwg-defects.html#195">195</a>, <a href="lwg-defects.html#199">199</a>, <a href="lwg-defects.html#208">208</a>, <a href="lwg-defects.html#209">209</a>, <a href="lwg-defects.html#210">210</a>, <a href="lwg-defects.html#211">211</a>, <a href="lwg-defects.html#212">212</a>, <a href="lwg-defects.html#217">217</a>, <a href="lwg-defects.html#220">220</a>, <a href="lwg-defects.html#222">222</a>, <a href="lwg-defects.html#223">223</a>, <a href="lwg-defects.html#224">224</a>, <a href="lwg-defects.html#227">227</a>.</li>
</ul></li>
</ul>
</li>
<li>R59: 
2008-08-22 pre-San Francisco mailing.
<ul>
<li><b>Summary:</b><ul>
<li>192 open issues, up by 9.</li>
<li>686 closed issues, up by 0.</li>
<li>878 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#870">870</a>, <a href="lwg-defects.html#871">871</a>, <a href="lwg-defects.html#872">872</a>, <a href="lwg-closed.html#873">873</a>, <a href="lwg-defects.html#874">874</a>, <a href="lwg-defects.html#875">875</a>, <a href="lwg-defects.html#876">876</a>, <a href="lwg-closed.html#877">877</a>, <a href="lwg-defects.html#878">878</a>.</li>
</ul></li>
</ul>
</li>
<li>R58: 
2008-07-28 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>183 open issues, up by 12.</li>
<li>686 closed issues, down by 4.</li>
<li>869 issues total, up by 8.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-closed.html#862">862</a>, <a href="lwg-closed.html#863">863</a>, <a href="lwg-closed.html#864">864</a>, <a href="lwg-defects.html#865">865</a>, <a href="lwg-defects.html#866">866</a>, <a href="lwg-closed.html#867">867</a>, <a href="lwg-defects.html#868">868</a>, <a href="lwg-defects.html#869">869</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#393">393</a>, <a href="lwg-closed.html#557">557</a>, <a href="lwg-closed.html#592">592</a>, <a href="lwg-closed.html#754">754</a>, <a href="lwg-closed.html#757">757</a>.</li>
<li>Changed the following issues from Pending WP to Open: <a href="lwg-closed.html#644">644</a>.</li>
<li>Changed the following issues from WP to Ready: <a href="lwg-defects.html#387">387</a>, <a href="lwg-defects.html#629">629</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to Review: <a href="lwg-defects.html#709">709</a>.</li>
</ul></li>
</ul>
</li>
<li>R57: 
2008-06-27 post-Sophia Antipolis mailing.
<ul>
<li><b>Summary:</b><ul>
<li>171 open issues, down by 20.</li>
<li>690 closed issues, up by 43.</li>
<li>861 issues total, up by 23.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issues: <a href="lwg-closed.html#840">840</a>.</li>
<li>Added the following New issues: <a href="lwg-closed.html#841">841</a>, <a href="lwg-defects.html#843">843</a>, <a href="lwg-defects.html#845">845</a>, <a href="lwg-defects.html#846">846</a>, <a href="lwg-defects.html#847">847</a>, <a href="lwg-closed.html#849">849</a>, <a href="lwg-defects.html#853">853</a>, <a href="lwg-defects.html#854">854</a>, <a href="lwg-closed.html#855">855</a>, <a href="lwg-defects.html#856">856</a>, <a href="lwg-defects.html#857">857</a>, <a href="lwg-defects.html#858">858</a>, <a href="lwg-defects.html#859">859</a>, <a href="lwg-defects.html#860">860</a>, <a href="lwg-defects.html#861">861</a>.</li>
<li>Added the following Open issues: <a href="lwg-closed.html#839">839</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#842">842</a>, <a href="lwg-defects.html#844">844</a>, <a href="lwg-defects.html#848">848</a>, <a href="lwg-defects.html#850">850</a>, <a href="lwg-defects.html#852">852</a>.</li>
<li>Added the following Review issues: <a href="lwg-closed.html#851">851</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#826">826</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#570">570</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#786">786</a>, <a href="lwg-closed.html#831">831</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#756">756</a>, <a href="lwg-defects.html#767">767</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-defects.html#723">723</a>, <a href="lwg-closed.html#726">726</a>, <a href="lwg-defects.html#794">794</a>, <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-closed.html#833">833</a>, <a href="lwg-defects.html#834">834</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#471">471</a>.</li>
<li>Changed the following issues from Review to Open: <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#711">711</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#713">713</a>, <a href="lwg-defects.html#714">714</a>, <a href="lwg-defects.html#769">769</a>, <a href="lwg-defects.html#772">772</a>, <a href="lwg-defects.html#779">779</a>, <a href="lwg-defects.html#787">787</a>, <a href="lwg-defects.html#805">805</a>, <a href="lwg-defects.html#806">806</a>, <a href="lwg-defects.html#807">807</a>, <a href="lwg-defects.html#808">808</a>, <a href="lwg-defects.html#809">809</a>, <a href="lwg-defects.html#813">813</a>, <a href="lwg-defects.html#824">824</a>, <a href="lwg-defects.html#829">829</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#180">180</a>, <a href="lwg-defects.html#396">396</a>, <a href="lwg-defects.html#522">522</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-defects.html#762">762</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#691">691</a>, <a href="lwg-defects.html#728">728</a>, <a href="lwg-defects.html#771">771</a>, <a href="lwg-defects.html#776">776</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#692">692</a>, <a href="lwg-defects.html#698">698</a>, <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#804">804</a>, <a href="lwg-defects.html#823">823</a>, <a href="lwg-defects.html#828">828</a>, <a href="lwg-closed.html#832">832</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#23">23</a>, <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-defects.html#803">803</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="lwg-defects.html#758">758</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#387">387</a>, <a href="lwg-defects.html#518">518</a>, <a href="lwg-defects.html#550">550</a>, <a href="lwg-defects.html#574">574</a>, <a href="lwg-defects.html#595">595</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-defects.html#673">673</a>, <a href="lwg-defects.html#685">685</a>, <a href="lwg-defects.html#710">710</a>, <a href="lwg-defects.html#715">715</a>, <a href="lwg-defects.html#722">722</a>, <a href="lwg-defects.html#740">740</a>, <a href="lwg-defects.html#743">743</a>, <a href="lwg-defects.html#744">744</a>, <a href="lwg-defects.html#746">746</a>, <a href="lwg-defects.html#749">749</a>, <a href="lwg-defects.html#755">755</a>, <a href="lwg-defects.html#759">759</a>, <a href="lwg-defects.html#761">761</a>, <a href="lwg-defects.html#766">766</a>, <a href="lwg-defects.html#768">768</a>, <a href="lwg-defects.html#770">770</a>, <a href="lwg-defects.html#775">775</a>, <a href="lwg-defects.html#777">777</a>, <a href="lwg-defects.html#778">778</a>, <a href="lwg-defects.html#781">781</a>, <a href="lwg-defects.html#782">782</a>, <a href="lwg-defects.html#783">783</a>, <a href="lwg-defects.html#789">789</a>, <a href="lwg-defects.html#792">792</a>, <a href="lwg-defects.html#798">798</a>.</li>
</ul></li>
</ul>
</li>
<li>R56: 
2008-05-16 pre-Sophia Antipolis mailing.
<ul>
<li><b>Summary:</b><ul>
<li>191 open issues, up by 24.</li>
<li>647 closed issues, up by 1.</li>
<li>838 issues total, up by 25.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#814">814</a>, <a href="lwg-defects.html#815">815</a>, <a href="lwg-defects.html#816">816</a>, <a href="lwg-defects.html#817">817</a>, <a href="lwg-defects.html#818">818</a>, <a href="lwg-defects.html#819">819</a>, <a href="lwg-defects.html#820">820</a>, <a href="lwg-defects.html#821">821</a>, <a href="lwg-closed.html#822">822</a>, <a href="lwg-defects.html#823">823</a>, <a href="lwg-defects.html#824">824</a>, <a href="lwg-defects.html#825">825</a>, <a href="lwg-closed.html#826">826</a>, <a href="lwg-defects.html#827">827</a>, <a href="lwg-defects.html#828">828</a>, <a href="lwg-defects.html#829">829</a>, <a href="lwg-closed.html#830">830</a>, <a href="lwg-closed.html#831">831</a>, <a href="lwg-closed.html#832">832</a>, <a href="lwg-closed.html#833">833</a>, <a href="lwg-defects.html#834">834</a>, <a href="lwg-defects.html#835">835</a>, <a href="lwg-defects.html#836">836</a>, <a href="lwg-closed.html#837">837</a>, <a href="lwg-defects.html#838">838</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#802">802</a>.</li>
</ul></li>
</ul>
</li>
<li>R55: 
2008-03-14 post-Bellevue mailing.
<ul>
<li><b>Summary:</b><ul>
<li>167 open issues, down by 39.</li>
<li>646 closed issues, up by 65.</li>
<li>813 issues total, up by 26.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Dup issues: <a href="lwg-closed.html#795">795</a>.</li>
<li>Added the following NAD issues: <a href="lwg-closed.html#790">790</a>, <a href="lwg-closed.html#791">791</a>, <a href="lwg-closed.html#796">796</a>, <a href="lwg-closed.html#797">797</a>, <a href="lwg-closed.html#799">799</a>.</li>
<li>Added the following New issues: <a href="lwg-defects.html#788">788</a>, <a href="lwg-defects.html#794">794</a>, <a href="lwg-closed.html#802">802</a>, <a href="lwg-defects.html#804">804</a>, <a href="lwg-defects.html#805">805</a>, <a href="lwg-defects.html#806">806</a>, <a href="lwg-defects.html#807">807</a>, <a href="lwg-defects.html#808">808</a>, <a href="lwg-defects.html#809">809</a>, <a href="lwg-defects.html#810">810</a>, <a href="lwg-defects.html#811">811</a>, <a href="lwg-closed.html#812">812</a>, <a href="lwg-defects.html#813">813</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#793">793</a>, <a href="lwg-defects.html#800">800</a>, <a href="lwg-defects.html#801">801</a>, <a href="lwg-defects.html#803">803</a>.</li>
<li>Added the following Ready issues: <a href="lwg-defects.html#789">789</a>, <a href="lwg-defects.html#792">792</a>, <a href="lwg-defects.html#798">798</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="lwg-closed.html#116">116</a>.</li>
<li>Changed the following issues from NAD Future to NAD: <a href="lwg-closed.html#188">188</a>, <a href="lwg-closed.html#323">323</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#729">729</a>, <a href="lwg-closed.html#730">730</a>, <a href="lwg-closed.html#731">731</a>, <a href="lwg-closed.html#733">733</a>, <a href="lwg-closed.html#735">735</a>, <a href="lwg-closed.html#736">736</a>, <a href="lwg-closed.html#737">737</a>, <a href="lwg-closed.html#739">739</a>, <a href="lwg-closed.html#741">741</a>, <a href="lwg-closed.html#745">745</a>, <a href="lwg-closed.html#748">748</a>, <a href="lwg-closed.html#763">763</a>, <a href="lwg-closed.html#764">764</a>, <a href="lwg-closed.html#773">773</a>, <a href="lwg-closed.html#784">784</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#388">388</a>, <a href="lwg-closed.html#462">462</a>, <a href="lwg-closed.html#579">579</a>, <a href="lwg-closed.html#627">627</a>, <a href="lwg-closed.html#653">653</a>, <a href="lwg-closed.html#686">686</a>, <a href="lwg-closed.html#707">707</a>.</li>
<li>Changed the following issues from NAD Future to NAD Editorial: <a href="lwg-closed.html#140">140</a>, <a href="lwg-closed.html#390">390</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#529">529</a>, <a href="lwg-closed.html#626">626</a>.</li>
<li>Changed the following issues from Review to NAD Editorial: <a href="lwg-closed.html#645">645</a>, <a href="lwg-closed.html#684">684</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="lwg-closed.html#128">128</a>, <a href="lwg-defects.html#180">180</a>, <a href="lwg-closed.html#190">190</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#617">617</a>, <a href="lwg-closed.html#718">718</a>, <a href="lwg-defects.html#719">719</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-defects.html#724">724</a>, <a href="lwg-defects.html#732">732</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-closed.html#747">747</a>, <a href="lwg-closed.html#750">750</a>, <a href="lwg-defects.html#753">753</a>, <a href="lwg-defects.html#756">756</a>, <a href="lwg-closed.html#760">760</a>, <a href="lwg-defects.html#762">762</a>, <a href="lwg-defects.html#767">767</a>, <a href="lwg-defects.html#774">774</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#688">688</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-defects.html#709">709</a>, <a href="lwg-closed.html#717">717</a>, <a href="lwg-closed.html#725">725</a>, <a href="lwg-closed.html#738">738</a>, <a href="lwg-closed.html#754">754</a>, <a href="lwg-closed.html#757">757</a>.</li>
<li>Changed the following issues from Open to Pending NAD Editorial: <a href="lwg-closed.html#424">424</a>, <a href="lwg-closed.html#557">557</a>, <a href="lwg-defects.html#625">625</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#710">710</a>, <a href="lwg-defects.html#715">715</a>, <a href="lwg-defects.html#722">722</a>, <a href="lwg-defects.html#740">740</a>, <a href="lwg-defects.html#743">743</a>, <a href="lwg-defects.html#744">744</a>, <a href="lwg-defects.html#746">746</a>, <a href="lwg-defects.html#749">749</a>, <a href="lwg-defects.html#755">755</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#759">759</a>, <a href="lwg-defects.html#761">761</a>, <a href="lwg-defects.html#766">766</a>, <a href="lwg-defects.html#768">768</a>, <a href="lwg-defects.html#770">770</a>, <a href="lwg-defects.html#775">775</a>, <a href="lwg-defects.html#777">777</a>, <a href="lwg-defects.html#778">778</a>, <a href="lwg-defects.html#781">781</a>, <a href="lwg-defects.html#782">782</a>, <a href="lwg-defects.html#783">783</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#387">387</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-defects.html#550">550</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#673">673</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#518">518</a>, <a href="lwg-defects.html#574">574</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-defects.html#685">685</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#728">728</a>, <a href="lwg-defects.html#771">771</a>, <a href="lwg-defects.html#776">776</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#539">539</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#561">561</a>, <a href="lwg-defects.html#562">562</a>, <a href="lwg-defects.html#563">563</a>, <a href="lwg-defects.html#567">567</a>, <a href="lwg-defects.html#581">581</a>, <a href="lwg-defects.html#620">620</a>, <a href="lwg-defects.html#621">621</a>, <a href="lwg-defects.html#622">622</a>, <a href="lwg-defects.html#623">623</a>, <a href="lwg-defects.html#624">624</a>, <a href="lwg-defects.html#661">661</a>, <a href="lwg-defects.html#664">664</a>, <a href="lwg-defects.html#665">665</a>, <a href="lwg-defects.html#666">666</a>, <a href="lwg-defects.html#674">674</a>, <a href="lwg-defects.html#679">679</a>, <a href="lwg-defects.html#680">680</a>, <a href="lwg-defects.html#687">687</a>, <a href="lwg-defects.html#689">689</a>, <a href="lwg-defects.html#693">693</a>, <a href="lwg-defects.html#694">694</a>, <a href="lwg-defects.html#695">695</a>, <a href="lwg-defects.html#700">700</a>, <a href="lwg-defects.html#703">703</a>, <a href="lwg-defects.html#705">705</a>, <a href="lwg-defects.html#706">706</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#527">527</a>.</li>
</ul></li>
</ul>
</li>
<li>R54: 
2008-02-01 pre-Bellevue mailing.
<ul>
<li><b>Summary:</b><ul>
<li>206 open issues, up by 23.</li>
<li>581 closed issues, up by 0.</li>
<li>787 issues total, up by 23.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#765">765</a>, <a href="lwg-defects.html#766">766</a>, <a href="lwg-defects.html#767">767</a>, <a href="lwg-defects.html#768">768</a>, <a href="lwg-defects.html#769">769</a>, <a href="lwg-defects.html#770">770</a>, <a href="lwg-defects.html#771">771</a>, <a href="lwg-defects.html#772">772</a>, <a href="lwg-closed.html#773">773</a>, <a href="lwg-defects.html#774">774</a>, <a href="lwg-defects.html#775">775</a>, <a href="lwg-defects.html#776">776</a>, <a href="lwg-defects.html#777">777</a>, <a href="lwg-defects.html#778">778</a>, <a href="lwg-defects.html#779">779</a>, <a href="lwg-defects.html#780">780</a>, <a href="lwg-defects.html#781">781</a>, <a href="lwg-defects.html#782">782</a>, <a href="lwg-defects.html#783">783</a>, <a href="lwg-closed.html#784">784</a>, <a href="lwg-closed.html#785">785</a>, <a href="lwg-defects.html#786">786</a>, <a href="lwg-defects.html#787">787</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="lwg-closed.html#105">105</a>, <a href="lwg-closed.html#348">348</a>.</li>
<li>Changed the following issues from NAD Future to NAD Editorial: <a href="lwg-defects.html#353">353</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-defects.html#697">697</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="lwg-closed.html#388">388</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#527">527</a>.</li>
</ul></li>
</ul>
</li>
<li>R53: 
2007-12-09 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>183 open issues, up by 11.</li>
<li>581 closed issues, down by 1.</li>
<li>764 issues total, up by 10.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#755">755</a>, <a href="lwg-defects.html#756">756</a>, <a href="lwg-closed.html#757">757</a>, <a href="lwg-defects.html#758">758</a>, <a href="lwg-defects.html#759">759</a>, <a href="lwg-closed.html#760">760</a>, <a href="lwg-defects.html#761">761</a>, <a href="lwg-defects.html#762">762</a>, <a href="lwg-closed.html#763">763</a>, <a href="lwg-closed.html#764">764</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="lwg-closed.html#463">463</a>.</li>
<li>Changed the following issues from Pending WP to WP: <a href="lwg-defects.html#607">607</a>, <a href="lwg-defects.html#608">608</a>, <a href="lwg-defects.html#654">654</a>, <a href="lwg-defects.html#655">655</a>, <a href="lwg-defects.html#677">677</a>, <a href="lwg-defects.html#682">682</a>.</li>
</ul></li>
</ul>
</li>
<li>R52: 
2007-10-19 post-Kona mailing.
<ul>
<li><b>Summary:</b><ul>
<li>172 open issues, up by 4.</li>
<li>582 closed issues, up by 27.</li>
<li>754 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#724">724</a>, <a href="lwg-closed.html#725">725</a>, <a href="lwg-closed.html#726">726</a>, <a href="lwg-defects.html#727">727</a>, <a href="lwg-defects.html#728">728</a>, <a href="lwg-closed.html#729">729</a>, <a href="lwg-closed.html#730">730</a>, <a href="lwg-closed.html#731">731</a>, <a href="lwg-defects.html#732">732</a>, <a href="lwg-closed.html#733">733</a>, <a href="lwg-defects.html#734">734</a>, <a href="lwg-closed.html#735">735</a>, <a href="lwg-closed.html#736">736</a>, <a href="lwg-closed.html#737">737</a>, <a href="lwg-closed.html#738">738</a>, <a href="lwg-closed.html#739">739</a>, <a href="lwg-defects.html#740">740</a>, <a href="lwg-closed.html#741">741</a>, <a href="lwg-defects.html#742">742</a>, <a href="lwg-defects.html#743">743</a>, <a href="lwg-defects.html#744">744</a>, <a href="lwg-closed.html#745">745</a>, <a href="lwg-defects.html#746">746</a>, <a href="lwg-closed.html#747">747</a>, <a href="lwg-closed.html#748">748</a>, <a href="lwg-defects.html#749">749</a>, <a href="lwg-closed.html#750">750</a>, <a href="lwg-closed.html#751">751</a>, <a href="lwg-defects.html#752">752</a>, <a href="lwg-defects.html#753">753</a>, <a href="lwg-closed.html#754">754</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="lwg-closed.html#77">77</a>, <a href="lwg-closed.html#350">350</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#639">639</a>, <a href="lwg-closed.html#657">657</a>, <a href="lwg-closed.html#663">663</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#548">548</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#546">546</a>, <a href="lwg-defects.html#550">550</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-closed.html#573">573</a>, <a href="lwg-closed.html#585">585</a>, <a href="lwg-closed.html#588">588</a>, <a href="lwg-closed.html#627">627</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-closed.html#632">632</a>, <a href="lwg-defects.html#635">635</a>, <a href="lwg-closed.html#653">653</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-closed.html#667">667</a>, <a href="lwg-closed.html#668">668</a>, <a href="lwg-closed.html#669">669</a>, <a href="lwg-closed.html#670">670</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#673">673</a>, <a href="lwg-closed.html#686">686</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-closed.html#707">707</a>, <a href="lwg-closed.html#708">708</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-closed.html#393">393</a>, <a href="lwg-closed.html#592">592</a>.</li>
<li>Changed the following issues from New to Pending WP: <a href="lwg-defects.html#607">607</a>, <a href="lwg-defects.html#608">608</a>, <a href="lwg-defects.html#654">654</a>, <a href="lwg-defects.html#655">655</a>, <a href="lwg-defects.html#677">677</a>, <a href="lwg-defects.html#682">682</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#561">561</a>, <a href="lwg-defects.html#562">562</a>, <a href="lwg-defects.html#563">563</a>, <a href="lwg-defects.html#567">567</a>, <a href="lwg-defects.html#581">581</a>, <a href="lwg-defects.html#595">595</a>, <a href="lwg-defects.html#620">620</a>, <a href="lwg-defects.html#621">621</a>, <a href="lwg-defects.html#622">622</a>, <a href="lwg-defects.html#623">623</a>, <a href="lwg-defects.html#624">624</a>, <a href="lwg-defects.html#661">661</a>, <a href="lwg-defects.html#664">664</a>, <a href="lwg-defects.html#665">665</a>, <a href="lwg-defects.html#666">666</a>, <a href="lwg-defects.html#674">674</a>, <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#676">676</a>, <a href="lwg-defects.html#679">679</a>, <a href="lwg-defects.html#687">687</a>, <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#689">689</a>, <a href="lwg-defects.html#693">693</a>, <a href="lwg-defects.html#694">694</a>, <a href="lwg-defects.html#695">695</a>, <a href="lwg-defects.html#700">700</a>, <a href="lwg-defects.html#703">703</a>, <a href="lwg-defects.html#705">705</a>, <a href="lwg-defects.html#706">706</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#680">680</a>.</li>
<li>Changed the following issues from New to Review: <a href="lwg-defects.html#574">574</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-closed.html#645">645</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-closed.html#684">684</a>, <a href="lwg-defects.html#685">685</a>, <a href="lwg-defects.html#691">691</a>.</li>
<li>Changed the following issues from New to WP: <a href="lwg-defects.html#552">552</a>, <a href="lwg-defects.html#634">634</a>, <a href="lwg-defects.html#650">650</a>, <a href="lwg-defects.html#651">651</a>, <a href="lwg-defects.html#652">652</a>, <a href="lwg-defects.html#678">678</a>, <a href="lwg-defects.html#681">681</a>, <a href="lwg-defects.html#699">699</a>, <a href="lwg-defects.html#712">712</a>.</li>
<li>Changed the following issues from Open to WP: <a href="lwg-defects.html#258">258</a>, <a href="lwg-defects.html#401">401</a>, <a href="lwg-defects.html#524">524</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#488">488</a>, <a href="lwg-defects.html#577">577</a>, <a href="lwg-defects.html#660">660</a>.</li>
</ul></li>
</ul>
</li>
<li>R51: 
2007-09-09 pre-Kona mailing.
<ul>
<li><b>Summary:</b><ul>
<li>168 open issues, up by 15.</li>
<li>555 closed issues, up by 0.</li>
<li>723 issues total, up by 15.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#709">709</a>, <a href="lwg-defects.html#710">710</a>, <a href="lwg-defects.html#711">711</a>, <a href="lwg-defects.html#712">712</a>, <a href="lwg-defects.html#713">713</a>, <a href="lwg-defects.html#714">714</a>, <a href="lwg-defects.html#715">715</a>, <a href="lwg-defects.html#716">716</a>, <a href="lwg-closed.html#717">717</a>, <a href="lwg-closed.html#718">718</a>, <a href="lwg-defects.html#719">719</a>, <a href="lwg-defects.html#720">720</a>, <a href="lwg-closed.html#721">721</a>, <a href="lwg-defects.html#722">722</a>, <a href="lwg-defects.html#723">723</a>.</li>
</ul></li>
</ul>
</li>
<li>R50: 
2007-08-05 post-Toronto mailing.
<ul>
<li><b>Summary:</b><ul>
<li>153 open issues, down by 5.</li>
<li>555 closed issues, up by 17.</li>
<li>708 issues total, up by 12.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#697">697</a>, <a href="lwg-defects.html#698">698</a>, <a href="lwg-defects.html#699">699</a>, <a href="lwg-defects.html#700">700</a>, <a href="lwg-closed.html#701">701</a>, <a href="lwg-closed.html#702">702</a>, <a href="lwg-defects.html#703">703</a>, <a href="lwg-defects.html#704">704</a>, <a href="lwg-defects.html#705">705</a>, <a href="lwg-defects.html#706">706</a>, <a href="lwg-closed.html#707">707</a>, <a href="lwg-closed.html#708">708</a>.</li>
<li>Changed the following issues from New to NAD: <a href="lwg-closed.html#583">583</a>, <a href="lwg-closed.html#584">584</a>, <a href="lwg-closed.html#662">662</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="lwg-closed.html#528">528</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-closed.html#637">637</a>, <a href="lwg-closed.html#647">647</a>, <a href="lwg-defects.html#658">658</a>, <a href="lwg-closed.html#690">690</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-defects.html#525">525</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="lwg-closed.html#553">553</a>, <a href="lwg-closed.html#571">571</a>, <a href="lwg-closed.html#591">591</a>, <a href="lwg-closed.html#633">633</a>, <a href="lwg-closed.html#636">636</a>, <a href="lwg-closed.html#641">641</a>, <a href="lwg-closed.html#642">642</a>, <a href="lwg-closed.html#648">648</a>, <a href="lwg-closed.html#649">649</a>, <a href="lwg-closed.html#656">656</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#579">579</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-defects.html#680">680</a>.</li>
<li>Changed the following issues from Pending WP to Open: <a href="lwg-defects.html#258">258</a>.</li>
<li>Changed the following issues from Ready to Pending WP: <a href="lwg-closed.html#644">644</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#577">577</a>, <a href="lwg-defects.html#660">660</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="lwg-defects.html#488">488</a>.</li>
<li>Changed the following issues from Open to Review: <a href="lwg-defects.html#518">518</a>.</li>
<li>Changed the following issues from Ready to TRDec: <a href="lwg-defects.html#604">604</a>.</li>
<li>Changed the following issues from DR to WP: <a href="lwg-defects.html#453">453</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#566">566</a>, <a href="lwg-defects.html#628">628</a>, <a href="lwg-defects.html#640">640</a>, <a href="lwg-defects.html#643">643</a>, <a href="lwg-defects.html#646">646</a>.</li>
</ul></li>
</ul>
</li>
<li>R49: 
2007-06-23 pre-Toronto mailing.
<ul>
<li><b>Summary:</b><ul>
<li>158 open issues, up by 13.</li>
<li>538 closed issues, up by 7.</li>
<li>696 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#677">677</a>, <a href="lwg-defects.html#678">678</a>, <a href="lwg-defects.html#679">679</a>, <a href="lwg-defects.html#680">680</a>, <a href="lwg-defects.html#681">681</a>, <a href="lwg-defects.html#682">682</a>, <a href="lwg-closed.html#684">684</a>, <a href="lwg-defects.html#685">685</a>, <a href="lwg-closed.html#686">686</a>, <a href="lwg-defects.html#687">687</a>, <a href="lwg-defects.html#688">688</a>, <a href="lwg-defects.html#689">689</a>, <a href="lwg-closed.html#690">690</a>, <a href="lwg-defects.html#691">691</a>, <a href="lwg-defects.html#692">692</a>, <a href="lwg-defects.html#693">693</a>, <a href="lwg-defects.html#694">694</a>, <a href="lwg-defects.html#695">695</a>, <a href="lwg-defects.html#696">696</a>.</li>
<li>Added the following Pending NAD Editorial issues: <a href="lwg-closed.html#683">683</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="lwg-closed.html#587">587</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="lwg-closed.html#590">590</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-closed.html#636">636</a>, <a href="lwg-closed.html#642">642</a>, <a href="lwg-closed.html#648">648</a>, <a href="lwg-closed.html#649">649</a>.</li>
</ul></li>
</ul>
</li>
<li>R48: 
2007-05-06 post-Oxford mailing.
<ul>
<li><b>Summary:</b><ul>
<li>145 open issues, down by 33.</li>
<li>531 closed issues, up by 53.</li>
<li>676 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-closed.html#657">657</a>, <a href="lwg-defects.html#658">658</a>, <a href="lwg-defects.html#659">659</a>, <a href="lwg-defects.html#660">660</a>, <a href="lwg-defects.html#661">661</a>, <a href="lwg-closed.html#662">662</a>, <a href="lwg-closed.html#663">663</a>, <a href="lwg-defects.html#664">664</a>, <a href="lwg-defects.html#665">665</a>, <a href="lwg-defects.html#666">666</a>, <a href="lwg-closed.html#667">667</a>, <a href="lwg-closed.html#668">668</a>, <a href="lwg-closed.html#669">669</a>, <a href="lwg-closed.html#670">670</a>, <a href="lwg-defects.html#671">671</a>, <a href="lwg-defects.html#672">672</a>, <a href="lwg-defects.html#673">673</a>, <a href="lwg-defects.html#674">674</a>, <a href="lwg-defects.html#675">675</a>, <a href="lwg-defects.html#676">676</a>.</li>
<li>Changed the following issues from Tentatively Ready to Dup: <a href="lwg-closed.html#479">479</a>, <a href="lwg-closed.html#536">536</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD: <a href="lwg-closed.html#385">385</a>, <a href="lwg-closed.html#463">463</a>, <a href="lwg-closed.html#466">466</a>, <a href="lwg-closed.html#470">470</a>, <a href="lwg-closed.html#515">515</a>, <a href="lwg-closed.html#526">526</a>, <a href="lwg-closed.html#547">547</a>, <a href="lwg-closed.html#560">560</a>, <a href="lwg-closed.html#572">572</a>.</li>
<li>Changed the following issues from NAD to NAD Editorial: <a href="lwg-closed.html#351">351</a>, <a href="lwg-closed.html#357">357</a>, <a href="lwg-closed.html#368">368</a>, <a href="lwg-closed.html#499">499</a>, <a href="lwg-closed.html#504">504</a>, <a href="lwg-closed.html#512">512</a>, <a href="lwg-closed.html#513">513</a>, <a href="lwg-closed.html#514">514</a>, <a href="lwg-closed.html#516">516</a>, <a href="lwg-closed.html#544">544</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-closed.html#555">555</a>, <a href="lwg-closed.html#558">558</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="lwg-defects.html#482">482</a>, <a href="lwg-closed.html#615">615</a>.</li>
<li>Changed the following issues from NAD_Future to NAD Future: <a href="lwg-closed.html#77">77</a>, <a href="lwg-closed.html#105">105</a>, <a href="lwg-closed.html#111">111</a>, <a href="lwg-closed.html#116">116</a>, <a href="lwg-closed.html#128">128</a>, <a href="lwg-closed.html#138">138</a>, <a href="lwg-closed.html#140">140</a>, <a href="lwg-defects.html#149">149</a>, <a href="lwg-defects.html#180">180</a>, <a href="lwg-closed.html#188">188</a>, <a href="lwg-closed.html#190">190</a>, <a href="lwg-closed.html#219">219</a>, <a href="lwg-closed.html#323">323</a>, <a href="lwg-closed.html#348">348</a>, <a href="lwg-closed.html#350">350</a>, <a href="lwg-defects.html#353">353</a>, <a href="lwg-closed.html#388">388</a>, <a href="lwg-closed.html#390">390</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="lwg-defects.html#471">471</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="lwg-closed.html#633">633</a>, <a href="lwg-closed.html#641">641</a>, <a href="lwg-closed.html#656">656</a>.</li>
<li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="lwg-closed.html#532">532</a>, <a href="lwg-closed.html#553">553</a>, <a href="lwg-closed.html#571">571</a>, <a href="lwg-closed.html#591">591</a>, <a href="lwg-defects.html#594">594</a>.</li>
<li>Changed the following issues from Tentatively Ready to Pending WP: <a href="lwg-defects.html#258">258</a>.</li>
<li>Changed the following issues from New to Ready: <a href="lwg-defects.html#566">566</a>, <a href="lwg-defects.html#628">628</a>, <a href="lwg-defects.html#640">640</a>, <a href="lwg-defects.html#643">643</a>, <a href="lwg-closed.html#644">644</a>, <a href="lwg-defects.html#646">646</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#604">604</a>.</li>
<li>Changed the following issues from Ready to TRDec: <a href="lwg-defects.html#598">598</a>, <a href="lwg-defects.html#599">599</a>, <a href="lwg-defects.html#600">600</a>, <a href="lwg-defects.html#601">601</a>, <a href="lwg-defects.html#602">602</a>, <a href="lwg-defects.html#603">603</a>, <a href="lwg-defects.html#605">605</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="lwg-defects.html#543">543</a>, <a href="lwg-defects.html#545">545</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="lwg-defects.html#201">201</a>, <a href="lwg-defects.html#206">206</a>, <a href="lwg-defects.html#233">233</a>, <a href="lwg-defects.html#254">254</a>, <a href="lwg-defects.html#416">416</a>, <a href="lwg-defects.html#422">422</a>, <a href="lwg-defects.html#456">456</a>, <a href="lwg-defects.html#534">534</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#559">559</a>, <a href="lwg-defects.html#575">575</a>, <a href="lwg-defects.html#576">576</a>, <a href="lwg-defects.html#578">578</a>, <a href="lwg-defects.html#586">586</a>, <a href="lwg-defects.html#589">589</a>, <a href="lwg-defects.html#593">593</a>, <a href="lwg-defects.html#609">609</a>, <a href="lwg-defects.html#610">610</a>, <a href="lwg-defects.html#611">611</a>, <a href="lwg-defects.html#613">613</a>, <a href="lwg-defects.html#616">616</a>, <a href="lwg-defects.html#619">619</a>.</li>
</ul></li>
</ul>
</li>
<li>R47: 
2007-03-09 pre-Oxford mailing.
<ul>
<li><b>Summary:</b><ul>
<li>178 open issues, up by 37.</li>
<li>478 closed issues, up by 0.</li>
<li>656 issues total, up by 37.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="lwg-defects.html#620">620</a>, <a href="lwg-defects.html#621">621</a>, <a href="lwg-defects.html#622">622</a>, <a href="lwg-defects.html#623">623</a>, <a href="lwg-defects.html#624">624</a>, <a href="lwg-closed.html#627">627</a>, <a href="lwg-defects.html#628">628</a>, <a href="lwg-defects.html#629">629</a>, <a href="lwg-defects.html#630">630</a>, <a href="lwg-closed.html#631">631</a>, <a href="lwg-closed.html#632">632</a>, <a href="lwg-closed.html#633">633</a>, <a href="lwg-defects.html#634">634</a>, <a href="lwg-defects.html#635">635</a>, <a href="lwg-closed.html#636">636</a>, <a href="lwg-closed.html#637">637</a>, <a href="lwg-defects.html#638">638</a>, <a href="lwg-closed.html#639">639</a>, <a href="lwg-defects.html#640">640</a>, <a href="lwg-closed.html#641">641</a>, <a href="lwg-closed.html#642">642</a>, <a href="lwg-defects.html#643">643</a>, <a href="lwg-closed.html#644">644</a>, <a href="lwg-closed.html#645">645</a>, <a href="lwg-defects.html#646">646</a>, <a href="lwg-closed.html#647">647</a>, <a href="lwg-closed.html#648">648</a>, <a href="lwg-closed.html#649">649</a>, <a href="lwg-defects.html#650">650</a>, <a href="lwg-defects.html#651">651</a>, <a href="lwg-defects.html#652">652</a>, <a href="lwg-closed.html#653">653</a>, <a href="lwg-defects.html#654">654</a>, <a href="lwg-defects.html#655">655</a>, <a href="lwg-closed.html#656">656</a>.</li>
<li>Added the following Open issues: <a href="lwg-defects.html#625">625</a>, <a href="lwg-closed.html#626">626</a>.</li>
<li>Changed the following issues from New to Open: <a href="lwg-closed.html#570">570</a>, <a href="lwg-closed.html#580">580</a>, <a href="lwg-closed.html#582">582</a>, <a href="lwg-closed.html#590">590</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-closed.html#614">614</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="lwg-closed.html#547">547</a>, <a href="lwg-closed.html#553">553</a>, <a href="lwg-closed.html#560">560</a>, <a href="lwg-closed.html#571">571</a>, <a href="lwg-closed.html#572">572</a>, <a href="lwg-defects.html#575">575</a>, <a href="lwg-defects.html#576">576</a>, <a href="lwg-defects.html#578">578</a>, <a href="lwg-defects.html#586">586</a>, <a href="lwg-defects.html#589">589</a>, <a href="lwg-closed.html#591">591</a>, <a href="lwg-defects.html#593">593</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-defects.html#609">609</a>, <a href="lwg-defects.html#610">610</a>, <a href="lwg-defects.html#611">611</a>, <a href="lwg-defects.html#613">613</a>, <a href="lwg-closed.html#615">615</a>, <a href="lwg-defects.html#616">616</a>, <a href="lwg-defects.html#619">619</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="lwg-defects.html#201">201</a>, <a href="lwg-defects.html#206">206</a>, <a href="lwg-defects.html#233">233</a>, <a href="lwg-defects.html#254">254</a>, <a href="lwg-defects.html#258">258</a>, <a href="lwg-closed.html#385">385</a>, <a href="lwg-defects.html#416">416</a>, <a href="lwg-defects.html#422">422</a>, <a href="lwg-defects.html#456">456</a>, <a href="lwg-closed.html#463">463</a>, <a href="lwg-closed.html#466">466</a>, <a href="lwg-closed.html#470">470</a>, <a href="lwg-defects.html#471">471</a>, <a href="lwg-closed.html#479">479</a>, <a href="lwg-defects.html#482">482</a>, <a href="lwg-closed.html#515">515</a>, <a href="lwg-closed.html#526">526</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-closed.html#536">536</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#559">559</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="lwg-defects.html#534">534</a>.</li>
</ul></li>
</ul>
</li>
<li>R46: 
2007-01-12 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>141 open issues, up by 11.</li>
<li>478 closed issues, down by 1.</li>
<li>619 issues total, up by 10.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-defects.html#610">610</a>, <a href="lwg-defects.html#611">611</a>, <a href="lwg-defects.html#612">612</a>, <a href="lwg-defects.html#613">613</a>, <a href="lwg-closed.html#614">614</a>, <a href="lwg-closed.html#615">615</a>, <a href="lwg-defects.html#616">616</a>, <a href="lwg-closed.html#617">617</a>, <a href="lwg-defects.html#618">618</a>, <a href="lwg-defects.html#619">619</a>.</li>
</ul></li>
</ul>
</li>
<li>R45: 
2006-11-03 post-Portland mailing.
<ul>
<li><b>Summary:</b><ul>
<li>130 open issues, up by 0.</li>
<li>479 closed issues, up by 17.</li>
<li>609 issues total, up by 17.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Moved issues <a href="lwg-defects.html#520">520</a>, <a href="lwg-defects.html#521">521</a>, <a href="lwg-defects.html#530">530</a>, <a href="lwg-defects.html#535">535</a>, <a href="lwg-defects.html#537">537</a>, <a href="lwg-defects.html#538">538</a>, <a href="lwg-defects.html#540">540</a>, <a href="lwg-defects.html#541">541</a> to WP.</li>
<li>Moved issues <a href="lwg-closed.html#504">504</a>, <a href="lwg-closed.html#512">512</a>, <a href="lwg-closed.html#516">516</a>, <a href="lwg-closed.html#544">544</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-closed.html#554">554</a>, <a href="lwg-closed.html#555">555</a>, <a href="lwg-closed.html#558">558</a> to NAD.</li>
<li>Moved issue <a href="lwg-closed.html#569">569</a> to Dup.</li>
<li>Moved issues <a href="lwg-defects.html#518">518</a>, <a href="lwg-closed.html#523">523</a>, <a href="lwg-defects.html#524">524</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-closed.html#557">557</a>, <a href="lwg-defects.html#559">559</a>, <a href="lwg-closed.html#597">597</a>, <a href="lwg-closed.html#606">606</a> to Open.</li>
<li>Moved issues <a href="lwg-defects.html#543">543</a>, <a href="lwg-defects.html#545">545</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-defects.html#598">598</a> - <a href="lwg-defects.html#603">603</a>, <a href="lwg-defects.html#605">605</a> to Ready.</li>
<li>Moved issues <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#604">604</a> to Review.</li>
<li>Added new issues <a href="lwg-defects.html#593">593</a>, <a href="lwg-defects.html#594">594</a>, <a href="lwg-defects.html#595">595</a>, <a href="lwg-defects.html#596">596</a>, <a href="lwg-closed.html#597">597</a>, <a href="lwg-defects.html#598">598</a>, <a href="lwg-defects.html#599">599</a>, <a href="lwg-defects.html#600">600</a>, <a href="lwg-defects.html#601">601</a>, <a href="lwg-defects.html#602">602</a>, <a href="lwg-defects.html#603">603</a>, <a href="lwg-defects.html#604">604</a>, <a href="lwg-defects.html#605">605</a>, <a href="lwg-closed.html#606">606</a>, <a href="lwg-defects.html#607">607</a>, <a href="lwg-defects.html#608">608</a>, <a href="lwg-defects.html#609">609</a>.</li>
</ul></li>
</ul>
</li>
<li>R44: 
2006-09-08 pre-Portland mailing.
<ul>
<li><b>Summary:</b><ul>
<li>130 open issues, up by 6.</li>
<li>462 closed issues, down by 1.</li>
<li>592 issues total, up by 5.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-closed.html#583">583</a>, <a href="lwg-closed.html#584">584</a>, <a href="lwg-closed.html#585">585</a>, <a href="lwg-defects.html#586">586</a>, <a href="lwg-closed.html#587">587</a>, <a href="lwg-closed.html#588">588</a>, <a href="lwg-defects.html#589">589</a>, <a href="lwg-closed.html#590">590</a>, <a href="lwg-closed.html#591">591</a>, <a href="lwg-closed.html#592">592</a>.</li>
</ul></li>
</ul>
</li>
<li>R43: 
2006-06-23 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>124 open issues, up by 14.</li>
<li>463 closed issues, down by 1.</li>
<li>587 issues total, up by 13.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-defects.html#575">575</a>, <a href="lwg-defects.html#576">576</a>, <a href="lwg-defects.html#577">577</a>, <a href="lwg-defects.html#578">578</a>, <a href="lwg-closed.html#579">579</a>, <a href="lwg-closed.html#580">580</a>, <a href="lwg-defects.html#581">581</a>, <a href="lwg-closed.html#582">582</a>.</li>
<li>Reopened <a href="lwg-closed.html#255">255</a>.</li>
<li>Moved issues <a href="lwg-defects.html#520">520</a>, <a href="lwg-defects.html#541">541</a>, <a href="lwg-closed.html#544">544</a>, <a href="lwg-closed.html#569">569</a> to Tentatively Ready.</li>
</ul></li>
</ul>
</li>
<li>R42: 
2006-04-21 post-Berlin mailing.
<ul>
<li><b>Summary:</b><ul>
<li>110 open issues, down by 16.</li>
<li>464 closed issues, up by 24.</li>
<li>574 issues total, up by 8.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-defects.html#567">567</a>, <a href="lwg-closed.html#568">568</a>, <a href="lwg-closed.html#569">569</a>, <a href="lwg-closed.html#570">570</a>, <a href="lwg-closed.html#571">571</a>, <a href="lwg-closed.html#572">572</a>.</li>
<li>Moved issues <a href="lwg-closed.html#499">499</a>, <a href="lwg-closed.html#501">501</a>, <a href="lwg-closed.html#506">506</a>, <a href="lwg-closed.html#509">509</a>, <a href="lwg-closed.html#510">510</a>, <a href="lwg-closed.html#511">511</a>, <a href="lwg-closed.html#513">513</a>, <a href="lwg-closed.html#514">514</a>, <a href="lwg-closed.html#517">517</a> to NAD.</li>
<li>Moved issues <a href="lwg-closed.html#502">502</a>, <a href="lwg-closed.html#503">503</a>, <a href="lwg-closed.html#515">515</a>, <a href="lwg-closed.html#516">516</a>, <a href="lwg-defects.html#522">522</a>, <a href="lwg-defects.html#525">525</a>, <a href="lwg-closed.html#526">526</a>, <a href="lwg-defects.html#527">527</a>, <a href="lwg-closed.html#528">528</a>, <a href="lwg-closed.html#529">529</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-closed.html#536">536</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-closed.html#548">548</a> to Open.</li>
<li>Moved issue <a href="lwg-closed.html#504">504</a>, <a href="lwg-closed.html#512">512</a>, <a href="lwg-defects.html#521">521</a>, <a href="lwg-defects.html#530">530</a>, <a href="lwg-defects.html#531">531</a>, <a href="lwg-defects.html#535">535</a>, <a href="lwg-defects.html#537">537</a>, <a href="lwg-defects.html#538">538</a>, <a href="lwg-defects.html#540">540</a>, <a href="lwg-closed.html#549">549</a> to Ready.</li>
<li>Moved issues <a href="lwg-defects.html#247">247</a>, <a href="lwg-defects.html#294">294</a>, <a href="lwg-defects.html#362">362</a>, <a href="lwg-defects.html#369">369</a>, <a href="lwg-defects.html#371">371</a>, <a href="lwg-defects.html#376">376</a>, <a href="lwg-defects.html#384">384</a>, <a href="lwg-defects.html#475">475</a>, <a href="lwg-defects.html#478">478</a>, <a href="lwg-defects.html#495">495</a>, <a href="lwg-defects.html#497">497</a>, <a href="lwg-defects.html#505">505</a>, <a href="lwg-defects.html#507">507</a>, <a href="lwg-defects.html#508">508</a>, <a href="lwg-defects.html#519">519</a> to WP.</li>
<li>Moved issue <a href="lwg-defects.html#534">534</a> to Review.</li>
</ul></li>
</ul>
</li>
<li>R41: 
2006-02-24 pre-Berlin mailing.
<ul>
<li><b>Summary:</b><ul>
<li>126 open issues, up by 31.</li>
<li>440 closed issues, up by 0.</li>
<li>566 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-closed.html#536">536</a>, <a href="lwg-defects.html#537">537</a>, <a href="lwg-defects.html#538">538</a>, <a href="lwg-defects.html#539">539</a>, <a href="lwg-defects.html#540">540</a>, <a href="lwg-defects.html#541">541</a>, <a href="lwg-defects.html#542">542</a>, <a href="lwg-defects.html#543">543</a>, <a href="lwg-closed.html#544">544</a>, <a href="lwg-defects.html#545">545</a>, <a href="lwg-closed.html#546">546</a>, <a href="lwg-closed.html#547">547</a>, <a href="lwg-closed.html#548">548</a>, <a href="lwg-closed.html#549">549</a>, <a href="lwg-defects.html#550">550</a> ,<a href="lwg-defects.html#551">551</a>, <a href="lwg-defects.html#552">552</a>, <a href="lwg-closed.html#553">553</a>, <a href="lwg-closed.html#554">554</a>, <a href="lwg-closed.html#555">555</a>, <a href="lwg-defects.html#556">556</a>, <a href="lwg-closed.html#557">557</a>, <a href="lwg-closed.html#558">558</a>, <a href="lwg-defects.html#559">559</a>, <a href="lwg-closed.html#560">560</a>, <a href="lwg-defects.html#561">561</a>, <a href="lwg-defects.html#562">562</a>, <a href="lwg-defects.html#563">563</a>, <a href="lwg-defects.html#564">564</a>, <a href="lwg-defects.html#565">565</a>, <a href="lwg-defects.html#566">566</a>.</li>
<li>Moved <a href="lwg-closed.html#342">342</a> from Ready to Open.</li>
<li>Reopened <a href="lwg-closed.html#309">309</a>.</li>
</ul></li>
</ul>
</li>
<li>R40: 
2005-12-16 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>95 open issues.</li>
<li>440 closed issues.</li>
<li>535 issues total.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="lwg-closed.html#529">529</a>, <a href="lwg-defects.html#530">530</a>, <a href="lwg-defects.html#531">531</a>, <a href="lwg-closed.html#532">532</a>, <a href="lwg-defects.html#533">533</a>, <a href="lwg-defects.html#534">534</a>, <a href="lwg-defects.html#535">535</a>.</li>
</ul></li>
</ul>
</li>
<li>R39: 
2005-10-14 post-Mont Tremblant mailing.
Added new issues <a href="lwg-closed.html#526">526</a>-<a href="lwg-closed.html#528">528</a>.
Moved issues <a href="lwg-defects.html#280">280</a>, <a href="lwg-defects.html#461">461</a>, <a href="lwg-defects.html#464">464</a>, <a href="lwg-defects.html#465">465</a>, <a href="lwg-defects.html#467">467</a>, <a href="lwg-defects.html#468">468</a>, <a href="lwg-defects.html#474">474</a>, <a href="lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
Moved issues <a href="lwg-defects.html#247">247</a>, <a href="lwg-defects.html#294">294</a>, <a href="lwg-closed.html#342">342</a>, <a href="lwg-defects.html#362">362</a>, <a href="lwg-defects.html#369">369</a>, <a href="lwg-defects.html#371">371</a>, <a href="lwg-defects.html#376">376</a>, <a href="lwg-defects.html#384">384</a>, <a href="lwg-defects.html#475">475</a>, <a href="lwg-defects.html#478">478</a>, <a href="lwg-defects.html#495">495</a>, <a href="lwg-defects.html#497">497</a> from Review to Ready.
Moved issues <a href="lwg-defects.html#498">498</a>, <a href="lwg-closed.html#504">504</a>, <a href="lwg-closed.html#506">506</a>, <a href="lwg-closed.html#509">509</a>, <a href="lwg-closed.html#510">510</a>, <a href="lwg-closed.html#511">511</a>, <a href="lwg-closed.html#512">512</a>, <a href="lwg-closed.html#513">513</a>, <a href="lwg-closed.html#514">514</a> from New to Open.
Moved issues <a href="lwg-defects.html#505">505</a>, <a href="lwg-defects.html#507">507</a>, <a href="lwg-defects.html#508">508</a>, <a href="lwg-defects.html#519">519</a> from New to Ready.
Moved issue <a href="lwg-closed.html#500">500</a> from New to NAD.
Moved issue <a href="lwg-defects.html#518">518</a> from New to Review.
</li>
<li>R38: 
2005-07-03 pre-Mont Tremblant mailing.
Merged open TR1 issues in <a href="lwg-closed.html#504">504</a>-<a href="lwg-defects.html#522">522</a>.
Added new issues <a href="lwg-closed.html#523">523</a>-<a href="lwg-closed.html#523">523</a>
</li>
<li>R37: 
2005-06 mid-term mailing.
Added new issues <a href="lwg-defects.html#498">498</a>-<a href="lwg-closed.html#503">503</a>.
</li>
<li>R36: 
2005-04 post-Lillehammer mailing. All issues in "ready" status except
for <a href="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: 
2005-03 pre-Lillehammer mailing.
</li>
<li>R34: 
2005-01 mid-term mailing.  Added new issues <a href="lwg-defects.html#488">488</a>-<a href="lwg-closed.html#494">494</a>.
</li>
<li>R33: 
2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
</li>
<li>R32: 
2004-09 pre-Redmond mailing: reflects new proposed resolutions and
new issues received after the 2004-07 mailing.  Added
new issues <a href="lwg-closed.html#479">479</a>-<a href="lwg-closed.html#481">481</a>.
</li>
<li>R31: 
2004-07 mid-term mailing: reflects new proposed resolutions and
new issues received after the post-Sydney mailing.  Added
new issues <a href="lwg-closed.html#463">463</a>-<a href="lwg-defects.html#478">478</a>.
</li>
<li>R30: 
Post-Sydney mailing: reflects decisions made at the Sydney meeting.
Voted all "Ready" issues from R29 into the working paper.
Added new issues <a href="lwg-defects.html#460">460</a>-<a href="lwg-closed.html#462">462</a>.
</li>
<li>R29: 
Pre-Sydney mailing.  Added new issues <a href="lwg-defects.html#441">441</a>-<a href="lwg-defects.html#457">457</a>.
</li>
<li>R28: 
Post-Kona mailing: reflects decisions made at the Kona meeting.
Added new issues <a href="lwg-defects.html#432">432</a>-<a href="lwg-closed.html#440">440</a>.
</li>
<li>R27: 
Pre-Kona mailing.  Added new issues <a href="lwg-defects.html#404">404</a>-<a href="lwg-defects.html#431">431</a>.
</li>
<li>R26: 
Post-Oxford mailing: reflects decisions made at the Oxford meeting.
All issues in Ready status were voted into DR status.  All issues in
DR status were voted into WP status.
</li>
<li>R25: 
Pre-Oxford mailing.  Added new issues <a href="lwg-closed.html#390">390</a>-<a href="lwg-defects.html#402">402</a>.
</li>
<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="lwg-defects.html#253">253</a>, 
which has been given a new proposed resolution, were
moved to DR status.  Added new issues <a href="lwg-defects.html#383">383</a>-<a href="lwg-defects.html#389">389</a>.  
(Issues <a href="lwg-defects.html#387">387</a>-<a href="lwg-defects.html#389">389</a> were discussed
at the meeting.)  Made progress on issues <a href="lwg-defects.html#225">225</a>, <a href="lwg-defects.html#226">226</a>, 
<a href="lwg-defects.html#229">229</a>: <a href="lwg-defects.html#225">225</a> and <a href="lwg-defects.html#229">229</a> have been moved to 
Ready status, and the only remaining concerns with <a href="lwg-defects.html#226">226</a> involve wording.
</li>
<li>R23: 
Pre-Santa Cruz mailing.  Added new issues <a href="lwg-closed.html#367">367</a>-<a href="lwg-closed.html#382">382</a>.
Moved issues in the TC to TC status.
</li>
<li>R22: 
Post-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-defects.html#362">362</a>-<a href="lwg-closed.html#366">366</a>.
</li>
<li>R21: 
Pre-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-closed.html#351">351</a>-<a href="lwg-closed.html#361">361</a>.
</li>
<li>R20: 
Post-Redmond mailing; reflects actions taken in Redmond.  Added
new issues <a href="lwg-defects.html#336">336</a>-<a href="lwg-closed.html#350">350</a>, of which issues 
<a href="lwg-defects.html#347">347</a>-<a href="lwg-closed.html#350">350</a> were added since Redmond, hence
not discussed at the meeting.  

All Ready issues were moved to DR status, with the exception of issues
<a href="lwg-defects.html#284">284</a>, <a href="lwg-defects.html#241">241</a>, and <a href="lwg-closed.html#267">267</a>.

Noteworthy issues discussed at Redmond include 
<a href="lwg-defects.html#120">120</a> <a href="lwg-defects.html#202">202</a>, <a href="lwg-defects.html#226">226</a>, <a href="lwg-defects.html#233">233</a>, 
<a href="lwg-defects.html#270">270</a>, <a href="lwg-defects.html#253">253</a>, <a href="lwg-defects.html#254">254</a>, <a href="lwg-closed.html#323">323</a>.
</li>
<li>R19: 
Pre-Redmond mailing.  Added new issues 
<a href="lwg-closed.html#323">323</a>-<a href="lwg-defects.html#335">335</a>.
</li>
<li>R18: 
Post-Copenhagen mailing; reflects actions taken in Copenhagen.
Added new issues <a href="lwg-defects.html#312">312</a>-<a href="lwg-defects.html#317">317</a>, and discussed
new issues <a href="lwg-defects.html#271">271</a>-<a href="lwg-closed.html#314">314</a>.

Changed status of issues
<a href="lwg-defects.html#103">103</a> <a href="lwg-defects.html#118">118</a> <a href="lwg-defects.html#136">136</a> <a href="lwg-defects.html#153">153</a>
<a href="lwg-defects.html#165">165</a> <a href="lwg-defects.html#171">171</a> <a href="lwg-defects.html#183">183</a> <a href="lwg-defects.html#184">184</a>
<a href="lwg-defects.html#185">185</a> <a href="lwg-defects.html#186">186</a> <a href="lwg-defects.html#214">214</a> <a href="lwg-defects.html#221">221</a>
<a href="lwg-defects.html#234">234</a> <a href="lwg-defects.html#237">237</a> <a href="lwg-defects.html#243">243</a> <a href="lwg-defects.html#248">248</a>
<a href="lwg-defects.html#251">251</a> <a href="lwg-defects.html#252">252</a> <a href="lwg-defects.html#256">256</a> <a href="lwg-defects.html#260">260</a>
<a href="lwg-defects.html#261">261</a> <a href="lwg-defects.html#262">262</a> <a href="lwg-defects.html#263">263</a> <a href="lwg-defects.html#265">265</a>
<a href="lwg-defects.html#268">268</a>
to DR.

Changed status of issues
<a href="lwg-defects.html#49">49</a>  <a href="lwg-defects.html#109">109</a> <a href="lwg-defects.html#117">117</a> <a href="lwg-defects.html#182">182</a>
<a href="lwg-defects.html#228">228</a> <a href="lwg-defects.html#230">230</a> <a href="lwg-defects.html#232">232</a> <a href="lwg-defects.html#235">235</a>
<a href="lwg-defects.html#238">238</a> <a href="lwg-defects.html#241">241</a> <a href="lwg-defects.html#242">242</a> <a href="lwg-defects.html#250">250</a>
<a href="lwg-defects.html#259">259</a> <a href="lwg-defects.html#264">264</a> <a href="lwg-defects.html#266">266</a> <a href="lwg-closed.html#267">267</a>
<a href="lwg-defects.html#271">271</a> <a href="lwg-defects.html#272">272</a> <a href="lwg-defects.html#273">273</a> <a href="lwg-defects.html#275">275</a>
<a href="lwg-defects.html#281">281</a> <a href="lwg-defects.html#284">284</a> <a href="lwg-defects.html#285">285</a> <a href="lwg-defects.html#286">286</a>
<a href="lwg-defects.html#288">288</a> <a href="lwg-defects.html#292">292</a> <a href="lwg-defects.html#295">295</a> <a href="lwg-defects.html#297">297</a>
<a href="lwg-defects.html#298">298</a> <a href="lwg-defects.html#301">301</a> <a href="lwg-defects.html#303">303</a> <a href="lwg-defects.html#306">306</a>
<a href="lwg-defects.html#307">307</a> <a href="lwg-defects.html#308">308</a> <a href="lwg-defects.html#312">312</a>
to Ready.

Closed issues 
<a href="lwg-closed.html#111">111</a> <a href="lwg-closed.html#277">277</a> <a href="lwg-closed.html#279">279</a> <a href="lwg-closed.html#287">287</a>
<a href="lwg-closed.html#289">289</a> <a href="lwg-closed.html#293">293</a> <a href="lwg-closed.html#302">302</a> <a href="lwg-closed.html#313">313</a>
<a href="lwg-closed.html#314">314</a>
as NAD.

</li>
<li>R17: 
Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-defects.html#76">76</a>, <a href="lwg-defects.html#91">91</a>, 
<a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-closed.html#267">267</a>.
Added new issues <a href="lwg-defects.html#278">278</a>-<a href="lwg-defects.html#311">311</a>.
</li>
<li>R16:  
post-Toronto mailing; reflects actions taken in Toronto. Added new
issues <a href="lwg-defects.html#265">265</a>-<a href="lwg-closed.html#277">277</a>.  Changed status of issues
<a href="lwg-defects.html#3">3</a>, <a href="lwg-defects.html#8">8</a>, <a href="lwg-defects.html#9">9</a>, <a href="lwg-defects.html#19">19</a>,
<a href="lwg-defects.html#26">26</a>, <a href="lwg-defects.html#31">31</a>, <a href="lwg-defects.html#61">61</a>,
<a href="lwg-defects.html#63">63</a>, <a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#108">108</a>,
<a href="lwg-defects.html#112">112</a>, <a href="lwg-defects.html#114">114</a>, <a href="lwg-defects.html#115">115</a>,
<a href="lwg-defects.html#122">122</a>, <a href="lwg-defects.html#127">127</a>, <a href="lwg-defects.html#129">129</a>,
<a href="lwg-defects.html#134">134</a>, <a href="lwg-defects.html#137">137</a>, <a href="lwg-defects.html#142">142</a>,
<a href="lwg-defects.html#144">144</a>, <a href="lwg-defects.html#146">146</a>, <a href="lwg-defects.html#147">147</a>,
<a href="lwg-defects.html#159">159</a>, <a href="lwg-defects.html#164">164</a>, <a href="lwg-defects.html#170">170</a>,
<a href="lwg-defects.html#181">181</a>, <a href="lwg-defects.html#199">199</a>, <a href="lwg-defects.html#208">208</a>,
<a href="lwg-defects.html#209">209</a>, <a href="lwg-defects.html#210">210</a>, <a href="lwg-defects.html#211">211</a>,
<a href="lwg-defects.html#212">212</a>, <a href="lwg-defects.html#217">217</a>, <a href="lwg-defects.html#220">220</a>,
<a href="lwg-defects.html#222">222</a>, <a href="lwg-defects.html#223">223</a>, <a href="lwg-defects.html#224">224</a>,
<a href="lwg-defects.html#227">227</a> to "DR".  Reopened issue <a href="lwg-defects.html#23">23</a>. Reopened
issue <a href="lwg-defects.html#187">187</a>. Changed issues <a href="lwg-closed.html#2">2</a> and
<a href="lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="lwg-defects.html#17">17</a>. Fixed
issue <a href="lwg-defects.html#70">70</a>: signature should be changed both places it
appears. Fixed issue <a href="lwg-defects.html#160">160</a>: previous version didn't fix
the bug in enough places.
</li>
<li>R15: 
pre-Toronto mailing. Added issues
<a href="lwg-defects.html#233">233</a>-<a href="lwg-defects.html#264">264</a>. Some small HTML formatting
changes so that we pass Weblint tests.
</li>
<li>R14: 
post-Tokyo II mailing; reflects committee actions taken in
Tokyo. Added issues <a href="lwg-defects.html#228">228</a> to <a href="lwg-defects.html#232">232</a>. (00-0019R1/N1242)
</li>
<li>R13: 
pre-Tokyo II updated: Added issues <a href="lwg-defects.html#212">212</a> to <a href="lwg-defects.html#227">227</a>.
</li>
<li>R12: 
pre-Tokyo II mailing: Added issues <a href="lwg-defects.html#199">199</a> to
<a href="lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
of issue <a href="lwg-defects.html#29">29</a>.  Add further rationale to issue
<a href="lwg-closed.html#178">178</a>.
</li>
<li>R11: 
post-Kona mailing: Updated to reflect LWG and full committee actions
in Kona (99-0048/N1224). Note changed resolution of issues
<a href="lwg-closed.html#4">4</a> and <a href="lwg-defects.html#38">38</a>. Added issues <a href="lwg-closed.html#196">196</a>
to <a href="lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
"closed" documents.  Changed the proposed resolution of issue
<a href="lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
of issue <a href="lwg-defects.html#38">38</a>.
</li>
<li>R10: 
pre-Kona updated.  Added proposed resolutions <a href="lwg-defects.html#83">83</a>,
<a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#91">91</a>, <a href="lwg-defects.html#92">92</a>,
<a href="lwg-defects.html#109">109</a>. Added issues <a href="lwg-closed.html#190">190</a> to
<a href="lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
</li>
<li>R9: 
pre-Kona mailing.  Added issues <a href="lwg-closed.html#140">140</a> to
<a href="lwg-defects.html#189">189</a>. Issues list split into separate "active" and
"closed" documents. (99-0030/N1206, 25 Aug 99)
</li>
<li>R8: 
post-Dublin mailing. Updated to reflect LWG and full committee actions
in Dublin. (99-0016/N1193, 21 Apr 99)
</li>
<li>R7: 
pre-Dublin updated: Added issues <a href="lwg-defects.html#130">130</a>, <a href="lwg-closed.html#131">131</a>,
<a href="lwg-defects.html#132">132</a>, <a href="lwg-defects.html#133">133</a>, <a href="lwg-defects.html#134">134</a>,
<a href="lwg-closed.html#135">135</a>, <a href="lwg-defects.html#136">136</a>, <a href="lwg-defects.html#137">137</a>,
<a href="lwg-closed.html#138">138</a>, <a href="lwg-defects.html#139">139</a> (31 Mar 99)
</li>
<li>R6: 
pre-Dublin mailing. Added issues <a href="lwg-defects.html#127">127</a>, <a href="lwg-closed.html#128">128</a>,
and <a href="lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
</li>
<li>R5: 
update issues <a href="lwg-defects.html#103">103</a>, <a href="lwg-defects.html#112">112</a>; added issues
<a href="lwg-defects.html#114">114</a> to <a href="lwg-defects.html#126">126</a>. Format revisions to prepare
for making list public. (30 Dec 98)
</li>
<li>R4: 
post-Santa Cruz II updated: Issues <a href="lwg-defects.html#110">110</a>,
<a href="lwg-closed.html#111">111</a>, <a href="lwg-defects.html#112">112</a>, <a href="lwg-closed.html#113">113</a> added, several
issues corrected. (22 Oct 98)
</li>
<li>R3: 
post-Santa Cruz II: Issues <a href="lwg-closed.html#94">94</a> to <a href="lwg-defects.html#109">109</a>
added, many issues updated to reflect LWG consensus (12 Oct 98)
</li>
<li>R2: 
pre-Santa Cruz II: Issues <a href="lwg-closed.html#73">73</a> to <a href="lwg-closed.html#93">93</a> added,
issue <a href="lwg-defects.html#17">17</a> updated. (29 Sep 98)
</li>
<li>R1: 
Correction to issue <a href="lwg-defects.html#55">55</a> resolution, <a href="lwg-defects.html#60">60</a> code
format, <a href="lwg-defects.html#64">64</a> title. (17 Sep 98)
</li>
</ul>

<h2><a name="Status"></a>Issue Status</h2>

  <p><b><a name="New">New</a></b> - The issue has not yet been
  reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
  suggestion from the issue submitter, and should not be construed as
  the view of LWG.</p>

  <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue
  but is not yet ready to move the issue forward. There are several
  possible reasons for open status:</p>
     <ul>
        <li>Consensus may have not yet have been reached as to how to deal
            with the issue.</li>
        <li>Informal consensus may have been reached, but the LWG awaits
            exact <b>Proposed Resolution</b> wording for review.</li>
        <li>The LWG wishes to consult additional technical experts before
            proceeding.</li>
        <li>The issue may require further study.</li>
     </ul>

  <p>A <b>Proposed Resolution</b> for an open issue is still not be
  construed as the view of LWG. Comments on the current state of
  discussions are often given at the end of open issues in an italic
  font. Such comments are for information only and should not be given
  undue importance.</p>

  <p><b><a name="Deferred">Deferred</a></b> - The LWG has discussed the issue,
  is not yet ready to move the issue forward, but neither does it deem the
  issue significant enough to delay publishing a standard or Technical Report.
  A typical deferred issue would be seeking to clarify wording that might be
  technically correct, but easily mis-read.</p>

  <p>A <b>Proposed Resolution</b> for a deferred issue is still not be
  construed as the view of LWG. Comments on the current state of
  discussions are often given at the end of open issues in an italic
  font. Such comments are for information only and should not be given
  undue importance.</p>

  <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
  the issue is a duplicate of another issue, and will not be further
  dealt with. A <b>Rationale</b> identifies the duplicated issue's
  issue number.  </p>

  <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
  the issue is not a defect in the Standard.</p>

  <p><b><a name="NAD Editorial">NAD Editorial</a></b> - The LWG has reached consensus that
  the issue can either be handled editorially, or is handled by a paper (usually
  linked to in the rationale).</p>

  <p><b><a name="NAD Concepts">NAD Concepts</a></b> - The LWG has reached consensus that
  the issue is NAD for now, but represents a real issue when the library is
  done with language-supported concepts.</p>

  <p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular
  status, the LWG believes that this issue should be revisited at the
  next revision of the standard.</p>

  <p><b><a name="Review">Review</a></b> - Exact wording of a
  <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="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
  full committee for further action as a Defect Report (DR).</p>

  <p><b><a name="Resolved">Resolved</a></b> - The LWG has reached consensus
  that the issue is a defect in the Standard, but the resolution adopted to
  resolve the issue came via some other mechanism than this issue in the
  list - typically by applying a formal paper, occasionally as a side effect
  of consolidating several interacting issue resolutions into a single issue.</p>

  <p><b><a name="DR">DR</a></b> - (Defect Report) - The full WG21/PL22.16
  committee has voted to forward the issue to the Project Editor to be
  processed as a Potential Defect Report. The Project Editor reviews
  the issue, and then forwards it to the WG21 Convenor, who returns it
  to the full committee for final disposition. This issues list
  accords the status of DR to all these Defect Reports regardless of
  where they are in that process.</p>

  <p><b><a name="TC1">TC1</a></b> - (Technical Corrigenda 1) - The full
  WG21/PL22.16 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/PL22.16 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
  complete and no further action is expected.</p>

  <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
  resolution has not been accepted as a Technical Corrigendum, but
  the full WG21/PL22.16 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
  the associated unqualified status.  However for logistical reasons the indicated
  outcome of the issue has not yet appeared in the latest working paper.

  <p>Issues are always given the status of <a href="lwg-active.html#New">New</a> when
  they first appear on the issues list. They may progress to
  <a href="lwg-active.html#Open">Open</a> or <a href="lwg-active.html#Review">Review</a> while the LWG
  is actively working on them. When the LWG has reached consensus on
  the disposition of an issue, the status will then change to
  <a href="lwg-active.html#Dup">Dup</a>, <a href="lwg-active.html#NAD">NAD</a>, or
  <a href="lwg-active.html#Ready">Ready</a> as appropriate.  Once the full J16 committee votes to
  forward Ready issues to the Project Editor, they are given the
  status of Defect Report ( <a href="lwg-active.html#DR">DR</a>). These in turn may
  become the basis for Technical Corrigenda (<a href="lwg-active.html#TC1">TC1</a>),
  or are closed without action other than a Record of Response
  (<a href="lwg-active.html#Resolved">Resolved</a> ). The intent of this LWG process is that
  only issues which are truly defects in the Standard move to the
  formal ISO DR status.
  </p>


<h2>Active Issues</h2>
<hr>
<h3><a name="1169"></a>1169. <tt>num_get</tt> not fully compatible with <tt>strto*</tt></h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2009-07-04 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As specified in the latest draft,
<a 
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
<code>num_get</code> is still not fully compatible with the following C
functions: <code>strtoul</code>, <code>strtoull</code>, 
<code>strtof</code> and
<code>strtod</code>.
</p>
<p>
In C, when conversion of a string to an unsigned integer type falls 
outside the
representable range, <code>strtoul</code> and <code>strtoull</code> return
<code>ULONG_MAX</code> and <code>ULLONG_MAX</code>, respectively, 
regardless
whether the input field represents a positive or a negative value.
On the other hand, the result of <code>num_get</code> conversion of 
negative
values to unsigned integer types is zero. This raises a compatibility 
issue.
</p>
<p>
Moreover, in C, when conversion of a string to a floating-point type falls
outside the representable range, <code>strtof</code>, <code>strtod</code> 
and
<code>strtold</code> return <code>&#xB1HUGE_VALF</code>,
<code>&#xB1HUGE_VAL</code> and <code>&#xB1HUGE_VALL</code>, respectively.
On the other hand, the result of <code>num_get</code> conversion of such
out-of-range floating-point values results in the most positive/negative
representable value.
Although many C library implementations do implement <code>HUGE_VAL</code>
(etc.) as the highest representable (which is, usually, the infinity), 
this isn't required by the C standard. The C library specification makes no
statement regarding the value of <code>HUGE_VAL</code> and friends, which
potentially raises the same compatibility issue as in the above case of
unsigned integers.
In addition, neither C nor C++ define symbolic constants for the maximum
representable floating-point values (they only do so only for the maximum
representable <i>finite</i> floating-point values), which raises a 
usability
issue (it would be hard for the programmer to check the result of
<code>num_get</code> against overflow).
</p>
<p>
As such, we propose to adjust the specification of <code>num_get</code> to
closely follow the behavior of all of its underlying C functions.
</p>



<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote><p>
Some concern that this is changing the specification for an existing C++03 function, but it was 
pointed out that this was underspecified as resolved by issue 23.  This is clean-up for that 
issue in turn. Some concern that we are trying to solve the same problem in both clause 22 and 27.
</p>
<p>
Bill: There's a change here as to whether val is stored to in an error case.
</p>
<p>
Pablo: Don't think this changes whether val is stored to or not, but changes the value that is stored.
</p>
<p>
Bill: Remembers having skirmishes with customers and testers as to whether val is stored to, and the resolution was not to store in error cases.
</p>
<p>
Howard: Believes since C++03 we made a change to always store in overflow.
</p>
<p>
Everyone took some time to review the issue.
</p>
<p>
Pablo: C++98 definitely did not store any value during an error condition.
</p>
<p>
Dietmar: Depends on the question of what is considered an error, and whether overflow is an error or not, which was the crux of LWG 23.
</p>
<p>
Pablo: Yes, but given the "zero, if the conversion function fails to convert the entire field", we are requiring every error condition to store.
</p>
<p>
Bill: When did this happen?
</p>
<p>
Alisdair: One of the last two or three meetings.
</p>
<p>
Dietmar: To store a value in case of failure is a very bad idea.
</p>
<p>
Move to Open, needs more study.
</p>
</blockquote>

<p><i>[2011-03-24 Madrid meeting]</i></p>


<p>Move to deferred</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
The proposed wording looks good, no-one sure why this was held back before.  Move to Review.
</p>


<p><i>[2012,Kona]</i></p>

<p>
Move to Open.
</p>
<p>
THe issues is what to do with <tt>-1</tt>.  Should it match 'C' or do the "sane" thing.
A fix here changes behavior, but is probably what we want.
</p>
<p>
Pablo to provide wording, with help from Howard.
</p>



<p><b>Proposed resolution:</b></p>

<p>
Change 22.4.2.1.2 [facet.num.get.virtuals] as follows:
</p>
<blockquote>
<p>
<b>Stage 3:</b>
The sequence of <code>char</code>s accumulated in stage 2 (the field) is
converted to a numeric value by the rules of one of the functions declared in
the header <code>&lt;cstdlib&gt;</code>:
</p>
<ul>
<li>For a signed integer value, the function <code>strtoll</code>.</li>
<li>For an unsigned integer value, the function <code>strtoull</code>.</li>
<li><ins>For a <code>float</code> value, the function
    <code>strtof</code>.</ins></li>
<li><ins>For a <code>double</code> value, the function
    <code>strtod</code>.</ins></li>
<li>For a <del>floating-point</del> <ins><code>long double</code></ins>
    value, the function <code>strtold</code>.</li>
</ul>
<p>
The numeric value to be stored can be one of:
</p>
<ul>
<li>zero, if the conversion function fails to convert the entire field.
    <del><code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
<li>the most positive <ins>(or negative)</ins> representable value, if
    the field <ins>to be converted to a signed integer type</ins> represents a
    value too large positive <ins>(or negative)</ins> to be represented in
    <code>val</code>.
    <del><code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
<li><del>the most negative representable value or zero for an unsigned integer
    type, if the field represents a value too large negative to be represented
    in <code>val</code>.
    <code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
<li><ins>the most positive representable value, if the field to be converted to
    an unsigned integer type represents a value that cannot be represented in
    <code>val</code>.</ins></li>
<li>the converted value, otherwise.</li>
</ul>
<p>
The resultant numeric value is stored in <code>val</code>.
<ins>If the conversion function fails to convert the entire field, or if the
field represents a value outside the range of representable values,
<code>ios_base::failbit</code> is assigned to <code>err</code>.</ins>
</p>
</blockquote>






<hr>
<h3><a name="1175"></a>1175. <tt>unordered</tt> complexity</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-07-17 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When I look at the <tt>unordered_*</tt> constructors, I think the complexity is poorly
described and does not follow the style of the rest of the standard.
</p>

<p>
The complexity for the default constructor is specified as constant.
Actually, it is proportional to <tt>n</tt>, but there are no invocations of
<tt>value_type</tt> constructors or other <tt>value_type</tt> operations.
</p>

<p>
For the iterator-based constructor the complexity should be:
</p>

<blockquote><p>
<i>Complexity:</i> exactly <tt>n</tt> calls to construct <tt>value_type</tt>
from <tt>InputIterator::value_type</tt> (where <tt>n = distance(f,l)</tt>).
The number of calls to <tt>key_equal::operator()</tt> is proportional to
<tt>n</tt> in the average case and <tt>n*n</tt> in the worst case.
</p></blockquote>



<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote><p>
Concern that the current wording may require O(1) where that cannot be delivered.  We need to look at 
both the clause 23 requirements tables and the constructor description of each unordered container to be sure.
</p>
<p>
Howard suggests NAD Editorial as we updated the container requirement tables since this issue was written.
</p>
<p>
Daniel offers to look deeper, and hopefully produce wording addressing any outstanding concerns at the next meeting.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[2011-02-26: Daniel provides wording]</i></p>


<p>I strongly suggest to clean-up the differences between requirement tables and individual
specifications. In the usual way, the most specific specifications wins, which is in this
case the wrong one. In regard to the concern expressed about missing <tt>DefaultConstructible</tt>
requirements of the value type I disagree: The function argument <tt>n</tt> is no size-control
parameter, but only some effective capacity parameter: No elements will be value-initialized
by these constructors. The necessary requirement for the value type, <tt>EmplaceConstructible</tt>
into <tt>*this</tt>, is already listed in Table 103 &mdash; Unordered associative container requirements.
Another part of the proposed resolution is the fact that there is an inconsistency of the
complexity counting when both a range <strong>and</strong> a bucket count is involved compared
to constructions where only bucket counts are provided: E.g. the construction <tt>X a(n);</tt>
has a complexity of <tt>n</tt> bucket allocations, but this part of the work is omitted for
<tt>X a(i, j, n);</tt>, even though it is considerable larger (in the average case) for 
<tt>n &#8811; distance(i, j)</tt>.
</p>

<p><i>[2011-03-24 Madrid meeting]</i></p>


<p>Move to deferred</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
The proposed wording looks good.  Move to Review.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Fix up some presentation issues with the wording, combining the big-O expressions into single
expressions rather than the sum of two separate big-Os.
</p>
<p>
Strike "constant or linear", prefer "linear in the number of buckets".
This allows for number of buckets being larger than requested <tt>n</tt> as well.
</p>
<p>
Default <tt>n</tt> to "unspecified" rather than "implementation-defined".  It seems an un-necessary
burden asking vendors to document a quantity that is easily determined through the public API of
these classes.
</p>
<p>
Replace <tt>distance(f,l)</tt> with "number of elements in the range <tt>[f,l)</tt>"
</p>
<p>
Retain in Review with the updated wording
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li><p>Modify the following rows in Table 103 &mdash; Unordered associative container requirements to
add the explicit bucket allocation overhead of some constructions. As editorial recommendation it is 
suggested <em>not</em> to shorten the sum <tt>&#x1d4aa;(n) + &#x1d4aa;(<em>N</em>)</tt> to
<tt>&#x1d4aa;(n + <em>N</em>)</tt>, because two different work units are involved.</p>

<blockquote>
<table border="1">
<caption>Table 103 &mdash; Unordered associative container requirements (in addition to container)</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td colspan="4" style="text-align:center;">&hellip;</td>
</tr>

<tr>
<td><tt>X(i, j, n, hf, eq)</tt><br/>
<tt>X a(i, j, n, hf, eq)</tt>
</td>
<td><tt>X</tt></td>
<td>&hellip;<br/>
<i>Effects</i>: Constructs an empty container with at least <tt>n</tt><br/>
buckets, using <tt>hf</tt> as the hash function and <tt>eq</tt> as the key<br/>
equality predicate, and inserts elements from <tt>[i, j)</tt> into it.
</td>
<td>Average case &#x1d4aa;(<tt><i><ins>n + </ins>N</i></tt>) (<tt><i>N</i></tt> is <tt>distance(i, j)</tt>),<br/>
worst case <ins>&#x1d4aa;(<tt>n</tt>) +</ins> &#x1d4aa;(<tt><i>N</i><sup>2</sup></tt>)</td>
</tr>

<tr>
<td><tt>X(i, j, n, hf)</tt><br/>
<tt>X a(i, j, n, hf)</tt>
</td>
<td><tt>X</tt></td>
<td>&hellip;<br/>
<i>Effects</i>: Constructs an empty container with at least <tt>n</tt><br/>
buckets, using <tt>hf</tt> as the hash function and <tt>key_equal()</tt> as the key<br/>
equality predicate, and inserts elements from <tt>[i, j)</tt> into it.
</td>
<td>Average case &#x1d4aa;(<tt><i><ins>n + </ins>N</i></tt>) (<tt><i>N</i></tt> is <tt>distance(i, j)</tt>),<br/>
worst case &#x1d4aa;(<tt><i><ins>n + </ins>N</i><sup>2</sup></tt>)</td>
</tr>

<tr>
<td><tt>X(i, j, n)</tt><br/>
<tt>X a(i, j, n)</tt>
</td>
<td><tt>X</tt></td>
<td>&hellip;<br/>
<i>Effects</i>: Constructs an empty container with at least <tt>n</tt><br/>
buckets, using <tt>hasher()</tt> as the hash function and <tt>key_equal()</tt> as the key<br/>
equality predicate, and inserts elements from <tt>[i, j)</tt> into it.
</td>
<td>Average case &#x1d4aa;(<tt><i><ins>n + </ins>N</i></tt>) (<tt><i>N</i></tt> is <tt>distance(i, j)</tt>),<br/>
worst case &#x1d4aa;(<tt><i><ins>n + </ins>N</i><sup>2</sup></tt>)</td>
</tr>

<tr>
<td colspan="4" style="text-align:center;">&hellip;</td>
</tr>

</table>
</blockquote>

</li>

<li><p>Modify 23.5.4.2 [unord.map.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some
editorial oversight.):</p>

<blockquote><pre>
explicit unordered_map(size_type n = <i>see below</i>,
                       const hasher&amp; hf = hasher(),
                       const key_equal&amp; eql = key_equal(),
                       const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
1 <i>Effects</i>: Constructs an empty <tt>unordered_map</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecied</ins><del>impldefdefault number of buckets in <tt>unordered_map</tt></del>. 
<tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
2 <i>Complexity</i>: <del>Constant</del><ins>Linear in the number of buckets</ins>.
</p></blockquote>
</blockquote>

<blockquote><pre>
template &lt;class InputIterator&gt;
unordered_map(InputIterator f, InputIterator l,
              size_type n = <i>see below</i>,
              const hasher&amp; hf = hasher(),
              const key_equal&amp; eql = key_equal(),
              const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
3 <i>Effects</i>: Constructs an empty <tt>unordered_map</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_map</tt></del>.
Then inserts elements from the range <tt>[f, l)</tt>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
4 <i>Complexity</i>: <del>Average case linear, worst case quadratic</del><ins>Linear in the number of buckets.
In the average case linear in <tt><i>N</i></tt> and in the worst case quadratic in <tt><i>N</i></tt> to insert
the elements, where <tt><i>N</i></tt> is equal to number of elements in the range <tt>[f,l)</tt></ins>.
</p></blockquote>
</blockquote>
</li>

<li><p>Modify 23.5.5.2 [unord.multimap.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some
editorial oversight.):</p>

<blockquote><pre>
explicit unordered_multimap(size_type n = <i>see below</i>,
                            const hasher&amp; hf = hasher(),
                            const key_equal&amp; eql = key_equal(),
                            const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
1 <i>Effects</i>: Constructs an empty <tt>unordered_multimap</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_multimap</tt></del>. 
<tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
2 <i>Complexity</i>: <del>Constant</del><ins>Linear in the number of buckets</ins>.
</p></blockquote>
</blockquote>

<blockquote><pre>
template &lt;class InputIterator&gt;
unordered_multimap(InputIterator f, InputIterator l,
                   size_type n = <i>see below</i>,
                   const hasher&amp; hf = hasher(),
                   const key_equal&amp; eql = key_equal(),
                   const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
3 <i>Effects</i>: Constructs an empty <tt>unordered_multimap</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_multimap</tt></del>.
Then inserts elements from the range <tt>[f, l)</tt>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
4 <i>Complexity</i>: <del>Average case linear, worst case quadratic</del><ins>Linear in the number of buckets.
In the average case linear in <tt><i>N</i></tt> and in the worst case quadratic in <tt><i>N</i></tt> to insert
the elements, where <tt><i>N</i></tt> is equal to number of elements in the range <tt>[f,l)</tt></ins>.
</p></blockquote>
</blockquote>
</li>

<li><p>Modify 23.5.6.2 [unord.set.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some
editorial oversight.):</p>

<blockquote><pre>
explicit unordered_set(size_type n = <i>see below</i>,
                       const hasher&amp; hf = hasher(),
                       const key_equal&amp; eql = key_equal(),
                       const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
1 <i>Effects</i>: Constructs an empty <tt>unordered_set</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_set</tt></del>. 
<tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
2 <i>Complexity</i>: <del>Constant</del><ins>Linear in the number of buckets</ins>.
</p></blockquote>
</blockquote>

<blockquote><pre>
template &lt;class InputIterator&gt;
unordered_set(InputIterator f, InputIterator l,
              size_type n = <i>see below</i>,
              const hasher&amp; hf = hasher(),
              const key_equal&amp; eql = key_equal(),
              const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
3 <i>Effects</i>: Constructs an empty <tt>unordered_set</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_set</tt></del>.
Then inserts elements from the range <tt>[f, l)</tt>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
4 <i>Complexity</i>: <del>Average case linear, worst case quadratic</del><ins>Linear in the number of buckets.
In the average case linear in <tt><i>N</i></tt> and in the worst case quadratic in <tt><i>N</i></tt> to insert
the elements, where <tt><i>N</i></tt> is equal to number of elements in the range <tt>[f,l)</tt></ins>.
</p></blockquote>
</blockquote>
</li>

<li><p>Modify 23.5.7.2 [unord.multiset.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some
editorial oversight.):</p>

<blockquote><pre>
explicit unordered_multiset(size_type n = <i>see below</i>,
                            const hasher&amp; hf = hasher(),
                            const key_equal&amp; eql = key_equal(),
                            const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
1 <i>Effects</i>: Constructs an empty <tt>unordered_multiset</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_multiset</tt></del>. 
<tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
2 <i>Complexity</i>: <del>Constant</del><ins>Linear in the number of buckets</ins>.
</p></blockquote>
</blockquote>

<blockquote><pre>
template &lt;class InputIterator&gt;
unordered_multiset(InputIterator f, InputIterator l,
                   size_type n = <i>see below</i>,
                   const hasher&amp; hf = hasher(),
                   const key_equal&amp; eql = key_equal(),
                   const allocator_type&amp; a = allocator_type());
</pre><blockquote><p>
3 <i>Effects</i>: Constructs an empty <tt>unordered_multiset</tt> using the specified hash function, key equality function,
and allocator, and using at least <tt>n</tt> buckets. If <tt>n</tt> is not provided, the number of buckets is 
<ins>unspecified</ins><del>impldefdefault number of buckets in <tt>unordered_multiset</tt></del>.
Then inserts elements from the range <tt>[f, l)</tt>. <tt>max_load_factor()</tt> returns <tt>1.0</tt>.
</p></blockquote>
<blockquote><p>
4 <i>Complexity</i>: <del>Average case linear, worst case quadratic</del><ins>Linear in the number of buckets.
In the average case linear in <tt><i>N</i></tt> and in the worst case quadratic in <tt><i>N</i></tt> to insert
the elements, where <tt><i>N</i></tt> is equal to number of elements in the range <tt>[f,l)</tt></ins>.
</p></blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="1213"></a>1213. Meaning of valid and singular iterator underspecified</h3>
<p><b>Section:</b> 24.2 [iterator.requirements] <b>Status:</b> <a href="lwg-active.html#Deferred">Deferred</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2009-09-19 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
<p><b>Discussion:</b></p>
<p>
The terms <em>valid</em> iterator and <em>singular</em> aren't
properly defined. The fuzziness of those terms became even worse
after the resolution of <a href="lwg-defects.html#208">208</a> (including further updates by <a href="lwg-defects.html#278">278</a>). In
24.2 [iterator.requirements] as of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
the standard says now:
</p>

<blockquote>
<p>
5 - These values are called past-the-end values. Values of an iterator <tt>i</tt> for
which the expression <tt>*i</tt> is defined are called dereferenceable. The library
never assumes that past-the-end values are dereferenceable. Iterators
can also have singular values that are not associated with any
container. [...] Results of most expressions are undefined for singular
values; the only exceptions are destroying an iterator that holds a
singular value and the assignment of a non-singular value to an iterator
that holds a singular value. [...] Dereferenceable values are always
non-singular.
</p>

<p>
10 - An invalid iterator is an iterator that may be singular.
</p>
</blockquote>

<p>
First, issue <a href="lwg-defects.html#208">208</a> intentionally removed the earlier constraint that past-the-end
values are always non-singular. The reason for this was to support null
pointers as past-the-end iterators of e.g. empty sequences. But there
seem to exist different views on what a singular (iterator) value is. E.g.
according to the <a href="http://www.sgi.com/tech/stl/trivial.html">SGI definition</a>
a null pointer is <em>not</em> a singular value:
</p>

<blockquote><p>
Dereferenceable iterators are always nonsingular, but the converse is
not true.
For example, a null pointer is nonsingular (there are well defined operations
involving null pointers) even thought it is not dereferenceable.
</p></blockquote>

<p>
and <a href="http://www.sgi.com/tech/stl/InputIterator.html">proceeds</a>:
</p>

<blockquote><p>
An iterator is valid if it is dereferenceable or past-the-end.
</p></blockquote>

<p>
Even if the standard prefers a different meaning of singular here, the
change was incomplete, because by restricting feasible expressions of singular
iterators to destruction and assignment isn't sufficient for a past-the-end
iterator: Of-course it must still be equality-comparable and in general be a readable value.
</p>

<p>
Second, the standard doesn't clearly say whether a past-the-end value is
a valid iterator or not. E.g. 20.6.12 [specialized.algorithms]/1 says:
</p>

<blockquote><p>
In all of the following algorithms, the formal template parameter <tt>ForwardIterator</tt> 
is required to satisfy the requirements of a forward iterator (24.1.3)
[..], and is required to have the property that no exceptions are thrown from [..], or
dereference of valid iterators.
</p></blockquote>

<p>
The standard should make better clear what "singular pointer" and "valid
iterator" means. The fact that the meaning of a valid <em>value</em>
has a core language meaning doesn't imply that for an iterator concept
the term "valid iterator" has the same meaning.
</p>

<p>
Let me add a final example: In X [allocator.concepts.members] of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>
we find:
</p>

<blockquote><pre>
pointer X::allocate(size_type n);
</pre>

<blockquote><p>
11 <i>Returns:</i> a pointer to the allocated memory. [<i>Note:</i> if <tt>n == 0</tt>, the return
value is unspecified. &mdash;<i>end note</i>]
</p></blockquote>

<p>
[..]
</p>

<pre>
void X::deallocate(pointer p, size_type n);
</pre>

<blockquote><p>
<i>Preconditions:</i> <tt>p</tt> shall be a non-singular pointer value obtained from a call
to <tt>allocate()</tt> on this allocator or one that compares equal to it.
</p></blockquote>
</blockquote>

<p>
If singular pointer value would include null pointers this make the
preconditions
unclear if the pointer value is a result of <tt>allocate(0)</tt>: Since the return value
is unspecified, it could be a null pointer. Does that mean that programmers
need to check the pointer value for a null value before calling deallocate?
</p>

<p><i>[
2010-11-09 Daniel comments:
]</i></p>


<p>
A later paper is in preparation.
</p>

<p><i>[
2010 Batavia:
]</i></p>


<p>
Doesn't need to be resolved for Ox
</p>


<p><b>Proposed resolution:</b></p>
<p>
Consider to await the paper.
</p>





<hr>
<h3><a name="1450"></a>1450. [FCD] Contradiction in regex_constants</h3>
<p><b>Section:</b> 28.5.2 [re.matchflag] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-127</b></p>

<p>
The Bitmask Type requirements in 17.5.2.1.3 [bitmask.types] p.3 say that
all elements on a bitmask type have distinct values, but
28.5.2 [re.matchflag] defines <tt>regex_constants::match_default</tt> and
<tt>regex_constants::format_default</tt> as elements of the
bitmask type <tt>regex_constants::match_flag_type</tt>, both with
value 0. This is a contradiction.
</p>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote><p>
One of the bitmask elements should be removed
from the declaration and should be defined
separately, in the same manner as
<tt>ios_base::adjustfield</tt>, <tt>ios_base::basefield</tt> and
<tt>ios_base::floatfield</tt> are defined by 27.5.3.1.2 [ios::fmtflags] p.2
and Table 120. These are constants of a bitmask
type, but are not distinct elements, they have
more than one value set in the bitmask.
<tt>regex_constants::format_default</tt> should be
specified as a constant with the same value as
<tt>regex_constants::match_default</tt>.
</p></blockquote>

<p><i>[
2010-10-31 Daniel comments:
]</i></p>

<p>
Strictly speaking, a bitmask type cannot have any element of value 0 at all, because
any such value would contradict the requirement expressed in 17.5.2.1.3 [bitmask.types] p. 3:
</p>
<blockquote><p>
for any pair <em>Ci</em> and <em>Cj</em>, <em>Ci</em> &amp; <em>Ci</em> is nonzero
</p></blockquote>
<p>
So, actually <em>both</em> <tt>regex_constants::match_default</tt> and
<tt>regex_constants::format_default</tt> are only constants of the type
<tt>regex_constants::match_flag_type</tt>, and no bitmask elements.
</p>

<p><i>[
2010-11-03 Daniel comments and provides a proposed resolution:
]</i></p>


<p>The proposed resolution is written against N3126 and considered as a further improvement
of the fixes suggested by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html">n3110</a>.
</p>

<blockquote>
<p>
Add the following sentence to 28.5.2 [re.matchflag]  paragraph 1:
</p>
<blockquote><p>
1 The type <tt>regex_constants::match_flag_type</tt> is an implementation-defined bitmask type (17.5.2.1.3).
Matching a regular expression against a sequence of characters [first,last) proceeds according to the
rules of the grammar specified for the regular expression object, modified according to the effects listed in
Table 136 for any bitmask elements set. <ins>Type <tt>regex_constants::match_flag_type</tt> also defines the 
constants <tt>regex_constants::match_default</tt> and <tt>regex_constants::format_default</tt>.</ins>
</p></blockquote>
</blockquote>

<p><i>[
2011 Bloomington
]</i></p>


<p>
It appears the key problem is the phrasing of the bitmask requirements.  Jeremiah supplies updated wording.
</p>

<p>
Pete Becker has also provided an alternative resolution.
</p>

<p>
Ammend 17.5.2.1.3 [bitmask.types]:
</p>
<p>
Change the list of values for "enum bit mask" in p2 from
</p>
<p>
<tt><i>V0</i> = 1 &lt;&lt; 0, <i>V1</i> = 1 &lt;&lt; 1, <i>V2</i> = 1 &lt;&lt; 2, <i>V3</i> = 1 &lt;&lt; 3, ...</tt>.
</p>
<p>
to
</p>
<p>
<tt><i>V0</i> = 0, <i>V1</i> = 1 &lt;&lt; 0, <i>V2</i> = 1 &lt;&lt; 1, <i>V3</i> = 1 &lt;&lt; 2,  ...</tt>.
</p>
<p>
Here, the names <i>C0</i>, <i>C1</i>, etc. represent <i>bitmask elements</i> for this particular
bitmask type. All such <ins>non-zero</ins> elements have distinct values such that, for any pair
<i>Ci</i> and <i>Cj</i> <ins>where <i>i</i> != <i>j</i></ins>, <del><i>Ci &amp; Ci</i> is nonzero
and</del> <i>Ci &amp; Cj</i> is zero.
</p>
<p>
Change bullet 3 of paragraph 4:
</p>
<p>
<del>The</del><ins>A non-zero</ins> value Y is set in the object X if the expression X &amp; Y is nonzero.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Ammend 17.5.2.1.3 [bitmask.types] p3:
</p>
<p>
Here, the names <i>C0</i>, <i>C1</i>, etc. represent <i>bitmask elements</i> for this particular
bitmask type. All such elements have distinct<ins>, non-zero</ins> values such that, for any pair
<i>Ci</i> and <i>Cj</i> <ins>where <i>i</i> != <i>j</i>,</ins> <i>Ci &amp; Ci</i> is nonzero
and <i>Ci &amp; Cj</i> is zero. <ins>Additionally, the value 0 is used to represent an
<i>empty bitmask</i>, in which no bitmask elements are set.</ins>
</p>

<p>
Add the following sentence to 28.5.2 [re.matchflag]  paragraph 1:
</p>
<blockquote><p>
1 The type <tt>regex_constants::match_flag_type</tt> is an implementation-defined bitmask type (17.5.2.1.3).
<ins>The constants of that type, except for <tt>match_default</tt> and <tt>format_default</tt>, are bitmask
elements. The <tt>match_default</tt> and <tt>format_default</tt> constants are empty bitmasks.</ins> Matching
a regular expression against a sequence of characters [first,last) proceeds according to the rules of the
grammar specified for the regular expression object, modified according to the effects listed in Table 136
for any bitmask elements set.
</p></blockquote>





<hr>
<h3><a name="1526"></a>1526. [FCD] C++ should not impose thread safety requirements on C99 library implementations</h3>
<p><b>Section:</b> 17.6.5.9 [res.on.data.races] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2011-03-24 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-111</b></p>

<p>Section 17.6.5.9 [res.on.data.races], Data Race Avoidance, requires the C++ Standard Library to avoid data races 
that might otherwise result from two threads making calls to C++ Standard Library functions on 
distinct objects. The C standard library is part of the C++ Standard Library and some C++ Standary library 
functions (parts of the Localization library, as well as Numeric Conversions in 21.5), are specified 
to make use of the C standard library. Therefore, the C++ standard indirectly imposes a requirement 
on the thread safety of the C standard library. However, since the C standard does not address the 
concept of thread safety conforming C implementations exist that do no provide such guarantees. 
This conflict needs to be reconciled.</p>

<p>Suggested resolution by national body comment:</p>

<blockquote><p>
remove the requirement to make use of <tt>strtol()</tt> and <tt>sprintf()</tt> since these functions depend on the 
global C locale and thus cannot be made thread safe.
</p></blockquote>

<p><i>[2011-03-24 Madrid meeting]</i></p>


<p>Deferred</p>

<p><i>[
2011 Bloomington
]</i></p>

<p>
Alisdair: PJ, does this cause a problem in C?
</p>
<p>
PJ: Every implementation know of is thread safe.
</p>
<p>
Pete: There a couple of effects that are specified on strtol() and sprintf() which is a problem.
</p>
<p>
PJ: When C++ talks about C calls it should be "as if" calling the function.
</p>
<p>
Pete: Culprit is to string stuff. My fault.
</p>
<p>
PJ: Not your fault. You did what you were told. Distinct resolution to change wording.
</p>
<p>
Dietmar: What would we break if we change it back?
</p>
<p>
Pete: Nothing. If implemented on top of thread safe C library you are just fine.
</p>
<p>
Alisdair: Anyone want to clean up wording and put it back to what Pete gave us?
</p>
<p>
Alisdair: No volunteers. Do we want to mark as NAD? We could leave it as deferred.
</p>
<p>
Stefanus: Did original submitter care about this?
</p>
<p>
Lawrence: There is some work to make local calls thread safe. The resolution would be to call those thread safe version.
</p>
<p>
Pete: "As if called under single threaded C program"
</p>
<p>
<b>Action Item</b> (Alisdair): Write wording for this issue.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Re-opened at the request of the concurrency subgroup, who feel there is an issue that needs
clarifying for the (planned) 2017 standard.
</p>



<p><b>Rationale:</b></p><p>No consensus to make a change at this time</p>

<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2003"></a>2003. String exception inconsistency in erase.</h3>
<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jos&eacute; Daniel Garc&iacute;a S&aacute;nchez <b>Opened:</b> 2010-10-21 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#string.require">active issues</a> in [string.require].</p>
<p><b>View all other</b> <a href="lwg-index.html#string.require">issues</a> in [string.require].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Clause 21.4.1 [string.require]p3 states:
</p>
<blockquote><p>
No <tt>erase()</tt> or <tt>pop_back()</tt> member function shall throw
any exceptions.
</p></blockquote>
<p>
However in 21.4.6.5 [string::erase] p2 the first version of <tt>erase</tt> has
</p>
<blockquote><p>
<i>Throws</i>: <tt>out_of_range</tt> if <tt>pos > size()</tt>.
</p></blockquote>

<p><i>[2011-03-24 Madrid meeting]</i></p>


<p>
Beman: Don't want to just change this, can we just say "unless otherwise specified"?
<p/>
Alisdair: Leave open, but update proposed resolution to say something like "unless otherwise specified".
<p/>
General agreement that it should be corrected but not a stop-ship.
<p/>
Action: Update proposed wording for issue 2003 as above, but leave Open. 
</p>


<p><b>Proposed resolution:</b></p>
<p>
Update [string.require]p/3:
</p>
<blockquote><p>
3 No <del><tt>erase()</tt> or</del> <tt>pop_back()</tt> member function
shall throw any exceptions.
</p></blockquote>





<hr>
<h3><a name="2005"></a>2005. <tt>unordered_map::insert(T&amp;&amp;)</tt> protection should apply to <tt>map</tt> too</h3>
<p><b>Section:</b> 23.4.4.4 [map.modifiers], 23.4.5.3 [multimap.modifiers], X [unord.map.modifiers], X [unord.multimap.modifiers] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2010-10-14 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In [unord.map.modifiers], the signature:
</p>
<blockquote><pre>
template &lt;class P&gt;
    pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);
</pre></blockquote>
<p>
now has an added Remarks paragraph:
</p>
<blockquote><p>
<i>Remarks</i>: This signature shall not participate in overload resolution unless <tt>P</tt>
is implicitly convertible to <tt>value_type</tt>.
</p></blockquote>
<p>
The same is true for <tt>unordered_multimap</tt>.
<p/>
But neither <tt>map</tt> nor <tt>multimap</tt> have this constraint, even though it is a
Good Thing(TM) in those cases as well.
</p>

<p><i>[
The submitter suggests: Add the same Remarks clause to [map.modifiers] and [multimap.modifiers].
]</i></p>


<p><i>[
2010-10-29 Daniel comments:
]</i></p>


<p>
I believe both paragraphs need more cleanup: First, the current Requires element conflict with the Remark; 
second, it seems to me that the whole single Requires element is intended to be split into a Requires
and an Effects element; third, the reference to <tt>tuple</tt> is incorrect (noticed by Paolo Carlini);
fourth, it refers to some non-existing <tt>InputIterator</tt> parameter relevant for a completely different
overload; sixth, the return type of the overload with hint is wrong.
The following proposed resolution tries to solve these issues as well and uses similar wording as for
the corresponding unordered containers. Unfortunately it has some redundancy over Table&nbsp;99, but I did
not remove the specification because of the more general template parameter <tt>P</tt> - the Table&nbsp;99 
requirements apply only for an argument <em>identical</em> to <tt>value_type</tt>.
<p/>
Daniel's Proposed resolution (not current):
</p>

<blockquote class="note">
<ol>
<li>Change 23.4.4.4 [map.modifiers] around p. 1 as indicated:
<blockquote><pre>
template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);
template &lt;class P&gt; <del>pair&lt;</del>iterator<del>, bool&gt;</del> insert(const_iterator position, P&amp;&amp; x);
</pre><blockquote><p>
1 <em>Requires</em>: <del><tt>P</tt> shall be convertible to </del><tt>value_type</tt><ins> is constructible 
from <tt>std::forward&lt;P&gt;(x)</tt>.</ins>.
<p/>
<del>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 map. Specifically, in
such cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or <tt>mapped_type</tt> unless the conversion
from <tt>P</tt> specifically requires it (e.g., if <tt>P</tt> is a <tt>tuple&lt;const key_type, mapped_type&gt;</tt>, then <tt>key_type</tt>
must be <tt>CopyConstructible</tt>). The signature taking <tt>InputIterator</tt> parameters does not require
<tt>CopyConstructible</tt> of either <tt>key_type</tt> or <tt>mapped_type</tt> if the dereferenced <tt>InputIterator</tt> returns a
non-const rvalue <tt>pair&lt;key_type,mapped_type&gt;</tt>. Otherwise <tt>CopyConstructible</tt> is required for both
<tt>key_type</tt> and <tt>mapped_type</tt>.</del><br/>
<ins>? <em>Effects</em>: Inserts <tt>x</tt> converted to <tt>value_type</tt> if and only if there is no element in the container with
key equivalent to the key of <tt>value_type(x)</tt>. For the second form, the iterator <tt>position</tt> is a hint pointing to where the
search should start.</ins>
<p/>
<ins>? <em>Returns</em>: For the first form, the <tt>bool</tt> component of the returned <tt>pair</tt> object indicates whether the 
insertion took place and the iterator component - or for the second form the returned iterator - points to the element with key equivalent 
to the key of <tt>value_type(x)</tt>.</ins>
<p/>
<ins>? <em>Complexity</em>: Logarithmic in general, but amortized constant if <tt>x</tt> is inserted right before <tt>position</tt>.</ins>
<p/>
<ins>? <em>Remarks</em>: These signatures shall not participate in overload resolution unless <tt>P</tt> 
is implicitly convertible to <tt>value_type</tt>.</ins>
</p>
</blockquote></blockquote>
</li>
<li>Change 23.4.5.3 [multimap.modifiers] around p. 1 as indicated:
<blockquote><pre>
template &lt;class P&gt; iterator insert(P&amp;&amp; x);
template &lt;class P&gt; iterator insert(const_iterator position, P&amp;&amp; x);
</pre><blockquote><p>
1 <em>Requires</em>: <del><tt>P</tt> shall be convertible to </del><tt>value_type</tt> <ins>is constructible from 
<tt>std::forward&lt;P&gt;(x)</tt></ins>.
<p/>
<del>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 map. 
Specifically, in such cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or <tt>mapped_type</tt> 
unless the conversion from <tt>P</tt> specifically requires it (e.g., if <tt>P</tt> is a <tt>tuple&lt;const key_type, mapped_type&gt;</tt>, 
then <tt>key_type</tt> must be <tt>CopyConstructible</tt>). The signature taking <tt>InputIterator</tt> parameters 
does not require <tt>CopyConstructible</tt> of either <tt>key_type</tt> or <tt>mapped_type</tt> if the dereferenced 
<tt>InputIterator</tt> returns a non-const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>. Otherwise <tt>CopyConstructible</tt> 
is required for both <tt>key_type</tt> and <tt>mapped_type</tt>.</del><br/>
<ins>? <em>Effects</em>: Inserts <tt>x</tt> converted to <tt>value_type</tt>. For the second form, the iterator <tt>position</tt> 
is a hint pointing to where the search should start.</ins>
<p/>
<ins>? <em>Returns</em>: An iterator that points to the element with key equivalent to the key of <tt>value_type(x)</tt>.</ins>
<p/>
<ins>? <em>Complexity</em>: Logarithmic in general, but amortized constant if <tt>x</tt> is inserted right before <tt>position</tt>.</ins>
<p/>
<ins>? <em>Remarks</em>: These signatures shall not participate in overload resolution unless <tt>P</tt> 
is implicitly convertible to <tt>value_type</tt>.</ins>
</p>
</blockquote></blockquote>
</li>
</ol>

</blockquote>

<p><i>[
2010 Batavia:
]</i></p>


<p>
We need <tt>is_convertible</tt>, not <tt>is_constructible</tt>, both in ordered and unordered containers. 
</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
The effects of these inserts can be concisely stated in terms of emplace().
Also, the correct term is "EmplaceConstructible", not "constructible".
</p>

<p>
New wording by Pablo, eliminating duplicate requirements already implied by the effects clause.  Move to Review.
</p>

<p><i>[
2011-10-02 Daniel comments and refines the proposed wording
]</i></p>


<blockquote><p>
Unfortunately the template constraints expressed as "<tt>P</tt> is implicitly convertible to <tt>value_type</tt>"
reject the intended effect to support move-only key types, which was the original intention when
the library became move-enabled through the rvalue-reference proposals by Howard (This can clearly be deduced
from existing carefully selected wording that emphasizes that <tt>CopyConstructible</tt> is only required
for special situations involving lvalues or const rvalues as arguments). The root of the problem is based
on current core rules, where an "implicitly converted" value has copy-initialization semantics. Consider
a move-only key type <tt>KM</tt>, some mapped type <tt>T</tt>, and a source value <tt>p</tt> of type <tt>P</tt> 
equal to <tt>std::pair&lt;KM, T&gt;</tt>, this is equivalent to:
</p>
<blockquote><pre>
std::pair&lt;const KM, T&gt; dest = std::move(p);
</pre></blockquote>
<p>
Now 8.5 [dcl.init] p16 b6 sb2 says that the effects of this heterogeneous copy-initialization (<tt>p</tt>
has a different type than <tt>dest</tt>) are as-if a temporary of the target type <tt>std::pair&lt;const KM, T&gt;</tt>
is produced from the rvalue <tt>p</tt> of type <tt>P</tt> (which is fine), and this temporary is used to initialize 
<tt>dest</tt>. This second step cannot succeed, because we cannot move from <tt>const KM</tt> to <tt>const KM</tt>. This 
means that <tt>std::is_convertible&lt;P, std::pair&lt;const KM, T&gt;&gt;::value</tt> is false.
<p/>
But the actual code that is required (with the default allocator) is simply a direct-initialization
from <tt>P</tt> to <tt>value_type</tt>, so imposing an implicit conversion is more than necessary. Therefore
I strongly recommend to reduce the "overload participation" constraint to  
<tt>std::is_constructible&lt;std::pair&lt;const KM, T&gt;, P&gt;::value</tt> instead. This change is the
only change that has been performed to the previous proposed wording from Pablo shown below. 
</p></blockquote>

<p><i>[2012, Kona]</i></p>

<p>
Moved to Tentatively Ready by the post-Kona issues processing subgroup, after much discussion
on Daniel's analysis of Copy Initialization and move semantics, which we ultimately agreed with.
</p>



<p><b>Proposed resolution:</b></p>

<ol>
<li>Change 23.4.4.4 [map.modifiers] around p. 1 as indicated:
<blockquote><pre>
template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);
template &lt;class P&gt; <del>pair&lt;</del>iterator<del>, bool&gt;</del> insert(const_iterator position, P&amp;&amp; x);
</pre><blockquote>
<del>1 <em>Requires</em>: <tt>P</tt> shall be convertible to <tt>value_type</tt>.</del>
<p/>
<del>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 map. Specifically, in
such cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or <tt>mapped_type</tt> unless the conversion
from <tt>P</tt> specifically requires it (e.g., if <tt>P</tt> is a <tt>tuple&lt;const key_type, mapped_type&gt;</tt>, then <tt>key_type</tt>
must be <tt>CopyConstructible</tt>). The signature taking <tt>InputIterator</tt> parameters does not require
<tt>CopyConstructible</tt> of either <tt>key_type</tt> or <tt>mapped_type</tt> if the dereferenced <tt>InputIterator</tt> returns a
non-const rvalue <tt>pair&lt;key_type,mapped_type&gt;</tt>. Otherwise <tt>CopyConstructible</tt> is required for both
<tt>key_type</tt> and <tt>mapped_type</tt>.</del><br/>
<ins>? <em>Effects</em>: The first form is equivalent to
<tt>return emplace(std::forward&lt;P&gt;(x))</tt>.
The second form is equivalent to
<tt>return emplace_hint(position, std::forward&lt;P&gt;(x))</tt>.</ins>
<p/>
<ins>? <em>Remarks</em>: These signatures shall not participate in overload resolution unless 
<tt>std::is_constructible&lt;value_type, P&amp;&amp;&gt;::value</tt> is true.</ins>
<p/>
</blockquote></blockquote>
</li>
<li>Change 23.4.5.3 [multimap.modifiers] around p. 1 as indicated:
<blockquote><pre>
template &lt;class P&gt; iterator insert(P&amp;&amp; x);
template &lt;class P&gt; iterator insert(const_iterator position, P&amp;&amp; x);
</pre><blockquote>
<del>1 <em>Requires</em>: <tt>P</tt> shall be convertible to <tt>value_type</tt>.</del>
<p/>
<del>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 map. 
Specifically, in such cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or <tt>mapped_type</tt> 
unless the conversion from <tt>P</tt> specifically requires it (e.g., if <tt>P</tt> is a <tt>tuple&lt;const key_type, mapped_type&gt;</tt>, 
then <tt>key_type</tt> must be <tt>CopyConstructible</tt>). The signature taking <tt>InputIterator</tt> parameters 
does not require <tt>CopyConstructible</tt> of either <tt>key_type</tt> or <tt>mapped_type</tt> if the dereferenced 
<tt>InputIterator</tt> returns a non-const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>. Otherwise <tt>CopyConstructible</tt> 
is required for both <tt>key_type</tt> and <tt>mapped_type</tt>.</del><br/>
<ins>? <em>Effects</em>: The first form is equivalent to
<tt>return emplace(std::forward&lt;P&gt;(x))</tt>.
The second form is equivalent to
<tt>return emplace_hint(position, std::forward&lt;P&gt;(x))</tt>.</ins>
<p/>
<ins>? <em>Remarks</em>: These signatures shall not participate in overload resolution unless 
<tt>std::is_constructible&lt;value_type, P&amp;&amp;&gt;::value</tt> is true.</ins>
<p/>
</blockquote></blockquote>
</li>
<li>Change 23.5.4.4 [unord.map.modifers] around p. 1 as indicated:
<blockquote><pre>
template &lt;class P&gt;
pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);
</pre>
<blockquote>
<del>1 <em>Requires</em>: <tt>value_type</tt> is constructible from <tt>std::forward&lt;P&gt;(obj)</tt>.</del>
<p/>
2 <em>Effects</em>:
<ins>equivalent to <tt>return emplace(std::forward&lt;P&gt;(obj))</tt>.</ins>
<del>Inserts obj converted to <tt>value_type</tt> if and only if there is no element in the container with
key equivalent to the key of <tt>value_type(obj)</tt>.</del>
<p/>
<del>3 <em>Returns</em>: The bool component of the returned pair object indicates whether the insertion took place
and the iterator component points to the element with key equivalent to the key of <tt>value_type(obj)</tt>.</del>
<p/>
<del>4 <em>Complexity</em>: Average case O(1), worst case O(size()).</del>
<p/>
<del>5</del><ins>3</ins> <em>Remarks</em>: This signature shall not participate in overload resolution unless 
<del><tt>P</tt> is implicitly convertible to <tt>value_type</tt></del><ins><tt>std::is_constructible&lt;value_type, 
P&amp;&amp;&gt;::value</tt> is true</ins>.
<p/>
</blockquote>
<pre>template &lt;class P&gt;
iterator insert(const_iterator hint, P&amp;&amp; obj);
</pre>
<blockquote>
<del>6 <em>Requires</em>: <tt>value_type</tt> is constructible from <tt>std::forward&lt;P&gt;(obj)</tt>.</del>
<p/>
<del>7</del><em>?</em> <em>Effects</em>:
<ins>equivalent to <tt>return emplace_hint(hint, std::forward&lt;P&gt;(obj))</tt>.</ins>
<del>Inserts obj converted to <tt>value_type</tt> if and only if there is no element in the container with
key equivalent to the key of <tt>value_type(obj)</tt>. The iterator hint is a hint pointing to where the
search should start.</del>
<p/>
<del>8 <em>Returns</em>: An iterator that points to the element with key equivalent to the key of 
<tt>value_type(obj)</tt>.</del>
<p/>
<del>9 <em>Complexity</em>: Average case O(1), worst case O(size()).</del>
<p/>
<del>10</del><em>?</em> <em>Remarks</em>: This signature shall not participate in overload resolution unless 
<del><tt>P</tt> is implicitly convertible to <tt>value_type</tt></del><ins><tt>std::is_constructible&lt;value_type, 
P&amp;&amp;&gt;::value</tt> is true</ins>.
</blockquote></blockquote>
</li>
<li>Change 23.5.5.3 [unord.multimap.modifers] around p. 1 as indicated:
<blockquote><pre>
template &lt;class P&gt;
iterator insert(P&amp;&amp; obj);
</pre>
<blockquote>
<del>1 <em>Requires</em>: <tt>value_type</tt> is constructible from <tt>std::forward&lt;P&gt;(obj)</tt>.</del>
<p/>
2 <em>Effects</em>:
<ins>equivalent to <tt>return emplace(std::forward&lt;P&gt;(obj))</tt>.</ins>
<del>Inserts obj converted to <tt>value_type</tt>.</del>
<p/>
<del>3 <em>Returns</em>: An iterator that points to the element with key equivalent to the key of <tt>value_type(obj)</tt>.</del>
<p/>
<del>4 <em>Complexity</em>: Average case O(1), worst case O(size()).</del>
<p/>
<del>5</del><ins>3</ins> <em>Remarks</em>: This signature shall not participate in overload resolution 
unless <del><tt>P</tt> is implicitly convertible to <tt>value_type</tt></del><ins><tt>std::is_constructible&lt;value_type, 
P&amp;&amp;&gt;::value</tt> is true</ins>.
</blockquote>
<pre>
template &lt;class P&gt;
iterator insert(const_iterator hint, P&amp;&amp; obj);
</pre>
<blockquote>
<del>6 <em>Requires</em>: <tt>value_type</tt> is constructible from <tt>std::forward&lt;P&gt;(obj)</tt>.</del>
<p/>
<del>7</del><em>?</em> <em>Effects</em>:
<ins>equivalent to <tt>return emplace_hint(hint, std::forward&lt;P&gt;(obj))</tt>.</ins>
<del>Inserts obj converted to <tt>value_type</tt>. The iterator hint is a hint pointing to where the search
should start.</del>
<p/>
<del>8 <em>Returns</em>: An iterator that points to the element with key equivalent to the key of <tt>value_type</tt>(obj).</del>
<p/>
<del>9 <em>Complexity</em>: Average case O(1), worst case O(size()).</del>
<p/>
<del>10</del><ins><em>?</em></ins> <em>Remarks</em>: This signature shall not participate in overload resolution 
unless <del><tt>P</tt> is implicitly convertible to <tt>value_type</tt></del><ins><tt>std::is_constructible&lt;value_type, 
P&amp;&amp;&gt;::value</tt> is true</ins>.
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2011"></a>2011. Unexpected output required of strings</h3>
<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> James Kanze <b>Opened:</b> 2010-07-23 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#string.io">issues</a> in [string.io].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
What should the following code output? 
</p>

<blockquote><pre>
#include &lt;string&gt;
#include &lt;iostream&gt;
#include &lt;iomanip&gt;

int main() 
{ 
   std::string test("0X1Y2Z"); 
   std::cout.fill('*'); 
   std::cout.setf(std::ios::internal, std::ios::adjustfield); 
   std::cout &lt;&lt; std::setw(8) &lt;&lt; test &lt;&lt; std::endl; 
} 
</pre></blockquote>

<p>
I would expect "<tt>**0X1Y2Z</tt>", and this is what the compilers I have access
to (VC++, g++ and Sun CC) do.  But according to the standard, it should be
"<tt>0X**1Y2Z</tt>":
</p>

<p>
21.4.8.9 [string.io]&#47;5: 
</p>

<blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
  basic_ostream&lt;charT, traits&gt;&amp;
    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
</pre><blockquote><p>
<i>Effects:</i> Behaves as a formatted output function (27.7.3.6.1 [ostream.formatted.reqmts]). After constructing 
a <tt>sentry</tt> object, if this object returns <tt>true</tt> when converted to a value of type <tt>bool</tt>, 
determines padding as described in 22.4.2.2.2 [facet.num.put.virtuals], then inserts the resulting sequence of
characters seq as if by calling <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of 
<tt>os.width()</tt> and <tt>str.size()</tt>; then calls <tt>os.width(0)</tt>.
</p></blockquote>
</blockquote>

<p>
22.4.2.2.2 [facet.num.put.virtuals]&#47;5: 
</p>

<blockquote>
<p>
[&hellip;] 
</p>

<p>
<b>Stage 3:</b> A local variable is initialized as
</p>

<blockquote><pre>
fmtflags adjustfield= (flags &amp; (ios_base::adjustfield));
</pre></blockquote>

<p>
The location of any padding is determined according to Table 88. 
</p>

<p>
If <tt>str.width()</tt> is nonzero and the number of <tt>charT</tt>'s in the
sequence after stage 2 is less than <tt>str.width()</tt>, then enough fill
characters are added to the sequence at the position indicated for padding to
bring the length of the sequence to <tt>str.width()</tt>. <tt>str.width(0)</tt>
is called.
</p>

<table border="1">
<caption>Table 88 &mdash; Fill padding</caption>
<tr>
<th>State</th>
<th>Location</th>
</tr>

<tr>
<td><tt>adjustfield == ios_base::left</tt></td>
<td>pad after</td>
</tr>

<tr>
<td><tt>adjustfield == ios_base::right</tt></td>
<td>pad before</td>
</tr>

<tr>
<td><tt>adjustfield == internal</tt> and a sign occurs in the representation</td>
<td>pad after the sign</td>
</tr>

<tr>
<td><tt>adjustfield == internal</tt> and representation after stage 1 began with 0x or 0X</td>
<td>pad after x or X</td>
</tr>

<tr>
<td><i>otherwise</i></td>
<td>pad before</td>
</tr>
</table>

</blockquote>

<p>
Although it's not 100% clear what "the sequence after stage 2" should mean here,
when there is no stage 2, the only reasonable assumption is that it is the
contents of the string being output.  In the above code, the string being output
is "<tt>0X1Y2Z</tt>", which starts with "<tt>0X</tt>", so the padding should be
inserted "after x or X", and not before the string. I believe that this is a
defect in the standard, and not in the three compilers I tried.
</p>

<p><i>[
2010 Batavia (post meeting session)
]</i></p>

<p>
Consensus that all known implementations are consistent, and disagree with the
standard. Preference is to fix the standard before implementations start trying
to conform to the current spec, as the current implementations have the preferred
form. Howard volunteered to drught for Madrid, move to Open.
</p>

<p><i>[2011-03-24 Madrid meeting]</i></p>


<p>
Daniel Kr&uuml;gler volunteered to provide wording, interacting with Dietmar and
Bill. 
</p>

<p><i>[2011-06-24 Daniel comments and provides wording]</i></p>


<p>
The same problem applies to the output provided by <tt>const char*</tt> and similar
character sequences as of 27.7.3.6.4 [ostream.inserters.character] p. 5. and even for
single character output (!) as described in 27.7.3.6.4 [ostream.inserters.character] p. 1,
just consider the character value '-' where '-' is the sign character. In this case
Table 91 &mdash; "Fill padding" requires to pad after the sign, i.e. the output
for the program
</p>
<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;iomanip&gt;

int main() 
{ 
   char c = '-'; 
   std::cout.fill('*'); 
   std::cout.setf(std::ios::internal, std::ios::adjustfield); 
   std::cout &lt;&lt; std::setw(2) &lt;&lt; c &lt;&lt; std::endl; 
} 
</pre></blockquote>

<p>
According to the current wording this program should output "<tt>-*</tt>", but
all tested implementations output "<tt>*-</tt>" instead.

<p/>
I suggest to replace the reference to 22.4.2.2.2 [facet.num.put.virtuals] in all three places. 
It is not very complicated to describe the padding rules for simple character sequences "inline". 
A similar approach is used as for the <tt>money_put</tt> functions.
</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
Move to Review, the resolution seems correct but it would be nice if some factoring of the
common words were proposed.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Moved to Tentatively Ready by the post-Kona issues processing subgroup.
</p>
<p>
While better factoring of the common words is desirable, it is also editorial and
should not hold up the progress of this issue.  As the edits impact two distinct
clauses, it is not entirely clear what a better factoring should look like.
</p>



<p><b>Proposed resolution:</b></p>
<p>
The new wording refers to the FDIS numbering.
</p>
<ol>
<li><p>Change 21.4.8.9 [string.io]&#47;5 as indicated:</p>
<blockquote><pre>
template&lt;class charT, class traits, class Allocator&gt;
  basic_ostream&lt;charT, traits&gt;&amp;
    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
</pre><blockquote><p>
-5- <i>Effects</i>: Behaves as a formatted output function ([ostream.formatted.reqmts]). After constructing a sentry object,
if this object returns <tt>true</tt> when converted to a value of type <tt>bool</tt>, determines padding as <del>described
in [facet.num.put.virtuals],</del><ins>follows: A <tt>charT</tt> character sequence is produced, initially consisting of 
the elements defined by the range <tt>[str.begin(), str.end())</tt>. If <tt>str.size()</tt> is less than <tt>os.width()</tt>, 
then enough copies of <tt>os.fill()</tt> are added to this sequence as necessary to pad to a width of <tt>os.width()</tt> 
characters. If <tt>(os.flags() &amp; ios_base::adjustfield) == ios_base::left</tt> is <tt>true</tt>, the fill characters 
are placed after the character sequence; otherwise, they are placed before the character sequence. T</ins><del>t</del>hen 
inserts the resulting sequence of characters <tt>seq</tt> as if by calling <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where 
<tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>; then calls <tt>os.width(0)</tt>.
</p></blockquote></blockquote>
</li>

<li><p>Change 27.7.3.6.4 [ostream.inserters.character]&#47;1 as indicated (An additional editorial
fix is suggested for the first prototype declaration):</p>
<blockquote><pre>
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; out,
                                          charT c<del>}</del><ins>)</ins>;
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; out,
                                          char c);
<i>// specialization</i>
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         char c);
<i>// signed and unsigned</i>
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         signed char c);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         unsigned char c);
</pre><blockquote><p>
-1- <i>Effects</i>: Behaves like a formatted inserter (as described in [ostream.formatted.reqmts]) of <tt>out</tt>. 
After a sentry object is constructed it inserts characters. In case <tt>c</tt> has type <tt>char</tt> and the 
character type of the stream is not <tt>char</tt>, then the character to be inserted is <tt>out.widen(c)</tt>; 
otherwise the character is <tt>c</tt>. Padding is determined as <del>described in [facet.num.put.virtuals]</del><ins>follows: 
A character sequence is produced, initially consisting of the insertion character. If <tt>out.width()</tt> is greater
than one, then enough copies of <tt>out.fill()</tt> are added to this sequence as necessary to pad to a width of 
<tt>out.width()</tt> characters. If <tt>(out.flags() &amp; ios_base::adjustfield) == ios_base::left</tt> is <tt>true</tt>, 
the fill characters are placed after the insertion character; otherwise, they are placed before the insertion 
character</ins>. <del><tt>width(0)</tt> is called.</del> The insertion character and any required padding are 
inserted into <tt>out</tt><ins>; then calls <tt>os.width(0)</tt></ins>.
</p></blockquote></blockquote>
</li>

<li><p>Change 27.7.3.6.4 [ostream.inserters.character]&#47;5 as indicated:</p>
<blockquote><pre>
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; out,
                                          const charT* s);
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; out,
                                          const char* s);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         const char* s);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         const signed char* s);
template&lt;class traits&gt;
  basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char,traits&gt;&amp; out,
                                         const unsigned char* s);
</pre><blockquote><p>
[&hellip;]
<p/>
-5- Padding is determined as <del>described in [facet.num.put.virtuals]. The <tt>n</tt> characters starting at <tt>s</tt> 
are widened using <tt>out.widen</tt> ([basic.ios.members])</del><ins>follows: A character sequence is produced, initially 
consisting of the elements defined by the <tt>n</tt> characters starting at <tt>s</tt> widened using 
<tt>out.widen</tt> ([basic.ios.members]). If <tt>n</tt> is less than <tt>out.width()</tt>, then enough copies of 
<tt>out.fill()</tt> are added to this sequence as necessary to pad to a width of <tt>out.width()</tt> characters. 
If <tt>(out.flags() &amp; ios_base::adjustfield) == ios_base::left</tt> is <tt>true</tt>, the fill characters are 
placed after the character sequence; otherwise, they are placed before the character sequence</ins>. The 
widened characters and any required padding are inserted into <tt>out</tt>. Calls <tt>width(0)</tt>.
</p></blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2012"></a>2012. Associative maps should insert <tt>pair</tt>, not <tt>tuple</tt></h3>
<p><b>Section:</b> 23.4 [associative] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2010-10-29 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#associative">active issues</a> in [associative].</p>
<p><b>View all other</b> <a href="lwg-index.html#associative">issues</a> in [associative].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I'm seeing something strange in the paragraphs 23.4.4.4 [map.modifiers] and 23.4.5.3 [multimap.modifiers]:
they both talk about <tt>tuple&lt;const key_type, mapped_type&gt;</tt> but I think they
should be talking about <tt>pair&lt;const key_type, mapped_type&gt;</tt> because, among
other reasons, a <tt>tuple</tt> is not convertible to a <tt>pair</tt>. If I replace <tt>tuple</tt>
with <tt>pair</tt> everything makes sense to me.
<p/>
The proposed resolution is obvious. 
</p>

<p><i>[
2010-11-07 Daniel comments
]</i></p>


<p>
This is by far not the only necessary fix within both sub-clauses. For details see the 2010-10-29 comment in 
<a href="lwg-active.html#2005">2005</a>.
</p>

<p><i>[2011-03-24 Madrid meeting]</i></p>


<p>
Paolo: Don't think we can do it now.
<p/>
Daniel K: Agrees. 
</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
Consensus that this issue will be resolved by <a href="lwg-active.html#2005">2005</a>, but held open until that issue is resolved.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Apply the resolution proposed by the 2010-10-29 comment in <a href="lwg-active.html#2005">2005</a>.
</p>





<hr>
<h3><a name="2013"></a>2013. Do library implementers have the freedom to add <tt>constexpr</tt>?</h3>
<p><b>Section:</b> 17.6.5.6 [constexpr.functions] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2010-11-12 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>
<p>Suppose that a particular function is not tagged as constexpr in the standard,
but that, in some particular implementation, it is possible to write it within
the constexpr constraints. If an implementer tags such a function as constexpr,
is that a violation of the standard or is it a conforming extension?</p>

<p>There are two questions to consider. First, is this allowed under the
as-if rule? Second, if it does not fall under as-if, is there
(and should there be) any special license granted to implementers
to do this anyway, sort of the way we allow elision of copy constructors
even though it is detectable by users?</p>

<p>I believe that this does not fall under "as-if", so implementers
probably don't have that freedom today. I suggest changing the WP
to grant it. Even if we decide otherwise, however, I suggest that
we make it explicit.</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
General surprise this was not already in 'Ready' status, and so moved.
</p>

<p><i>[
2012 Kona
]</i></p>


<p>
Some concern expressed when presented to full committee for the vote to WP status
that this issue had been resolved without sufficient thought of the consequences
for diverging library implementations, as users may use SFINAE to observe
different behavior from otherwise identical code.  Issue moved back to Review
status, and will be discussed again in Portland with a larger group.

Note for Portland: John Spicer has agreed to represent Core's concerns during
any such discussion within LWG.
</p>



<p><b>Proposed resolution:</b></p>
<p><i>In 17.6.4.6 [constexpr.functions], change paragraph 1 to:</i></p>

<blockquote><p>
<ins>This standard explicitly requires that certain standard library functions
are <tt>constexpr</tt> [dcl.constexpr].
Additionally, an implementation may declare any function to be <tt>constexpr</tt>
if that function's definition satisfies the necessary constraints.</ins>
Within any header that provides any non-defining declarations of <tt>constexpr</tt>
functions or constructors an implementation shall provide corresponding definitions. 
</p></blockquote>






<hr>
<h3><a name="2016"></a>2016. <tt>Allocators</tt> must be no-throw <i>swappable</i></h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2010-11-17 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
During the Batavia meeting it turned out that there is a definition
hole for types satisfying the <tt>Allocators</tt> requirements: The problem
became obvious when it was discussed whether all <tt>swap</tt> functions 
of <tt>Containers</tt> with internal data handles can be safely tagged
with <tt>noexcept</tt> or not. While it is correct that the implicit
<tt>swap</tt> function of an allocator is required to be a no-throw
operation (because move/copy-constructors and assignment operators are
required to be no-throw functions), there are no such requirements
for specialized <tt>swap</tt> overloads for a particular allocator.
<p/>
But this requirement is essential because the <tt>Containers</tt> are
required to support <i>swappable</i> <tt>Allocators</tt>, when the value
<tt>allocator_traits&lt;&gt;::propagate_on_container_swap</tt> evaluates
to <tt>true</tt>.
</p>
<p><i>[2011-02-10 Alberto, Daniel, and Pablo collaborated on the proposed wording]</i></p>

<p>
The proposed resolution (based on N3225) attempts to solve the following problems:
</p>
<ol>
<li>Table 44 &mdash; Allocator requirements, expression rows 
<tt>X::propagate_on_container_copy_assignment</tt>, <tt>X::propagate_on_container_move_assignment</tt>, and
<tt>X::propagate_on_container_swap</tt> only describe operations, but no requirements. In fact, if and only
if these compile-time predicates evaluate to <tt>true</tt>, the <em>additional</em> requirements
<tt>CopyAssignable</tt>,  no-throw <tt>MoveAssignable</tt>, and no-throw lvalue <tt>Swappable</tt>, 
respectively, are imposed on the allocator types.</li>
<li>23.2.1 [container.requirements.general] p. 9 misses to refer to the correct swap conditions: The current wording does not relate to
17.6.3.2 [swappable.requirements] as it should and omits to mention that lvalues shall be swapped. Additional there is one
situation described twice in p. 8 and p. 9 (undefined behaviour unless <tt>a.get_allocator() == b.get_allocator()</tt>
or <tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_swap::value == true</tt>), which should be cleaned up.</li>
</ol>

<p><i>[2011-04-08 Pablo comments]</i></p>

<p>
I'm implementing a version of list now and I actually do find it impossible to write an exception-safe assignment 
operator unless I can assume that allocator assignment does not throw.  (The problem is that I use a sentinel node 
and I need to allocate a new sentinel using the new allocator without destroying the old one -- then swap the 
allocator and sentinel pointer in atomically, without risk of an exception leaving one inconsistent with the other.
<p/>
Please update the proposed resolution to add the nothrow requirement to copy-assignment.
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Adapt the following three rows from Table 44 &mdash; Allocator requirements:
</p>

<blockquote>
<table border="1">
<caption>Table 44 &mdash; Allocator requirements</caption>
<tr>
<th>
Expression
</th>

<th>
Return type
</th>

<th>
Assertion/note<br/>pre-/post-condition
</th>

<th>
Default
</th>

</tr>

<tr>
<td><tt>X::propagate_on_container_copy_assignment</tt></td>

<td>Identical to or derived from <tt>true_type</tt><br/>
or <tt>false_type</tt></td>

<td><tt>true_type</tt> only if an allocator of type <tt>X</tt> should be copied<br/> 
when the client container is copy-assigned. <ins>See Note B, below.</ins></td>

<td><tt>false_type</tt></td>
</tr>

<tr>
<td><tt>X::propagate_on_container_move_assignment</tt></td>

<td>Identical to or derived from <tt>true_type</tt><br/>
or <tt>false_type</tt></td>

<td><tt>true_type</tt> only if an allocator of type <tt>X</tt> should be moved<br/>
when the client container is move-assigned. <ins>See Note B, below.</ins></td>

<td><tt>false_type</tt></td>
</tr>

<tr>
<td><tt>X::propagate_on_container_swap</tt></td>

<td>Identical to or derived from <tt>true_type</tt><br/>
or <tt>false_type</tt></td>

<td><tt>true_type</tt> only if an allocator of type <tt>X</tt> should be swapped<br/>
when the client container is swapped. <ins>See Note B, below.</ins></td>

<td><tt>false_type</tt></td>
</tr>

</table>
</blockquote>


</li>

<li>
<p>Following 17.6.3.5 [allocator.requirements] p. 3 insert a new normative paragraph:</p>

<blockquote><p>
<ins>Note B: If <tt>X::propagate_on_container_copy_assignment::value</tt> is true, <tt>X</tt> shall 
satisfy the <tt>CopyAssignable</tt> requirements (Table 39  [copyassignable]) and the copy 
operation shall not throw exceptions. If <tt>X::propagate_on_container_move_assignment::value</tt> is 
true, <tt>X</tt> shall satisfy the <tt>MoveAssignable</tt> requirements (Table 38  [moveassignable]) 
and the move operation shall not throw exceptions. If <tt>X::propagate_on_container_swap::value</tt> is 
true, lvalues of <tt>X</tt> shall be swappable (17.6.3.2 [swappable.requirements]) and the <tt>swap</tt> 
operation shall not throw exceptions.</ins>
</p></blockquote>
</li>

<li>
<p>Modify 23.2.1 [container.requirements.general] p. 8 and p. 9 as indicated:</p>

<blockquote><p>
8 - [..] The allocator may be replaced only via assignment or <tt>swap()</tt>. Allocator replacement is 
performed by copy assignment, move assignment, or swapping of the allocator only if 
<tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_copy_assignment::value</tt>,
<tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_move_assignment::value</tt>, 
or <tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_swap::value</tt> is true 
within the implementation of the corresponding container operation. <del>The behavior of a call to 
a container's <tt>swap</tt> function is undefined unless the objects being swapped have allocators that compare 
equal or <tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_swap::value</tt> is true</del>. In all 
container types defined in this Clause, the member <tt>get_allocator()</tt> returns a copy of the allocator 
used to construct the container or, if that allocator has been replaced, a copy of the most recent replacement.
<p/>
9 - The expression <tt>a.swap(b)</tt>, for containers <tt>a</tt> and <tt>b</tt> of a standard container type 
other than <tt>array</tt>, shall exchange the values of <tt>a</tt> and <tt>b</tt> without invoking any move, 
copy, or swap operations on the individual container elements. <ins>Lvalues of a</ins><del>A</del>ny <tt>Compare</tt>, 
<tt>Pred</tt>, or <tt>Hash</tt> object<del>s</del> belonging to <tt>a</tt> and <tt>b</tt> shall be swappable 
and shall be exchanged by <del>unqualified calls to non-member</del> <ins>calling</ins> <tt>swap</tt> 
<ins>as described in 17.6.3.2 [swappable.requirements]</ins>. If <tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_swap::value</tt> 
is <tt>true</tt>, then <ins>lvalues of <tt>allocator_type</tt> shall be swappable and</ins> the allocators of <tt>a</tt> and 
<tt>b</tt> shall also be exchanged using <ins>a</ins> <del>an unqualified call to non-member</del> 
<tt>swap</tt> <ins>call</ins> <ins>as described in 17.6.3.2 [swappable.requirements]</ins>. Otherwise, 
<del>they</del><ins>the allocators</ins> shall not be swapped, and the behavior is undefined unless
<tt>a.get_allocator() == b.get_allocator()</tt>. Every iterator referring to an element in one container before
the swap shall refer to the same element in the other container after the swap. It is unspecified whether an
iterator with value <tt>a.end()</tt> before the swap will have value <tt>b.end()</tt> after the swap.
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="2018"></a>2018. <tt>regex_traits::isctype</tt> Returns clause is wrong</h3>
<p><b>Section:</b> 28.7 [re.traits] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2010-11-16 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#re.traits">issues</a> in [re.traits].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>28.7 [re.traits] p. 12 says:</p>

<blockquote><p>
returns true if <tt>f</tt> bitwise or&#39;ed with the result of calling
<tt>lookup_classname</tt> with an iterator pair that designates the character
sequence &quot;w&quot; is not equal to <tt>0</tt> and <tt>c == '_'</tt>
</p></blockquote>

<p>
If the bitmask value corresponding to &quot;w&quot; has a non-zero value (which
it must do) then the bitwise or with any value is also non-zero, and
so <tt>isctype('_', f)</tt> returns true for any <tt>f</tt>. Obviously this is wrong,
since <tt>'_'</tt> is not in every <tt>ctype</tt> category.
</p>

<p>
There&#39;s a similar problem with the following phrases discussing the
&quot;blank&quot; char class.
</p>

<p><i>[2011-05-06: Jonathan Wakely comments and provides suggested wording]</i></p>


<p>
DR <a href="lwg-defects.html#2019">2019</a> added <tt>isblank</tt> support to <tt>&lt;locale&gt;</tt> which simplifies the
definition of <tt>regex_traits::isctype</tt> by removing the special case for the "blank" class.
<p/>
My suggestion for 2018 is to add a new table replacing the lists of
recognized names in the Remarks clause of <tt>regex_traits::lookup_classname</tt>. 
I then refer to that table in the Returns clause of <tt>regex_traits::isctype</tt> 
to expand on the "in an unspecified manner" wording which is too vague. The conversion 
can now be described using the "is set" term defined by 17.5.2.1.3 [bitmask.types] and
the new table to convey the intented relationship between e.g.
[[:digit:]] and <tt>ctype_base::digit</tt>, which is not actually stated in the
FDIS.
<p/>
The effects of <tt>isctype</tt> can then most easily be described in code,
given an "exposition only" function prototype to do the not-quite-so-unspecified conversion 
from <tt>char_class_type</tt> to <tt>ctype_base::mask</tt>.
<p/>
The core of LWG 2018 is the "bitwise or'ed" wording which gives the
wrong result, always evaluating to true for all values of <tt>f</tt>. That is
replaced by the condition <tt>(f&amp;x) == x</tt> where <tt>x</tt> is the result of calling
<tt>lookup_classname</tt> with "w".  I believe that's necessary, because the
"w" class could be implemented by an internal "underscore" class i.e.
<tt>x = _Alnum|_Underscore</tt> in which case <tt>(f&amp;x) != 0</tt> would give the wrong
result when <tt>f==_Alnum</tt>.
<p/>
The proposed resolution also makes use of <tt>ctype::widen</tt> which addresses
the problem that the current wording only talks about "w" and '_' which assumes 
<tt>charT</tt> is char.  There's still room for improvement here:
the regex grammar in 28.13 [re.grammar] says that the class names in the
table should always be recognized, implying that e.g. U"digit" should
be recognized by <tt>regex_traits&lt;char32_t&gt;</tt>, but the specification of
<tt>regex_traits::lookup_classname</tt> doesn't cover that, only mentioning
<tt>char</tt> and <tt>wchar_t</tt>.  Maybe the table should not distinguish narrow and
wide strings, but should just have one column and add wording to say
that <tt>regex_traits</tt> widens the name as if by using <tt>use_facet&lt;ctype&lt;charT&gt;&gt;::widen()</tt>.
<p/>
Another possible improvement would be to allow additional
implementation-defined extensions in <tt>isctype</tt>. An implementation is
allowed to support additional class names in <tt>lookup_classname</tt>, e.g.
[[:octdigit:]] for [0-7] or [[:bindigit:]] for [01], but the current
definition of isctype provides no way to use them unless <tt>ctype_base::mask</tt> 
also supports them.
</p>

<p><i>[2011-05-10: Alberto and Daniel perform minor fixes in the P&#47;R]</i></p>


<p><i>[
2011 Bloomington
]</i></p>


<p>
Consensus that this looks to be a correct solution, and the presentation as a table is a big improvement.
</p>

<p>
Concern that the middle section wording is a little muddled and confusing, Stefanus volunteered to reword.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Modify 28.7 [re.traits] p. 10 as indicated:</p>
<blockquote><pre>
template &lt;class ForwardIterator&gt;
  char_class_type lookup_classname(
    ForwardIterator first, ForwardIterator last, bool icase = false) const;
</pre><blockquote><p>
-9- <i>Returns</i>: an unspecified value that represents the character classification named by the character
sequence designated by the iterator range [<tt>first</tt>,<tt>last</tt>). If the parameter <tt>icase</tt> is true then the
returned mask identifies the character classification without regard to the case of the characters being
matched, otherwise it does honor the case of the characters being matched.(footnote 335) The value returned shall
be independent of the case of the characters in the character sequence. If the name is not recognized
then returns a value that compares equal to 0.
<p/>
-10- <i>Remarks</i>: For <tt>regex_traits&lt;char&gt;</tt>, at least the <del>names "d", "w", "s", "alnum", "alpha", "blank",
"cntrl", "digit", "graph", "lower", "print", "punct", "space", "upper" and "xdigit"</del><ins>narrow character
names in Table X</ins> shall be recognized. For <tt>regex_traits&lt;wchar_t&gt;</tt>, at least the <del>names L"d", L"w", 
L"s", L"alnum", L"alpha", L"blank", L"cntrl", L"digit", L"graph", L"lower", L"print", L"punct", L"space", L"upper" and 
L"xdigit"</del><ins>wide character names in Table X</ins> shall be recognized.
</p></blockquote></blockquote>
</li>

<li><p>Modify 28.7 [re.traits] p. 12 as indicated:</p>
<blockquote><pre>
bool isctype(charT c, char_class_type f) const;
</pre><blockquote><p>
-11- <i>Effects</i>: Determines if the character <tt>c</tt> is a member of the character classification represented by <tt>f</tt>.
<p/>
-12- <i>Returns</i>: Converts <tt>f</tt> into a value <tt>m</tt> of type <tt>std::ctype_base::mask</tt> in an unspecified manner, <del>and
returns true if <tt>use_facet&lt;ctype&lt;charT&gt; &gt;(getloc()).is(m, c)</tt> is true. Otherwise returns true
if <tt>f</tt> bitwise or'ed with the result of calling <tt>lookup_classname</tt> with an iterator pair that designates
the character sequence "w" is not equal to <tt>0</tt> and <tt>c == '_'</tt>, or if <tt>f</tt> bitwise or'ed with the result of
calling <tt>lookup_classname</tt> with an iterator pair that designates the character sequence "blank" is not
equal to <tt>0</tt> and <tt>c</tt> is one of an implementation-defined subset of the characters for which 
<tt>isspace(c, getloc())</tt> returns true, otherwise returns false.</del><ins>except that when <tt>f</tt> represents 
membership of a character class named in Table X, the corresponding <tt>ctype_base::mask</tt> value shall be set in <tt>m</tt>. 
Given the function prototype</ins>
</p><blockquote><pre>
<ins>template&lt;class C&gt;
   ctype_base::mask convert(typename regex_traits&lt;C&gt;::char_class_type);</ins>
</pre></blockquote>
<p><ins>the result is determined as if by</ins>
</p><blockquote><pre><ins>
ctype_base::mask m = convert&lt;charT&gt;(f);
const ctype&lt;charT&gt;&amp; ct = use_facet&lt;ctype&lt;charT&gt; &gt;(getloc());
if (ct.is(m, c))
  return true;
charT w[1] = { ct.widen('w') };
char_class_type x = lookup_classname(w, w+1);
if ((f&amp;x) == x &amp;&amp; c == ct.widen('_'))
  return true;
return false;
</ins></pre></blockquote>
<p><ins>[<i>Example</i>:</ins>
</p><blockquote><pre><ins>
regex_traits&lt;char&gt; t;
string d("d");
string u("upper");
regex_traits&lt;char&gt;::char_class_type f;
f = t.lookup_classname(d.begin(), d.end());
f |= t.lookup_classname(u.begin(), u.end());
ctype_base::mask m = convert&lt;char&gt;(f); // m == ctype_base::digit|ctype_base::upper
</ins></pre></blockquote>
<p><ins>&mdash; <i>end example</i>]</ins></p>
<p><ins>[<i>Example</i>:</ins>
</p><blockquote><pre><ins>
regex_traits&lt;char&gt; t;
string w("w");
regex_traits&lt;char&gt;::char_class_type f;
f = t.lookup_classname(w.begin(), w.end());
t.isctype('A', f); // returns true
t.isctype('_', f); // returns true
t.isctype(' ', f); // returns false
</ins></pre></blockquote>
<p><ins>&mdash; <i>end example</i>]</ins>
</p></blockquote></blockquote>
</li>

<li><p>At the end of [re.traits] add a new Table X &mdash; Character class names and corresponding ctype masks:</p>

<blockquote>
<table border="1">
<caption>Table X &mdash; Character class names and corresponding ctype masks</caption>

<tr>
<th>Narrow character name</th>
<th>Wide character name</th>
<th>Corresponding <tt>ctype_base::mask</tt> value</th>
</tr>
 
<tr>
<td><tt>"alnum"</tt></td>
<td><tt>L"alnum"</tt></td>
<td><tt>ctype_base::alnum</tt></td>
</tr>

<tr>
<td><tt>"alpha"</tt></td>
<td><tt>L"alpha"</tt></td>
<td><tt>ctype_base::alpha</tt></td>
</tr>

<tr>
<td><tt>"blank"</tt></td>
<td><tt>L"blank"</tt></td>
<td><tt>ctype_base::blank</tt></td>
</tr>

<tr>
<td><tt>"cntrl"</tt></td>
<td><tt>L"cntrl"</tt></td>
<td><tt>ctype_base::cntrl</tt></td>
</tr>

<tr>
<td><tt>"digit"</tt></td>
<td><tt>L"digit"</tt></td>
<td><tt>ctype_base::digit</tt></td>
</tr>

<tr>
<td><tt>"d"</tt></td>
<td><tt>L"d"</tt></td>
<td><tt>ctype_base::digit</tt></td>
</tr>

<tr>
<td><tt>"graph"</tt></td>
<td><tt>L"graph"</tt></td>
<td><tt>ctype_base::graph</tt></td>
</tr>

<tr>
<td><tt>"lower"</tt></td>
<td><tt>L"lower"</tt></td>
<td><tt>ctype_base::lower</tt></td>
</tr>

<tr>
<td><tt>"print"</tt></td>
<td><tt>L"print"</tt></td>
<td><tt>ctype_base::print</tt></td>
</tr>

<tr>
<td><tt>"punct"</tt></td>
<td><tt>L"punct"</tt></td>
<td><tt>ctype_base::punct</tt></td>
</tr>

<tr>
<td><tt>"space"</tt></td>
<td><tt>L"space"</tt></td>
<td><tt>ctype_base::space</tt></td>
</tr>

<tr>
<td><tt>"s"</tt></td>
<td><tt>L"s"</tt></td>
<td><tt>ctype_base::space</tt></td>
</tr>

<tr>
<td><tt>"upper"</tt></td>
<td><tt>L"upper"</tt></td>
<td><tt>ctype_base::upper</tt></td>
</tr>

<tr>
<td><tt>"w"</tt></td>
<td><tt>L"w"</tt></td>
<td><tt>ctype_base::alnum</tt></td>
</tr>

<tr>
<td><tt>"xdigit"</tt></td>
<td><tt>L"xdigit"</tt></td>
<td><tt>ctype_base::xdigit</tt></td>
</tr>

</table>
</blockquote> 
</li>
</ol>





<hr>
<h3><a name="2035"></a>2035. Output iterator requirements are broken</h3>
<p><b>Section:</b> 24.2.4 [output.iterators] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-02-27 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#output.iterators">active issues</a> in [output.iterators].</p>
<p><b>View all other</b> <a href="lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>During the Pittsburgh meeting the proposal <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>
became accepted because it fixed several severe issues related to the iterator specification. But the current working draft (N3225)
does not reflect all these changes. Since I'm unaware whether every correction can be done editorial, this issue is submitted to take
care of that. To give one example: All expressions of Table 108 &mdash; &quot;Output iterator requirements&quot; have a post-condition
that the iterator is incrementable. This is impossible, because it would exclude any finite sequence that is accessed by an output 
iterator, such as a pointer to a C array. The N3066 wording changes did not have these effects.
</p>

<p><i>[2011-03-01: Daniel comments:]</i></p>


<p>This issue has some overlap with the issue <a href="lwg-active.html#2038">2038</a> and I would prefer if we
could solve both at one location. I suggest the following approach:
</p>
<ol>
<li><p>The terms <tt><i>dereferencable</i></tt> and <tt><i>incrementable</i></tt> could be defined in a more
general way not restricted to iterators (similar to the concepts <tt>HasDereference</tt> and 
<tt>HasPreincrement</tt> from working draft N2914). But on the other hand, all current usages of 
<tt><i>dereferencable</i></tt> and <tt><i>incrementable</i></tt> are involved with types that satisfy 
iterator requirements. Thus, I believe that it is sufficient for C++0x to add corresponding definitions to 
24.2.1 [iterator.requirements.general] and to let all previous usages of these terms refer to this 
sub-clause. Since the same problem occurs with the past-the-end iterator, this proposal suggest providing 
similar references to usages that precede its definition as well.
</p></li>
<li><p>We also need to ensure that all iterator expressions get either an operational semantics in
terms of others or we need to add missing pre- and post-conditions. E.g. we have the following
ones without semantics:
</p><blockquote><pre>
*r++ = o // output iterator
*r--     // bidirectional iterator
</pre></blockquote><p>
According to the <a href="http://www.sgi.com/tech/stl/OutputIterator.html">SGI specification</a>
these correspond to
</p><blockquote><pre>
{ *r = o; ++r; }                         // output iterator
{ reference tmp = *r; --r; return tmp; } // bidirectional iterator
</pre></blockquote><p>
respectively. Please note especially the latter expression for bidirectional iterator. It fixes a problem
that we have for forward iterator as well: Both these iterator categories provide stronger guarantees
than input iterator, because the result of the dereference operation is <tt>reference</tt>, and <strong>not</strong>
only convertible to the value type (The exact form from the SGI documentation does not correctly refer to
<tt>reference</tt>).
</p></li>
</ol>

<p><i>[2011-03-14: Daniel comments and updates the suggested wording]</i></p>


<p>In addition to the before mentioned necessary changes there is another one need, which
became obvious due to issue <a href="lwg-defects.html#2042">2042</a>: <tt>forward_list&lt;&gt;::before_begin()</tt> returns
an iterator value which is not dereferencable, but obviously the intention is that it should
be incrementable. This leads to the conclusion that imposing dereferencable as a requirement
for the expressions <tt>++r</tt> is wrong: We only need the iterator to be incrementable. A
similar conclusion applies to the expression <tt>--r</tt> of bidirectional iterators.</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
Consensus this is the correct direction, but there are (potentially) missing <i>incrementable</i>
preconditions on some table rows, and the Remarks on when an output iterator becomes dereferencable
are probably better handled outside the table, in a manner similar to the way we word for input
iterators.
</p>

<p>
There was some concern about redundant pre-conditions when the operational semantic is defined in
terms of operations that have preconditions, and a similar level of concern over dropping such
redundancies vs. applying a consistent level of redundant specification in all the iterator tables.
Wording clean-up in either direction would be welcome.
</p>

<p><i>[2011-08-18: Daniel adapts the proposed resolution to honor the Bloomington request]</i></p>


<p>
There is only a small number of further changes suggested to get rid of superfluous 
requirements and essentially non-normative assertions. Operations should not have extra 
pre-conditions, if defined by "in-terms-of" semantics, see e.g. <tt>a != b</tt> or <tt>a-&gt;m</tt> 
for Table 107. Further, some remarks, that do not impose anything or say nothing new have been removed, 
because I could not find anything helpful they provide.
E.g. consider the remarks for Table 108 for the operations dereference-assignment and
preincrement: They don't provide additional information say nothing surprising. With the
new pre-conditions <em>and</em> post-conditions it is implied what the remarks intend to say.
</p>

<p><i>[
2011-11-03: Some observations from Alexander Stepanov via c++std-lib-31405
]</i></p>


<p>
The following sentence is dropped from the standard section on OutputIterators:
<p/>
"In particular, the following two conditions should hold: first, any
iterator value should be assigned through before it is incremented
(this is, for an output iterator <tt>i, i++; i++;</tt> is not a valid code
sequence); second, any value of an output iterator may have at most
one active copy at any given time (for example, <tt>i = j; *++i = a; *j = b;</tt> 
is not a valid code sequence)."
</p>

<p><i>[
2011-11-04: Daniel comments and improves the wording
]</i></p>


<p>
In regard to the first part of the comment, the intention of the newly proposed wording 
was to make clear that for the expression
</p>
<blockquote><pre>
*r = o
</pre></blockquote>
<p>
we have the precondition dereferenceable and the post-condition
incrementable. And for the expression
</p>
<blockquote><pre>
++r
</pre></blockquote>
<p>
we have the precondition incrementable and the post-condition dereferenceable 
or past-the-end. This <em>should not</em>  allow for a sequence like <tt>i++; i++;</tt> 
but I agree that it doesn't exactly say that.
<p/>
In regard to the second point: To make this point clearer, I suggest to
add a similar additional wording as we already have for input iterator to the 
"Assertion&#47;note" column of the expression <tt>++r</tt>:
<p/>
"Post: any copies of the previous value of <tt>r</tt> are no longer 
required to be dereferenceable or incrementable."
<p/>
The proposed has been updated to honor the observations of Alexander Stepanov.
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li><p>Add a reference to 24.2.1 [iterator.requirements.general] to the following parts of the
library preceding Clause 24 Iterators library: (I stopped from 23.2.5 [unord.req] on, because
the remaining references are the concrete containers)</p>
<ol>
<li><p>17.6.3.2 [swappable.requirements] p5:</p>

<blockquote><p>
-5- A type <tt>X</tt> satisfying any of the iterator requirements (24.2) is <tt><i>ValueSwappable</i></tt> if, 
for any dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> object <tt>x</tt> of type 
<tt>X</tt>, <tt>*x</tt> is swappable.
</p></blockquote>
</li>

<li><p>17.6.3.5 [allocator.requirements], Table 27 &mdash; &quot;Descriptive variable definitions&quot;, 
row with the expression <tt>c</tt>:</p>

<blockquote><p>
a dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> pointer of type <tt>C*</tt>
</p></blockquote>

</li>

<li><p>20.6.3.2 [pointer.traits.functions]:</p>
<blockquote><p>
<i>Returns</i>: The first template function returns a dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> 
pointer to <tt>r</tt> obtained by calling <tt>Ptr::pointer_to(r)</tt>;  [&hellip;]
</p></blockquote>
</li>

<li><p>21.4.3 [string.iterators] p. 2:</p>
<blockquote><p>
<i>Returns</i>: An iterator which is the past-the-end value <ins>(24.2.1 [iterator.requirements.general])</ins>.
</p></blockquote>
</li>

<li><p>22.4.5.1.2 [locale.time.get.virtuals] p. 11:</p>
<blockquote><pre>
iter_type do_get(iter_type s, iter_type end, ios_base&amp; f,
  ios_base::iostate&amp; err, tm *t, char format, char modifier) const;
</pre><blockquote><p>
<i>Requires</i>: <tt>t</tt> shall be dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins>.
</p></blockquote></blockquote>
</li>

<li><p>23.2.1 [container.requirements.general] p. 6:</p>

<blockquote><p>
[&hellip;]  <tt>end()</tt> returns an iterator which is the past-the-end <ins>(24.2.1 [iterator.requirements.general])</ins> 
value for the container.  [&hellip;]
</p></blockquote>
</li>

<li><p>23.2.3 [sequence.reqmts] p. 3:</p>

<blockquote><p>
[&hellip;]  <tt>q</tt> denotes a valid dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> 
const iterator to <tt>a</tt>,  [&hellip;]
</p></blockquote>
</li>

<li><p>23.2.4 [associative.reqmts] p. 8 (I omit intentionally one further reference in the same sub-clause):</p>

<blockquote><p>
[&hellip;]  <tt>q</tt> denotes a valid dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> 
const iterator to <tt>a</tt>,  [&hellip;]
</p></blockquote>
</li>

<li><p>23.2.5 [unord.req] p. 10 (I omit intentionally one further reference in the same sub-clause):</p>

<blockquote><p>
[&hellip;]  <tt>q</tt> and <tt>q1</tt> are valid dereferenceable <ins>(24.2.1 [iterator.requirements.general])</ins> 
const iterators to <tt>a</tt>,  [&hellip;]
</p></blockquote>
</li>
</ol>

</li>
<li><p>Edit 24.2.1 [iterator.requirements.general] p. 5 as indicated (The intent is to properly define
<i>incrementable</i> and to ensure some further library guarantee related to past-the-end iterator values):</p>

<blockquote><p>
-5- Just as a regular pointer to an array guarantees that there is a pointer value pointing past the last element
of the array, so for any iterator type there is an iterator value that points past the last element of a
corresponding sequence. These values are called <i>past-the-end values</i>. Values of an iterator <tt>i</tt> for which the
expression <tt>*i</tt> is defined are called <i>dereferenceable</i>. <ins>Values of an iterator <tt>i</tt> for which the
expression <tt>++i</tt> is defined are called <i>incrementable</i>. </ins> The library never assumes that 
past-the-end values are dereferenceable <ins>or incrementable</ins>. Iterators can also have singular values 
that are not associated with any sequence. [&hellip;]
</p></blockquote>
</li>

<li><p>Modify the column contents of Table 106 &mdash; &quot;Iterator requirements&quot;, 
24.2.2 [iterator.iterators], as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 106 &mdash; Iterator requirements</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>

<tr>
<td><tt>*r</tt></td>
<td><tt>reference</tt></td>
<td><tt>&nbsp;</tt></td>
<td>pre: <tt>r</tt> is dereferenceable.</td>
</tr>

<tr>
<td><tt>++r</tt></td>
<td><tt>X&amp;</tt></td>
<td><tt>&nbsp;</tt></td>
<td><ins>pre: <tt>r</tt> is incrementable.</ins></td>
</tr>

</table>
</blockquote>
</li>

<li><p>Modify the column contents of Table 107 &mdash; &quot;Input iterator requirements&quot;, 
24.2.3 [input.iterators], as indicated [<i>Rationale</i>: The wording changes attempt
to define a minimal "independent" set of operations, namely <tt>*a</tt> and <tt>++r</tt>, and 
to specify the semantics of the remaining ones. This approach seems to be in agreement with the 
original <a href="http://www.sgi.com/tech/stl/InputIterator.html">SGI specification</a> 
&mdash; <i>end rationale</i>]:</p>

<blockquote>
<table border="1">
<caption>Table 107 &mdash; Input iterator requirements (in addition to Iterator)</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>

<tr>
<td><tt>a != b</tt></td>
<td>contextually<br/>
convertible to <tt>bool</tt></td>
<td><tt>!(a == b)</tt></td>
<td><del>pre: <tt>(a, b)</tt> is in the domain<br/>
of <tt>==</tt>.</del>
</td>
</tr>

<tr>
<td><tt>*a</tt></td>
<td>convertible to <tt>T</tt></td>
<td><tt>&nbsp;</tt></td>
<td>pre: <tt>a</tt> is dereferenceable.<br/>
The expression<br/>
<tt>(void)*a, *a</tt> is equivalent<br/>
to <tt>*a</tt>.<br/>
If <tt>a == b</tt> and <tt>(a,b)</tt> is in<br/>
the domain of <tt>==</tt> then <tt>*a</tt> is<br/>
equivalent to <tt>*b</tt>.
</td>
</tr>

<tr>
<td><tt>a-&gt;m</tt></td>
<td><tt>&nbsp;</tt></td>
<td><tt>(*a).m</tt></td>
<td><del>pre: <tt>a</tt> is dereferenceable.</del></td>
</tr>

<tr>
<td><tt>++r</tt></td>
<td><tt>X&amp;</tt></td>
<td><tt>&nbsp;</tt></td>
<td>pre: <tt>r</tt> is <del>dereferenceable</del><ins>incrementable</ins>.<br/>
post: <tt>r</tt> is dereferenceable or<br/>
<tt>r</tt> is past-the-end.<br/>
post: any copies of the<br/>
previous value of <tt>r</tt> are no<br/>
longer required either to be<br/>
dereferenceable<ins>, incrementable,</ins><br/>
or to be in the domain of <tt>==</tt>.
</td>
</tr>

<tr>
<td><tt>(void)r++</tt></td>
<td><tt>&nbsp;</tt></td>
<td><ins><tt>(void)++r</tt></ins></td>
<td><del>equivalent to <tt>(void)++r</tt></del></td>
</tr>

<tr>
<td><tt>*r++</tt></td>
<td>convertible to <tt>T</tt></td>
<td><tt>{ T tmp = *r;<br/>
++r;<br/>
return tmp; }
</tt></td>
<td><tt>&nbsp;</tt></td>
</tr>

</table>
</blockquote>
</li>

<li>
<p>Modify the column contents of Table 108 &mdash; &quot;Output iterator requirements&quot;, 
24.2.4 [output.iterators], as indicated [<i>Rationale</i>: The wording changes attempt
to define a minimal "independent" set of operations, namely <tt>*r = o</tt> and <tt>++r</tt>,
and to specify the semantics of the remaining ones. This approach seems to be in agreement with
the original <a href="http://www.sgi.com/tech/stl/OutputIterator.html">SGI specification</a> 
&mdash; <i>end rationale</i>]:</p>

<blockquote>
<table border="1">
<caption>Table 108 &mdash; Output iterator requirements (in addition to Iterator)</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>

<tr>
<td><tt>*r = o</tt></td>
<td>result is not used</td>
<td><tt>&nbsp;</tt></td>
<td><ins>pre: <tt>r</tt> is dereferenceable.</ins><br/>
<i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable <ins>and any copies of<br/>
the previous value of <tt>r</tt> are no<br/>
longer required to be dereferenceable<br/>
or incrementable.</ins><br/>
post: <tt>r</tt> is incrementable.
</td>
</tr>

<tr>
<td><tt>++r</tt></td>
<td><tt>X&amp;</tt></td>
<td><tt>&nbsp;</tt></td>
<td><ins>pre: <tt>r</tt> is incrementable.</ins><br/>
<tt>&amp;r == &amp;++r</tt>.<br/>
<del><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable.<br/></del>
<ins><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
incrementable and any copies of<br/>
the previous value of <tt>r</tt> are no<br/>
longer required to be dereferenceable<br/>
or incrementable.</ins><br/>
post: <tt>r</tt> is <ins>dereferenceable<br/>
or <tt>r</tt> is past-the-end</ins><del>incrementable</del>.<br/>
</td>
</tr>

<tr>
<td><tt>r++</tt></td>
<td>convertible to <tt>const X&amp;</tt></td>
<td><tt>{ X tmp = r;<br/>
  ++r;<br/>
  return tmp; }</tt>
</td>
<td><del><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable.<br/>
post: <tt>r</tt> is incrementable.</del>
</td>
</tr>

<tr>
<td><tt>*r++ = o</tt></td>
<td>result is not used</td>
<td><ins><tt>{ *r = o; ++r; }</tt></ins></td>
<td><del><i>Remark</i>: After this operation<br/>
<tt>r</tt> is not required to be<br/>
dereferenceable.<br/>
post: <tt>r</tt> is incrementable.</del>
</td>
</tr>
</table>
</blockquote>
</li>

<li><p>Modify the column contents of Table 109 &mdash; &quot;Forward iterator requirements&quot;, 
24.2.5 [forward.iterators], as indicated [<i>Rationale</i>: Since the return type of the
expression <tt>*r++</tt> is now guaranteed to be type <tt>reference</tt>, the implied operational
semantics from input iterator based on value copies is wrong &mdash; <i>end rationale</i>]</p>

<blockquote>
<table border="1">
<caption>Table 109 &mdash; Forward iterator requirements (in addition to input iterator)</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>

<tr>
<td><tt>r++</tt></td>
<td>convertible to <tt>const X&amp;</tt></td>
<td><tt>{ X tmp = r;<br/>
  ++r;<br/>
  return tmp; }</tt>
</td>
<td><tt>&nbsp;</tt></td>
</tr>

<tr>
<td><tt>*r++</tt></td>
<td>reference</td>
<td><ins><tt>{ reference tmp = *r;<br/>
 ++r;<br/> 
 return tmp; }</tt></ins></td>
<td><tt>&nbsp;</tt></td>
</tr>
</table>
</blockquote>

</li>

<li><p>Modify the column contents of Table 110 &mdash; &quot;Bidirectional iterator requirements&quot;, 
24.2.6 [bidirectional.iterators], as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 110 &mdash; Bidirectional iterator requirements (in addition to forward iterator)</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>

<tr>
<td><tt>--r</tt></td>
<td><tt>X&amp;</tt></td>
<td><tt>&nbsp;</tt></td>
<td>pre: there exists <tt>s</tt> such that<br/>
<tt>r == ++s</tt>.<br/>
post: <tt>r</tt> is <del>dereferenceable</del><ins>incrementable</ins>.<br/>
<tt>--(++r) == r</tt>.<br/>
<tt>--r == --s</tt> implies <tt>r == s</tt>.<br/>
<tt>&amp;r == &amp;--r</tt>.
</td>
</tr>

<tr>
<td><tt>r--</tt></td>
<td>convertible to <tt>const X&amp;</tt></td>
<td><tt>{ X tmp = r;<br/>
  --r;<br/>
  return tmp; }</tt>
</td>
<td><tt>&nbsp;</tt></td>
</tr>

<tr>
<td><tt>*r--</tt></td>
<td>reference</td>
<td><ins><tt>{ reference tmp = *r;<br/>
 --r;<br/> 
 return tmp; }</tt></ins></td>
<td><tt>&nbsp;</tt></td>
</tr>
</table>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2038"></a>2038. Missing definition for <tt>incrementable</tt> iterator</h3>
<p><b>Section:</b> 24.2.4 [output.iterators] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2011-02-27 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#output.iterators">active issues</a> in [output.iterators].</p>
<p><b>View all other</b> <a href="lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>In comp.lang.c++, Vicente Botet raises the following questions:</p>

<blockquote><p>
&quot;In "24.2.4 Output iterators" there are 3 uses of incrementable. I've
not found the definition. Could some one point me where it is defined?
<p/>
Something similar occurs with dereferenceable. While the definition is
given in "24.2.1 In general" it is used several times before.
<p/>
Shouldn't these definitions be moved to some previous section?&quot;
</p></blockquote>

<p>He's right: both terms are used without being properly defined.
<p/>
There is no definition of "incrementable".
<p/>
While there is a definition of "dereferenceable", it is, in fact, a definition of 
"dereferenceable iterator". "dereferenceable" is used throughout Clause 23 (Containers) 
before its definition in Clause 24. In almost all cases it's referring to iterators, 
but in 17.6.3.2 [swappable.requirements] there is a mention of "dereferenceable object"; in 
17.6.3.5 [allocator.requirements] the table of Descriptive variable definitions refers to a 
"dereferenceable pointer"; 20.6.3.2 [pointer.traits.functions] refers to a 
"dereferenceable pointer"; in 22.4.5.1.2 [locale.time.get.virtuals]&#47;11 (<tt>do_get</tt>) 
there is a requirement that a pointer "shall be dereferenceable". In those specific cases 
it is not defined.
</p>

<p><i>[2011-03-02: Daniel comments:]</i></p>


<p>I believe that the currently proposed resolution of issue <a href="lwg-active.html#2035">2035</a> solves this
issue as well.</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
Agree with Daniel, this will be handled by the resolution of <a href="lwg-active.html#2035">2035</a>.
</p>



<p><b>Proposed resolution:</b></p>
<p></p>





<hr>
<h3><a name="2048"></a>2048. Unnecessary <tt>mem_fn</tt> overloads</h3>
<p><b>Section:</b> 20.8 [function.objects], 20.8.10 [func.memfn] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-04-18 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#function.objects">active issues</a> in [function.objects].</p>
<p><b>View all other</b> <a href="lwg-index.html#function.objects">issues</a> in [function.objects].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>mem_fn</tt> overloads for member functions are redundant and misleading
and should be removed from the post-C++11 WP.
<p/>
I believe the history of the overloads is as follows:
<p/>
In TR1 and in C++0x prior to the N2798 draft, <tt>mem_fn</tt> was specified by
a single signature:
</p>
<blockquote><pre>
template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::* pm);
</pre></blockquote>
<p>
and was accompanied by the remark "Implementations may implement <tt>mem_fn</tt> 
as a set of overloaded function templates." This remark predates variadic templates 
and was presumably to allow implementations to provide overloads for a limited 
number of function parameters, to meet the implementation-defined limit on numbers of
template parameters.
<p/>
N2770 "Concepts for the C++0x Standard Library: Utilities" added
separate overloads for pointers to member functions, apparently so
that function parameters would require the <tt>CopyConstructible</tt> concept
(those overloads first appeared in N2322.) The overloads failed to
account for varargs member functions (i.e. those declared with an
ellipsis in the parameter-declaration-clause) e.g.
</p>
<blockquote><pre>
struct S {
 int f(int, ...);
};
</pre></blockquote>
<p>
Syntactically such a function would be handled by the original
<tt>mem_fn(R T::* pm)</tt> signature, the only minor drawback being that there
would be no <tt>CopyConstructible</tt> requirement on the parameter list. (Core
DR 547 clarifies that partial specializations can be written to match
cv-qualified and ref-qualified functions to support the case where <tt>R T::*</tt> 
matches a pointer to member function type.)
<p/>
LWG issue <a href="lwg-defects.html#920">920</a> pointed out that additional overloads were missing for
member functions with ref-qualifiers. These were not strictly
necessary, because such functions are covered by the <tt>mem_fn(R T::* pm)</tt> signature.
<p/>
Concepts were removed from the draft and N3000 restored the original
single signature and accompanying remark.
<p/>
LWG <a href="lwg-closed.html#1230">1230</a> was opened to strike the remark again and to add an overload
for member functions (this overload was unnecessary for syntactic reasons and 
insufficient as it didn't handle member functions with cv-qualifiers and&#47;or 
ref-qualifiers.)
<p/>
<a href="lwg-defects.html#920">920</a> (and <a href="lwg-closed.html#1230">1230</a>) were resolved by restoring a full set of
(non-concept-enabled) overloads for member functions with cv-qualifiers and ref-qualifiers,
but as in the concept-enabled draft there were no overloads for member functions with 
an ellipsis in the parameter-declaration-clause. This is what is present in the FDIS.
<p/>
Following the thread beginning with message c++std-lib-30675, it is my
understanding that all the <tt>mem_fn</tt> overloads for member functions are
unnecessary and were only ever added to allow concept requirements.
I'm not aware of any reason implementations cannot implement <tt>mem_fn</tt> as
a single function template. Without concepts the overloads are
redundant, and the absence of overloads for varargs functions can be
interpreted to imply that varargs functions are not intended to work
with <tt>mem_fn</tt>. Clarifying the intent by adding overloads for varargs
functions would expand the list of 12 redundant overloads to 24, it
would be much simpler to remove the 12 redundant overloads entirely.
</p>

<p><i>[Bloomington, 2011]</i></p>

<p>
Move to Review.
</p>

<p>
The issue and resolution appear to be correct, but there is some concern that the wording of INVOKE may be different depending on whether you pass a pointer-to-member-data or pointer-to-member-function.  That might make the current wording necessary after all, and then we might need to add the missing elipsis overloads.
</p>

<p>
There was some concern that the Remark confirming implementors had freedom to implement this as a set of overloaded functions may need to be restored if we delete the specification for these overloads.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Moved to Tentatively Ready by the post-Kona issues processing subgroup.
</p>



<p><b>Proposed resolution:</b></p>

<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change the <tt>&lt;functional&gt;</tt> synopsis 20.8 [function.objects] p. 2 as follows:</p>

<blockquote><pre>
namespace std {
  [&hellip;]
  // <i>[func.memfn], member function adaptors:</i>
  template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::*);
<del>  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...));
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) const);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;&amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;&amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;&amp;);
  template&lt;class R, class T, class... Args&gt;
  <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;&amp;);</del>

  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Change 20.8.10 [func.memfn] as follows:</p>

<blockquote><pre>
template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::*);
<del>template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...));
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) const);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) volatile);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;&amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;&amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;&amp;);
template&lt;class R, class T, class... Args&gt;
<i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;&amp;);</del>
</pre></blockquote>
</li>

</ol>






<hr>
<h3><a name="2049"></a>2049. <tt>is_destructible</tt> is underspecified</h3>
<p><b>Section:</b> 20.9.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-04-18 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>The conditions for the type trait <tt>is_destructible</tt> to be true
are described in Table 49 &mdash; Type property predicates:</p>
<blockquote><p>
For a complete type <tt>T</tt> and given<br/>
<tt>template &lt;class U&gt;
struct test { U u; };</tt>,<br/>
<tt>test&lt;T&gt;::~test()</tt> is not deleted.
</p></blockquote>

<p>This specification does not say what the result would be for function
types or for abstract types:</p>
<ol>
<li>For an abstract type <tt>X</tt> the instantiation <tt>test&lt;X&gt;</tt>
is already ill-formed, so we cannot say anything about whether the destructor
would be deleted or not.</li>
<li>In regard to function types, there exists a special rule in the core language, 14.3.1 [temp.arg.type] p. 3,
which excludes member functions to be declared via the type of the template parameter:
<blockquote><p>
If a declaration acquires a function type through a type dependent on a <i>template-parameter</i>
and this causes a declaration that does not use the syntactic form of a function declarator 
to have function type, the program is ill-formed. 
<p/>
[ <i>Example</i>:</p>
<blockquote><pre>
template&lt;class T&gt; struct A {
  static T t;
};
typedef int function();
A&lt;function&gt; a; // ill-formed: would declare A&lt;function&gt;::t
               // as a static member function
</pre></blockquote>
<p>
&mdash; <i>end example</i> ]
</p></blockquote>
which has the same consequence as for abstract types, namely that the corresponding
instantiation of <tt>test</tt> is already ill-formed and we cannot say anything
about the destructor.
</li>
</ol>
<p>To solve this problem, I suggest to specify function types as trivially and nothrowing
destructible, because above mentioned rule is very special for templates. For non-templates,
a typedef can be used to introduce a member as member function as clarified in 8.3.5 [dcl.fct]
p. 10.</p>
<p>For abstract types, two different suggestions have been brought to my attention:
Either declare them as unconditionally non-destructible or check whether the expression
</p>
<blockquote><pre>
std::declval&lt;T&amp;&gt;().~T()
</pre></blockquote>
<p>is well-formed in an unevaluated context. The first solution is very easy to specify,
but the second version has the advantage for providing more information to user-code. This 
information could be quite useful, if generic code is supposed to invoke the destructor
of a reference to a base class indirectly via a delete expression, as suggested by
Howard Hinnant:</p>
<blockquote><pre>
template &lt;class T&gt;
my_pointer&lt;T&gt;::~my_pointer() noexcept(is_nothrow_destructible&lt;T&gt;::value)
{
   delete ptr_;
}
</pre></blockquote>
<p>Additional to the <tt>is_destructible</tt> traits, its derived forms <tt>is_trivially_destructible</tt>
and <tt>is_nothrow_destructible</tt> are similarly affected, because their wording refers to "the indicated
destructor" and probably need to be adapted as well.</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
After discussion about to to handle the exceptional cases of reference types, function types (available by defererencing a function pointer)
and <tt>void</tt> types, Howard supplied proposed wording.
</p>

<p><i>[
2011-08-20 Daniel comments and provides alternatives wording
]</i></p>


<p>
The currently proposed wording would have the consequence that 
<em>every</em> array type is not destructible, because the pseudo-destructor
requires a scalar type with the effect that the expression
</p><blockquote><pre>
std::declval&lt;T&amp;&gt;().~T()
</pre></blockquote><p>
is not well-formed for e.g. <tt>T</tt> equal to <tt>int[3]</tt>. The intuitive
solution to fix this problem would be to adapt the object type case to refer to 
the expression
</p><blockquote><pre>
std::declval&lt;U&amp;&gt;().~U()
</pre></blockquote><p>
with <tt>U</tt> equal to <tt>remove_all_extents&lt;T&gt;::type</tt>, but that
would have the effect that arrays of unknown bounds would be destructible, if 
the element type is destructible, which was not the case before (This was 
intentionally covered by the special "For a complete type T" rule in
the FDIS).
<p/>
Suggestion: Use the following definition instead:
</p>
<blockquote><p>
Let <tt>U</tt> be <tt>remove_all_extents&lt;T&gt;::type</tt>.<br/>
For incomplete types and function types, <tt>is_destructible&lt;T&gt;::value</tt> is <tt>false</tt>.<br/>
For object types, if the expression <tt>std::declval&lt;U&amp;&gt;().~U()</tt> is well-formed<br/>
when treated as an unevaluated operand (Clause 5), then <tt>is_destructible&lt;T&gt;::value</tt><br/>
is <tt>true</tt>, otherwise it is <tt>false</tt>.<br/>
For reference types, <tt>is_destructible&lt;T&gt;::value</tt> is <tt>true</tt>.
</p></blockquote>
<p>
This wording also harmonizes with the "unevaluated operand" phrase
used in other places, there does not exist the definition of an
"unevaluated context"
<p/>
<em>Note:</em> In the actually proposed wording this wording has been slightly reordered with the same effects. 
</p>

<p><strong>Howard's (old) proposed resolution:</strong></p>
<blockquote class="note">
<p>
Update 20.9.4.3 [meta.unary.prop], table 49:
</p>

<table border="1">
<tr>
<td><tt>template &lt;class T&gt;
struct is_destructible;</tt></td>
<td>
<del>For a complete type <tt>T</tt> and given <tt>template &lt;class U&gt; struct test { U u; };</tt>, <tt>test&lt;T&gt;::~test()</tt> is not deleted.
</del>
<br/>
<ins>
For object types, if the expression: <tt>std::declval&lt;T&amp;>().~T()</tt> is well-formed in an unevaluated context then
<tt>is_destructible&lt;T>::value</tt> is <tt>true</tt>, otherwise it is <tt>false</tt>.
<br/>
For <tt>void</tt> types, <tt>is_destructible&lt;T>::value</tt> is <tt>false</tt>.
<br/>
For reference types, <tt>is_destructible&lt;T>::value</tt> is <tt>true</tt>.
<br/>
For function types, <tt>is_destructible&lt;T>::value</tt> is <tt>false</tt>.
</ins>
</td>
<td><tt>T</tt> shall be a complete type, (possibly cv-qualified) <tt>void</tt>, or an array of unknown bound.</td>
</tr>
</table>
</blockquote>
<p>
</p>

<p><i>[2012, Kona]</i></p>

<p>
Moved to Tentatively Ready by the post-Kona issues processing subgroup.
</p>



<p><b>Proposed resolution:</b></p>

<p>
Update 20.9.4.3 [meta.unary.prop], table 49:
</p>

<table border="1">
<tr>
<td><tt>template &lt;class T&gt;
struct is_destructible;</tt></td>
<td>
<del>For a complete type <tt>T</tt> and given <tt>template &lt;class U&gt; struct test { U u; };</tt>, <tt>test&lt;T&gt;::~test()</tt> is not deleted.
</del>
<br/>
<ins>
For reference types, <tt>is_destructible&lt;T&gt;::value</tt> is <tt>true</tt>.<br/>
For incomplete types and function types, <tt>is_destructible&lt;T&gt;::value</tt> is <tt>false</tt>.<br/>
For object types and given <tt>U</tt> equal to <tt>remove_all_extents&lt;T&gt;::type</tt>,<br/> 
if the expression <tt>std::declval&lt;U&amp;&gt;().~U()</tt> is well-formed when treated as an<br/>
unevaluated operand (Clause 5 [expr]), then <tt>is_destructible&lt;T&gt;::value</tt> is <tt>true</tt>,<br/>
otherwise it is <tt>false</tt>.<br/>
</ins>
</td>
<td><tt>T</tt> shall be a complete type, (possibly cv-qualified) <tt>void</tt>, or an array of unknown bound.</td>
</tr>
</table>






<hr>
<h3><a name="2052"></a>2052. Mixup between <tt>mapped_type</tt> and <tt>value_type</tt> for associative containers</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Marc Glisse <b>Opened:</b> 2011-05-04 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
(this is basically reopening the first part of issue <a href="lwg-closed.html#2006">2006</a>, as discussed in the thread 
starting at c++std-lib-30698 )
<p/>
Section 23.2.4 [associative.reqmts]
<p/>
In Table 102, several uses of <tt>T</tt> (which means <tt>mapped_type</tt> here) should
be <tt>value_type</tt> instead. This is almost editorial. For instance:
</p>
<blockquote><pre>
a_uniq.emplace(args)
</pre><p>
<i>Requires</i>: <tt>T</tt> shall be <tt>EmplaceConstructible</tt> into <tt>X</tt> from args.
<p/>
<i>Effects</i>: Inserts a <tt>T</tt> object <tt>t</tt> constructed with
<tt>std::forward&lt;Args&gt;(args)...</tt> if and only if there is no element in the
container with key equivalent to the key of <tt>t</tt>. The <tt>bool</tt> component of
the returned pair is true if and only if the insertion takes place, and the iterator component 
of the pair points to the element with key equivalent to the key of <tt>t</tt>.
</p></blockquote>

<p><i>[
2011 Bloomington
]</i></p>


<p>
Not even an exhaustive list of problem locations. No reason to doubt issue.
</p>
<p>
Pablo agrees to provide wording.
</p>

<p><i>[
2011-09-04 Pablo Halpern provides improved wording
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
In both section 23.2.4 [associative.reqmts] Table 102 and 23.2.5 [unord.req], Table 103, make the following text replacements:
</p>

<table border="1">
<tr> <td>Original text, in FDIS</td> <td>Replacement text</td> </tr>

<tr> 
<td><tt>T</tt> is CopyInsertable into <tt>X</tt> and <tt>CopyAssignable</tt>.</td>
<td><tt>value_type</tt> is <tt>CopyInsertable</tt> into <tt>X</tt>, <tt>key_type</tt> is <tt>CopyAssignable</tt>, and
<tt>mapped_type</tt> is <tt>CopyAssignable</tt> (for containers having a <tt>mapped_type</tt>)</td>    
</tr>

<tr> 
<td><tt>T</tt> is <tt>CopyInsertable</tt></td>                                                
<td><tt>value_type</tt> is CopyInsertable</td> 
</tr>

<tr> 
<td><tt>T</tt> shall be <tt>CopyInsertable</tt></td>                                          
<td><tt>value_type</tt> shall be CopyInsertable</td> 
</tr>

<tr> 
<td><tt>T</tt> shall be <tt>MoveInsertable</tt></td>                                          
<td><tt>value_type</tt> shall be MoveInsertable</td> 
</tr>

<tr> 
<td><tt>T</tt> shall be <tt>EmplaceConstructible</tt></td>                                    
<td><tt>value_type</tt> shall be EmplaceConstructible</td> 
</tr>

<tr> 
<td><tt>T</tt> object</td>                                                                    
<td><tt>value_type</tt> object</td> 
</tr>
</table>

<p><i>[
<b>Notes to the editor</b>: The above are carefully selected 
phrases that can be used for global search-and-replace within 
the specified sections without accidentally making changes to 
correct uses <tt>T</tt>.
]</i></p>






<hr>
<h3><a name="2054"></a>2054. <tt>time_point</tt> constructors need to be <tt>constexpr</tt></h3>
<p><b>Section:</b> 20.11.6 [time.point] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2011-05-13 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 20.11.6 [time.point], <tt>time_point::min()</tt> and <tt>time_point::max()</tt> 
are listed as <tt>constexpr</tt>. However, <tt>time_point</tt> has no <tt>constexpr</tt> constructors, 
so is not a literal type, and so these functions cannot be <tt>constexpr</tt> without adding a 
<tt>constexpr</tt> constructor for implementation purposes.
<p/>
Proposed resolution: Add <tt>constexpr</tt> to the constructors of <tt>time_point</tt>. The effects of
the constructor template basically imply that the member function <tt>time_since_epoch()</tt> is
intended to be <tt>constexpr</tt> as well.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Alter the class template definition in 20.11.6 [time.point] as follows:</p>
<blockquote><pre>
template &lt;class Clock, class Duration = typename Clock::duration&gt;
class time_point {
  [&hellip;]
public:
  <i>// 20.11.6.1, construct:</i>
  <ins>constexpr</ins> time_point(); <i>// has value epoch</i>
  <ins>constexpr</ins> explicit time_point(const duration&amp; d); <i>// same as time_point() + d</i>
  template &lt;class Duration2&gt;
    <ins>constexpr</ins> time_point(const time_point&lt;clock, Duration2&gt;&amp; t);

  <i>// 20.11.6.2, observer:</i>
  <ins>constexpr</ins> duration time_since_epoch() const;
  [&hellip;]
};
</pre></blockquote>
</li>

<li><p>Alter the declarations in 20.11.6.1 [time.point.cons]:</p>
<blockquote><pre>
<ins>constexpr</ins> time_point();
</pre><blockquote><p>
-1- <i>Effects</i>: Constructs an object of type <tt>time_point</tt>, initializing <tt>d_</tt> with <tt>duration::zero()</tt>. Such a
<tt>time_point</tt> object represents the epoch.
</p></blockquote></blockquote>
<blockquote><pre>
<ins>constexpr explicit</ins> time_point(const duration&amp; d);
</pre><blockquote><p>
-2- <i>Effects</i>: Constructs an object of type <tt>time_point</tt>, initializing <tt>d_</tt> with <tt>d</tt>. Such a 
<tt>time_point</tt> object represents the epoch <tt>+ d</tt>.
</p></blockquote></blockquote>
<blockquote><pre>
template &lt;class Duration2&gt;
  <ins>constexpr</ins> time_point(const time_point&lt;clock, Duration2&gt;&amp; t);
</pre><blockquote><p>
-3- <i>Remarks</i>: This constructor shall not participate in overload resolution unless <tt>Duration2</tt> is implicitly
convertible to <tt>duration</tt>.
<p/>
-4- <i>Effects</i>: Constructs an object of type <tt>time_point</tt>, initializing <tt>d_</tt> with <tt>t.time_since_epoch()</tt>.
</p></blockquote></blockquote>
</li>

<li><p>Alter the declaration in 20.11.6.2 [time.point.observer]:</p>
<blockquote><pre>
<ins>constexpr</ins> duration time_since_epoch() const;
</pre><blockquote><p>
-1- <i>Returns</i>: d_.
</p></blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2056"></a>2056. <tt>future_errc</tt> enums start with value 0 (invalid value for <tt>broken_promise</tt>)</h3>
<p><b>Section:</b> 30.6.1 [futures.overview] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2011-05-18 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.overview">issues</a> in [futures.overview].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 30.6.1 [futures.overview] <tt>enum class future_errc</tt> is defined as follows:
</p><blockquote><pre>
enum class future_errc {
  broken_promise,
  future_already_retrieved,
  promise_already_satisfied,
  no_state
};
</pre></blockquote><p>
With this declaration <tt>broken_promise</tt> has value 0, which means that
for a <tt>future_error f</tt> with this code
</p><blockquote><pre>
f.code().operator bool()
</pre></blockquote><p>
yields false, which makes no sense. 0 has to be reserved for "no error".
So, the enums defined here have to start with 1.
<p/>
Howard, Anthony, and Jonathan have no objections.
</p>
<p>[Discussion in Bloomington 2011-08-16]
</p>
<p>
Previous resolution:
</p>
<blockquote class="note">
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>In 30.6.1 [futures.overview], header <tt>&lt;future&gt;</tt> synopsis, fix 
the declaration of <tt>future_errc</tt> as follows:</p>
<blockquote><pre>
namespace std {
  enum class future_errc {
    <del>broken_promise,</del>
    future_already_retrieved<ins> = 1</ins>,
    promise_already_satisfied,
    no_state<ins>,
    broken_promise</ins>
  };
  [&hellip;]
}
</pre></blockquote>
</li>
</ol>
</blockquote>
<p>
Is this resolution overspecified? These seem to be all implementation-defined. How do users add new values and not conflict with established error codes?
</p><p>
PJP proxy says: over-specified. boo.
</p><p>
Other error codes: look for <tt>is_error_code_enum</tt> specializations. Only one exists <tt>io_errc</tt>
</p><p>
Peter: I don't see any other parts of the standard that specify error codes where we have to do something similar.
</p><p>
Suggest that for every place where we add an error code, the following:
</p>
<ol>
   <li> no zero values
   </li><li> all implementation defined values, so future_already_retrieved = implementation_defined
   </li><li> values are distinct
</li></ol>

<p><i>[2012, Kona]</i></p>

<p>
Moved to Tentatively Ready by the post-Kona issues processing subgroup.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<p>In 30.6.1 [futures.overview], header <tt>&lt;future&gt;</tt> synopsis, fix 
the declaration of <tt>future_errc</tt> as follows:</p>

<blockquote><pre>
namespace std {
  enum class future_errc {
    broken_promise<ins> = <var>implementation defined</var></ins>,
    future_already_retrieved<ins> = <var>implementation defined</var></ins>,
    promise_already_satisfied<ins> = <var>implementation defined</var></ins>,
    no_state<ins> = <var>implementation defined</var></ins>
  };
  [&hellip;]
}
</pre></blockquote>
<p>In 30.6.1 [futures.overview], header <tt>&lt;future&gt;</tt> synopsis, add a paragraph after paragraph 2 as follows:</p>

<ins>The enum values of <tt>future_errc</tt> are distinct and not zero.</ins>




<hr>
<h3><a name="2057"></a>2057. <tt>time_point + duration</tt> semantics should be made <tt>constexpr</tt> conforming</h3>
<p><b>Section:</b> 20.11.6.5 [time.point.nonmember] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-05-21 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It has been observed by LWG <a href="lwg-active.html#2054">2054</a> that the specification of some <tt>time_point</tt> member functions
already imply that <tt>time_point</tt> needs to be a literal type and suggests to specify the constructors
and the member function <tt>time_since_epoch()</tt> as <tt>constexpr</tt> functions at the
minimum necessary. Adding further <tt>constexpr</tt> specifier to other operations should
clearly be allowed and should probably be done as well. But to allow for further <tt>constexpr</tt> 
functions in the future requires that their semantics is compatible to operations allowed in <tt>constexpr</tt> 
functions. This is already fine for all operations, except this binary plus operator:
</p>
<blockquote><pre>
template &lt;class Clock, class Duration1, class Rep2, class Period2&gt;
time_point&lt;Clock, typename common_type&lt;Duration1, duration&lt;Rep2, Period2&gt;&gt;::type&gt;
operator+(const time_point&lt;Clock, Duration1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre><blockquote><p>
-1- <i>Returns</i>: <tt>CT(lhs) += rhs</tt>, where <tt>CT</tt> is the type of the return value.
</p></blockquote></blockquote>
<p>
for similar reasons as those mentioned in <a href="lwg-defects.html#2020">2020</a>. The semantics should be fixed to allow
for making them <tt>constexpr</tt>. This issue should also be considered as a placeholder for a request
to make the remaining <tt>time_point</tt> operations similarly <tt>constexpr</tt> as had been done for 
<tt>duration</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>In 20.11.6.5 [time.point.nonmember], p.1 change the <i>Returns</i> element semantics as indicated:</p>
<blockquote><pre>
template &lt;class Clock, class Duration1, class Rep2, class Period2&gt;
time_point&lt;Clock, typename common_type&lt;Duration1, duration&lt;Rep2, Period2&gt;&gt;::type&gt;
operator+(const time_point&lt;Clock, Duration1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre><blockquote><p>
-1- <i>Returns</i>: <tt><del>CT(lhs) += rhs</del><ins>CT(lhs.time_since_epoch() + rhs)</ins></tt>, where <tt>CT</tt> 
is the type of the return value.
</p></blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2058"></a>2058. <tt>valarray</tt> and <tt>begin&#47;end</tt></h3>
<p><b>Section:</b> 26.6 [numarray] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2011-05-17 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#numarray">issues</a> in [numarray].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It was just brought to my attention that the pair of functions
<tt>begin&#47;end</tt> were added to <tt>valarray</tt> component.
Those additions strike me as counter to the long standing agreement
that <tt>valarray&lt;T&gt;</tt> is not yet another container. Valarray values
are in general supposed to be treated as a whole, and as such
has a loose specification allowing expression template techniques.
<p/>
The addition of these functions sound to me as making it much harder
(or close to impossible) to effectively use expression templates
as implementation techniques, for no clear benefits.
<p/>
My recommendation would be to drop <tt>begin&#47;end</tt> - or at least for the
<tt>const valarray&lt;T&gt;&amp;</tt> version. I strongly believe those 
are defects.
</p>
<p><i>[This issue was discussed on the library reflector starting from c++std-lib-30761.
Some of the key conclusions of this discussion were:]</i></p>

<ol>
<li>The <tt>begin&#47;end</tt> members were added to allow <tt>valarray</tt> to participate
in the new range-based for-loop by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html">n2930</a>
and not to make them container-like.</li>
<li>It is currently underspecified when the iterator values returned from
<tt>begin&#47;end</tt> become invalidated. To fix this, these invalidation rules need at
least to reflect the invalidation rules of the references returned by the
<tt>operator[]</tt> overloads of <tt>valarray</tt> (26.6.2.4 [valarray.access]).
</li>
<li>A further problem is that the requirements expressed in 26.6.1 [valarray.syn] p.3-5
enforce an implementation to provide further overloads of <tt>begin&#47;end</tt>, if the
replacement type technique is used (which was clearly part of the design of <tt>valarray</tt>).
Providing such additional overloads would also lead to life-time problems in examples like 
<tt>begin(x + y)</tt> where <tt>x</tt> and <tt>y</tt> are expressions involving <tt>valarray</tt> 
objects. To fix this, the <tt>begin&#47;end</tt> overloads could be explicitly excluded from the 
general statements of 26.6.1 [valarray.syn] p.3-5. This would make it unspecified
whether the expression <tt>begin(x + y)</tt> would be well-formed, portable code would
need to write this as <tt>begin(std::valarray&lt;T&gt;(x + y))</tt>.</li>
</ol>

<p><i>[
2011 Bloomington
]</i></p>


<p>
The intent of these overloads is entirely to support the new for syntax, and not to create
new containers.
</p>

<p>
Stefanus provides suggested wording.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Moved to Tenatively Ready by post-meeting issues processing group, after confirmation
from Gaby.
</p>



<p><b>Proposed resolution:</b></p>
<p>
In 26.6.1 [valarray.syn]&#47;4, make the following <ins>insertion</ins>:
</p>

<p>
4 Implementations introducing such replacement types shall provide additional functions and operators as
follows:
</p>
<ul>
<li>for every function taking a <tt>const valarray&lt;T&gt;&amp;</tt> <ins>other than <tt>begin</tt> and <tt>end</tt>
(26.6.10 [valarray.range])</ins>, identical functions taking the replacement types shall be added;
</li>
<li>
for every function taking two <tt>const valarray&lt;T&gt;&amp;</tt> arguments, identical functions taking every combination
of <tt>const valarray&lt;T&gt;&amp;</tt> and replacement types shall be added.
</li>
</ul>

<p>
In 26.6.10 [valarray.range], make the following <ins>insertion</ins>:
</p>
<p> 
1 In the <tt>begin</tt> and <tt>end</tt> function templates that follow, <i>unspecified</i>1 is a type that meets
the requirements of a mutable random access iterator (24.2.7) whose <tt>value_type</tt> is the template parameter
<tt>T</tt> and whose <tt>reference</tt> type is <tt>T&amp;</tt>. <i>unspecified</i>2 is a type that meets the
requirements of a constant random access iterator (24.2.7) whose <tt>value_type</tt> is the template parameter
<tt>T</tt> and whose <tt>reference</tt> type is <tt>const T&amp;</tt>.
</p>
<p><ins>
2 The iterators  returned by <tt>begin</tt> and <tt>end</tt> for an array are guaranteed to be valid until the
member function <tt>resize(size_t, T)</tt> (26.6.2.8 [valarray.members]) is called for that array or until
the lifetime of that array ends, whichever happens first.
</ins></p>





<hr>
<h3><a name="2059"></a>2059. C++0x ambiguity problem with <tt>map::erase</tt></h3>
<p><b>Section:</b> 23.4.4 [map] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Christopher Jefferson <b>Opened:</b> 2011-05-18 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#map">issues</a> in [map].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>map::erase</tt> (and several related methods) took an iterator in C++03, but take a <tt>const_iterator</tt> 
in C++0x. This breaks code where the map's <tt>key_type</tt> has a constructor which accepts an iterator 
(for example a template constructor), as the compiler cannot choose between <tt>erase(const key_type&amp;)</tt> 
and <tt>erase(const_iterator)</tt>.</p>
<blockquote><pre>
#include &lt;map&gt;

struct X
{
  template&lt;typename T&gt;
  X(T&amp;) {}
};

bool operator&lt;(const X&amp;, const X&amp;) { return false; }

void erasor(std::map&lt;X,int&gt;&amp; s, X x)
{
  std::map&lt;X,int&gt;::iterator it = s.find(x);
  if (it != s.end())
    s.erase(it);
}
</pre></blockquote>

<p><i>[
2011 Bloomington
]</i></p>


<p>
This issue affects only associative container <tt>erase</tt> calls, and is not more general, as these are the
only functions that are also overloaded on another single arguement that might cause confusion - the <tt>erase</tt>
by key method.  The complete resolution should simply restore the <tt>iterator</tt> overload in addition to the
<tt>const_iterator</tt> overload for all eight associative containers. 
</p>

<p>
Proposed wording supplied by Alan Talbot, and moved to Review.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Moved back to Open by post-meeting issues processing group.
</p>
<p>
Pablo very unhappy about case of breaking code with ambiguous conversion between both iterator types.
</p>
<p>
Alisdair strongly in favor of proposed resolution, this change from C++11 bit Chris in real code,
and it took a while to track down the cause.
</p>
<p>
Move to open, bring in front of a larger group
</p>
<p>
Proposed wording from Jeremiah:

<tt>erase(key)</tt> shall not participate in overload resolution if <tt>iterator</tt> is
convertible to <tt>key</tt>.

Note that this means making <tt>erase(key)</tt> a template-method
</p>
<p>
Poll Chris to find out if he already fixed his code, or fixed his library
</p>
<p>
Jeremiah - allow both overloads, but <tt>enable_if</tt> the <tt>const_iterator</tt> form as
a template, requiring <tt>is_same</tt> to match only <tt>const_iterator</tt>.
</p>
<p>
Poll PJ to see if he has already applied this fix?
</p>


<p><b>Proposed resolution:</b></p>
<p>
Editorial note: The following things are different between 23.2.4 [associative.reqmts] p.8 and
23.2.5 [unord.req] p.10. These should probably be reconciled.
</p>
<blockquote>
<ol>
<li>First uses the convention "denotes";  second uses the convention "is".</li>
<li>First redundantly says: "If no such element exists, returns a.end()." in erase table entry, second does not.</li>
</ol>
</blockquote>

<p>
23.2.4 [associative.reqmts] Associative containers
</p>
<p>
8 In Table 102, <tt>X</tt> denotes an associative container class, <tt>a</tt> denotes a value of <tt>X</tt>, <tt>a_uniq</tt>
denotes a value of <tt>X</tt> when <tt>X</tt> supports unique keys, <tt>a_eq</tt> denotes a value of <tt>X</tt> when
<tt>X</tt> supports multiple keys, <tt>u</tt> denotes an identifier, <tt>i</tt> and <tt>j</tt> satisfy input iterator
requirements and refer to elements implicitly convertible to <tt>value_type</tt>, <tt>[i,j)</tt> denotes a valid range,
<tt>p</tt> denotes a valid const iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable const iterator to <tt>a</tt>,
<ins><tt>r</tt> denotes a valid dereferenceable iterator to a,</ins> <tt>[q1, q2)</tt> denotes a valid range of const iterators
in <tt>a</tt>, <tt>il</tt> designates an object of type <tt>initializer_list&lt;value_type></tt>, <tt>t</tt> denotes a value of
<tt>X::value_type</tt>, <tt>k</tt> denotes a value of <tt>X::key_type</tt> and <tt>c</tt> denotes a value of type
<tt>X::key_compare</tt>. <tt>A</tt> denotes the storage allocator used by <tt>X</tt>, if any, or
<tt>std::allocator&lt;X::value_type></tt> otherwise, and <tt>m</tt> denotes an allocator of a type convertible to <tt>A</tt>.
</p>

<p>
23.2.4 [associative.reqmts] Associative containers Table 102
</p>
<p>
Add row:
</p>
<ins>
<table border="1">
<tr>
<td><tt>a.erase(r)</tt></td>
<td><tt>iterator</tt></td>
<td>
erases the element pointed to by <tt>r</tt>. Returns an iterator pointing to the element immediately following <tt>r</tt>
prior to the element being erased. If no such element exists, returns <tt>a.end()</tt>.
</td>
<td>amortized constant</td>
</tr>
</table>
</ins>

<p>
23.2.5 [unord.req] Unordered associative containers</p>
<p>
10 In table 103: <tt>X</tt> is an unordered associative container class, <tt>a</tt> is an object of type <tt>X</tt>,
<tt>b</tt> is a possibly const object of type <tt>X</tt>, <tt>a_uniq</tt> is an object of type <tt>X</tt> when
<tt>X</tt> supports unique keys, <tt>a_eq</tt> is an object of type <tt>X</tt> when <tt>X</tt> supports equivalent keys,
<tt>i</tt> and <tt>j</tt> are input iterators that refer to <tt>value_type</tt>, <tt>[i, j)</tt> is a valid range,
<tt>p</tt> and <tt>q2</tt> are valid const iterators to <tt>a</tt>, <tt>q</tt> and <tt>q1</tt> are valid dereferenceable
const iterators to <tt>a</tt>, <ins><tt>r</tt> is a valid dereferenceable iterator to a,</ins> <tt>[q1,q2)</tt> is a
valid range in <tt>a</tt>, <tt>il</tt> designates an object of type <tt>initializer_list&lt;value_type></tt>,
<tt>t</tt> is a value of type <tt>X::value_type</tt>, <tt>k</tt> is a value of type <tt>key_type</tt>, <tt>hf</tt> is a
possibly const value of type <tt>hasher</tt>, <tt>eq</tt> is a possibly const value of type <tt>key_equal</tt>,
<tt>n</tt> is a value of type <tt>size_type</tt>, and <tt>z</tt> is a value of type <tt>float</tt>.
</p>

<p>
23.2.5 [unord.req] Unordered associative containers Table 103
</p>
<p>
Add row:
</p>
<ins>
<table border="1">
<tr>
<td><tt>a.erase(r)</tt></td>
<td><tt>iterator</tt></td>
<td>
Erases the element pointed to by <tt>r</tt>. Returns the iterator immediately following <tt>r</tt> prior to the erasure.
</td>
<td>Average case O(1), worst case O(<tt>a.size()</tt>).</td>
</tr>
</table>
</ins>

<p>
23.4.4.1 [map.overview] Class template map overview p. 2
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
23.4.5.1 [multimap.overview] Class template multimap overview p. 2
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
23.4.6.1 [set.overview] Class template set overview p. 2
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
23.4.7.1 [multiset.overview] Class template multiset overview 
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
23.5.4.1 [unord.map.overview] Class template unordered_map overview p. 3
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
23.5.5.1 [unord.multimap.overview] Class template unordered_multimap overview p. 3
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
23.5.6.1 [unord.set.overview] Class template unordered_set overview p. 3
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>


<p>
23.5.7.1 [unord.multiset.overview] Class template unordered_multiset overview p. 3
</p>
<pre>
<ins>iterator erase(iterator position);</ins>
iterator erase(const_iterator position);
size_type erase(const key_type&amp; x);
iterator erase(const_iterator first, const_iterator last);
</pre>

<p>
 [diff.cpp03.containers] C.2.12 Clause 23: containers library 
</p>
<p>
23.2.3, 23.2.4
</p>
<p>
Change: Signature changes: from iterator to const_iterator parameters
</p>
<p>
Rationale: Overspecification. Effects: The signatures of the following member functions changed from
taking an iterator to taking a const_iterator:
</p>
<ul>
<li>insert(iter, val) for vector, deque, list, set, multiset, map, multimap</li>
<li>insert(pos, beg, end) for vector, deque, list, forward_list</li>
<li><del>erase(iter) for set, multiset, map, multimap</del></li>
<li>erase(begin, end) for set, multiset, map, multimap</li>
<li>all forms of list::splice</li>
<li>all forms of list::merge</li>
</ul>
<p>
Valid C++ 2003 code that uses these functions may fail to compile with this International Standard.
</p>





<hr>
<h3><a name="2062"></a>2062. Effect contradictions w&#47;o no-throw guarantee of <tt>std::function</tt> swaps</h3>
<p><b>Section:</b> 20.8.11.2 [func.wrap.func], 20.8.11.2.2 [func.wrap.func.mod] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-05-28 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Howard Hinnant observed in reflector message c++std-lib-30841 that 20.8.11.2 [func.wrap.func] 
makes the member swap <tt>noexcept</tt>, even though the non-member swap is not <tt>noexcept</tt>. 
<p/>
The latter was an outcome of the discussions during the Batavia meeting and the Madrid meeting 
involving LWG <a href="lwg-defects.html#1349">1349</a>, which seems to indicate that the remaining <tt>noexcept</tt> 
specifier at the member swap is incorrect and should be removed.
<p/>
But if we allow for a potentially throwing member swap of <tt>std::function</tt>, this causes 
another conflict with the exception specification for the following member function:
</p>
<blockquote><pre>
template&lt;class F&gt; function&amp; operator=(reference_wrapper&lt;F&gt; f) <span style="color:#C80000;font-weight:bolder">noexcept</span>;
</pre><blockquote><p>
<i>Effects</i>: <tt>function(f).<span style="color:#C80000;font-weight:bolder">swap</span>(*this);</tt>
</p>
</blockquote></blockquote>
<p>
Note that in this example the sub-expression <tt>function(f)</tt> does not cause any problems,
because of the nothrow-guarantee given in 20.8.11.2.1 [func.wrap.func.con] p. 10. The problem
is located in the usage of the swap which could potentially throw given the general latitude. 
<p/>
So, either the Madrid meeting decision need to be revised (and both member and free swap of 
<tt>std::function</tt> should be noexcept), or this function needs to be adapted as well,
e.g. by taking the exception-specification away or by changing the semantics.
<p/>
One argument for "swap-may-throw" would be to allow for small-object optimization techniques
where the copy of the target may throw. But given the fact that the swap function has been guaranteed 
to be "Throws: Nothing" from TR1 on, it seems to me that that there would still be opportunities to 
perform small-object optimizations just restricted to the set of target copies that cannot throw. 
<p/>
In my opinion member swap of <tt>std::function</tt> has always been intended to be no-throw, because
otherwise there would be no good technical reason to specify the effects of several member 
functions in terms of the "construct-swap" idiom (There are three functions that are defined
this way), which provides the strong exception safety in this case. I suggest to enforce that both 
member swap and non-member swap of <tt>std::function</tt> are nothrow functions as it had been guaranteed 
since TR1 on.
</p>

<p><i>[
2011 Bloomington
]</i></p>

<p>
Dietmar: May not be swappable in the first place.
</p>
<p>
Alisdair: This is wide contact. Then we should be taking noexcept off instead of putting it on. This is preferred resolution.
</p>
<p>
Pablo: This is bigger issue. Specification of assignment in terms of swap is suspect to begin with. It is over specification.
How this was applied to string is a better example to work from.
</p>
<p>
Pablo: Two problems: inconsistency that should be fixed (neither should have noexcept), the other issues is that assignment
should not be specified in terms of swap. There are cases where assignment should succeed where swap would fail. This is easier
with string as it should follow container rules.
</p>
<p>
<b>Action Item</b> (Alisdair): There are a few more issues found to file.
</p>
<p>
Dave: This is because of allocators? The allocator makes this not work.
</p>
<p>
Howard: There is a type erased allocator in shared_ptr. There is a noexcept allocator in shared_ptr.
</p>
<p>
Pablo: shared_ptr is a different case. There are shared semantics and the allocator does move around.
A function does not have shared semantics.
</p>
<p>
Alisdair: Function objects think they have unique ownership.
</p>
<p>
Howard: In function we specify semantics with copy construction and swap.
</p>
<p>
<b>Action Item</b> (Pablo): Write this up better (why assignment should not be defined in terms of swap)
</p>
<p>
Howard: Not having trouble making function constructor no throw.
</p>
<p>
Dietmar: Function must allocate memory.
</p>
<p>
Howard: Does not put stuff that will throw on copy or swap in small object optimization. Put those on heap.
Storing allocator, but has to be no throw copy constructable.
</p>
<p>
Pablo: Are you allowed to or required to swap or move allocators in case or swap or move.
</p>
<p>
Dave: An allocator that is type erased should be different...
</p>
<p>
Pablo: it is
</p>
<p>
Dave: Do you need to know something about allocator types? But only at construction time.
</p>
<p>
Pablo: You could have allocators that are different types.
</p>
<p>
Dave: Swap is two ended operation.
</p>
<p>
Pablo: Opinion is that both have to say propagate on swap for them to swap.
</p>
<p>
John: It is not arbitrary. If one person says no. No is no.
</p>
<p>
Howard: Find noexcept swap to be very useful. Would like to move in that direction and bring container design along.
</p>
<p>
Dave: If you have something were allocator must not propagate you can detect that at construction time.
</p>
<p>
...
</p>
<p>
Pablo: Need to leave this open and discuss in smaller group.
</p>
<p>
Alisdair: Tried to add boost::any as TR2 proposal and ran into this issue. Only the first place where we run into
issues with type erased allocators. Suggest we move it to open.
</p>
<p>
<b>Action Item</b>: Move to open.
</p>
<p>
<b>Action Item</b> (Pablo works with Howard and Daniel): Address the more fundamental issue
(which may be multiple issues) and write up findings.
</p>

<p><i>[
<b>Original resolution</b>:
]</i></p>

<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Modify the header <tt>&lt;functional&gt;</tt> synopsis in 20.8 [function.objects] as indicated:</p>
<blockquote><pre>
namespace std {
  [&hellip;]

  template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;) <ins>noexcept</ins>;

  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Modify the class template <tt>function</tt> synopsis in 20.8.11.2 [func.wrap.func] as indicated:</p>
<blockquote><pre>
namespace std {
  [&hellip;]

  <i>// [func.wrap.func.alg], specialized algorithms:</i>
  template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;) <ins>noexcept</ins>;

  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Modify 20.8.11.2.7 [func.wrap.func.alg] as indicated:</p>
<blockquote><pre>
template&lt;class R, class... ArgTypes&gt;
void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2) <ins>noexcept</ins>;
</pre><blockquote><p>
-1- <i>Effects</i>: <tt>f1.swap(f2);</tt>
</p></blockquote></blockquote>
</li>

</ol>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2063"></a>2063. Contradictory requirements for string move assignment</h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2011-05-29 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
21.4.1 [string.require]&#47;p4 says that <tt>basic_string</tt> is an "allocator-aware" 
container and behaves as described in 23.2.1 [container.requirements.general].
<p/>
23.2.1 [container.requirements.general] describes move assignment in p7 and Table 99.
<p/>
If <tt>allocator_traits&lt;allocator_type&gt;::propagate_on_container_move_assignment::value</tt> 
is false, and if the allocators stored in the lhs and rhs sides are not equal, then move 
assigning a string has the same semantics as copy assigning a string as far as resources are 
concerned (resources can not be transferred). And in this event, the lhs may have to acquire 
resources to gain sufficient capacity to store a copy of the rhs.
<p/>
However 21.4.2 [string.cons]&#47;p22 says:
</p><blockquote><pre>
basic_string&lt;charT,traits,Allocator&gt;&amp;
operator=(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; str) noexcept;
</pre><blockquote><p>
<i>Effects</i>: If <tt>*this</tt> and <tt>str</tt> are not the same object, modifies <tt>*this</tt> 
as shown in Table 71. [<i>Note</i>: A valid implementation is <tt>swap(str)</tt>. &mdash; <i>end note</i> ]
</p></blockquote></blockquote><p>
These two specifications for <tt>basic_string::operator=(basic_string&amp;&amp;)</tt> are in conflict with 
each other. It is not possible to implement a <tt>basic_string</tt> which satisfies both requirements.
<p/>
Additionally assign from an rvalue <tt>basic_string</tt> is defined as:
</p><blockquote><pre>
basic_string&amp; assign(basic_string&amp;&amp; str) noexcept;
</pre><blockquote><p>
<i>Effects</i>: The function replaces the string controlled by <tt>*this</tt> with a string of length 
<tt>str.size()</tt> whose elements are a copy of the string controlled by <tt>str</tt>. [ <i>Note</i>: A valid 
implementation is <tt>swap(str)</tt>. &mdash; <i>end note</i> ]
</p></blockquote></blockquote><p>
It seems contradictory that this member can be sensitive to <tt>propagate_on_container_swap</tt> instead 
of <tt>propagate_on_container_move_assignment</tt>.  Indeed, there is a very subtle chance for undefined 
behavior here:  If the implementation implements this in terms of <tt>swap</tt>, and if 
<tt>propagate_on_container_swap</tt> is false, and if the two allocators are unequal, the behavior 
is undefined, and will likely lead to memory corruption.  That's a lot to go wrong under a member 
named "assign".
</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
Alisdair: Can this be conditional noexcept?
</p>
<p>
Pablo: We said we were not going to put in many conditional noexcepts. Problem is not allocator, but non-normative definition. It says swap is a valid operation which it is not.
</p>
<p>
Dave: Move assignment is not a critical method.
</p>
<p>
Alisdair: Was confusing assignment and construction.
</p>
<p>
Dave: Move construction is critical for efficiency.
</p>
<p>
Kyle: Is it possible to test for noexcept.
</p>
<p>
Alisdair: Yes, query the noexcept operator.
</p>
<p>
Alisdair: Agreed there is a problem that we cannot unconditionally mark these operations as noexcept.
</p>
<p>
Pablo: How come swap is not defined in alloc
</p>
<p>
Alisdair: It is in utility.
</p>
<p>
Pablo: Swap has a conditional noexcept. Is no throw move constructable, is no throw move assignable.
</p>
<p>
Pablo: Not critical for strings or containers.
</p>
<p>
Kyle: Why?
</p>
<p>
Pablo: They do not use the default swap.
</p>
<p>
Dave: Important for deduction in other types.
</p>
<p>
Alisdair: Would change the policy we adopted during FDIS mode.
</p>
<p>
Pablo: Keep it simple and get some vendor experience.
</p>
<p>
Alisdair: Is this wording correct? Concerned with bullet 2.
</p>
<p>
Pablo: Where does it reference containers section.
</p>
<p>
Alisdair: String is a container.
</p>
<p>
Alisdair: We should not remove redundancy piecemeal.
</p>
<p>
Pablo: I agree. This is a deviation from rest of string. Missing forward reference to containers section.
</p>
<p>
Pablo: To fix section 2. Only the note needs to be removed. The rest needs to be a forward reference to containers.
</p>
<p>
Alisdair: That is a new issue.
</p>
<p>
Pablo: Not really. Talking about adding one sentence, saying that basic string is a container.
</p>
<p>
Dave: That is not just a forward reference, it is a semantic change.
</p>
<p>
PJ: We intended to make it look like a container, but it did not satisfy all the requirements.
</p>
<p>
Pablo: Clause 1 is correct. Clause 2 is removing note and noexcept (do not remove the rest). Clause 3 is correct.
</p>
<p>
Alisdair: Not sure data() is correct (in clause 2).
</p>
<p>
Conclusion: Move to open, Alisdair and Pablo volunteered to provide wording
</p>

<p><i>[
originally proposed wording:
]</i></p>


<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Modify the class template <tt>basic_string</tt> synopsis in 21.4 [basic.string]:</p>
<blockquote><pre>
namespace std {
  template&lt;class charT, class traits = char_traits&lt;charT&gt;,
    class Allocator = allocator&lt;charT&gt; &gt;
  class basic_string {
  public:
    [&hellip;]
    basic_string&amp; operator=(basic_string&amp;&amp; str) <del>noexcept</del>;
    [&hellip;]
    basic_string&amp; assign(basic_string&amp;&amp; str) <del>noexcept</del>;
    [&hellip;]
  };
}
</pre></blockquote>
</li>

<li><p>Remove the definition of the <tt>basic_string</tt> move assignment operator from 21.4.2 [string.cons] 
entirely, including Table 71 &mdash; <tt>operator=(const basic_string&lt;charT, traits, Allocator&gt;&amp;&amp;)</tt>.
This is consistent with how we define move assignment for the containers in Clause 23:</p>
<blockquote><pre>
<del>basic_string&lt;charT,traits,Allocator&gt;&amp;
operator=(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; str) noexcept;</del>
</pre><blockquote><p>
<del>-22- <i>Effects</i>: If <tt>*this</tt> and <tt>str</tt> are not the same object, modifies <tt>*this</tt> as shown 
in Table 71. [ <i>Note</i>: A valid implementation is <tt>swap(str)</tt>. &mdash; <i>end note</i> ]</del>
<p/>
<del>-23- If <tt>*this</tt> and <tt>str</tt> are the same object, the member has no effect.</del>
<p/>
<del>-24- <i>Returns</i>: <tt>*this</tt></del>
</p></blockquote></blockquote>
<blockquote>
<table border="1">
<caption><del>Table 71 &mdash; <tt>operator=(const basic_string&lt;charT, traits, Allocator&gt;&amp;&amp;)</tt></del></caption>

<tr>
<th><del>Element</del></th>
<th><del>Value</del></th>
</tr>

<tr>
<td><del><tt>data()</tt></del></td>
<td><del>points at the array whose first element was pointed
at by <tt>str.data()</tt></del></td>
</tr>

<tr>
<td><del><tt>size()</tt></del></td>
<td><del>previous value of <tt>str.size()</tt></del></td>
</tr>

<tr>
<td><del><tt>capacity()</tt></del></td>
<td><del>a value at least as large as <tt>size()</tt></del></td>
</tr>

</table> 
</blockquote>
</li>

<li><p>Modify the paragraphs prior to 21.4.6.3 [string::assign] p.3 as indicated (The
first insertion recommends a separate paragraph number for the indicated paragraph):</p>
<blockquote><pre>
basic_string&amp; assign(basic_string&amp;&amp; str) <del>noexcept</del>;
</pre><blockquote><p>
<ins>-?-</ins> <i>Effects</i>: <ins>Equivalent to <tt>*this = std::move(str)</tt>.</ins>
<del>The function replaces the string controlled by <tt>*this</tt> with a string of length 
<tt>str.size()</tt> whose elements are a copy of the string controlled by <tt>str</tt>. 
[ <i>Note</i>: A valid implementation is <tt>swap(str)</tt>. &mdash; <i>end note</i> ]</del>
<p/>
-3- <i>Returns</i>: <tt>*this</tt>
</p></blockquote></blockquote>

</li>
</ol>

<p><i>[
2012-08-11 Joe Gottman observes:
]</i></p>


<blockquote>
<p>
One of the effects of <tt>basic_string</tt>'s move-assignment operator (21.4.2 [string.cons], Table 71) is
</p>
<blockquote>

<table border="1">

<tr>
<th>Element</th>
<th>Value</th>
</tr>

<tr>
<td><tt>data()</tt></td>
<td>points at the array whose first element was pointed at by <tt>str.data()</tt></td>
</tr>

</table> 

</blockquote>
<p>
If a string implementation uses the small-string optimization and the input string <tt>str</tt> is small enough 
to make use of it, this effect is impossible to achieve. To use the small string optimization, a string has to 
be implemented using something like
</p>
<blockquote><pre>
union
{
   char buffer[SMALL_STRING_SIZE];
   char *pdata;
};
</pre></blockquote>
<p>
When the string is small enough to fit inside <tt>buffer</tt>, the <tt>data()</tt> member function returns 
<tt>static_cast&lt;const char *&gt;(buffer)</tt>, and since <tt>buffer</tt> is an array variable, there 
is no way to implement move so that the moved-to string's <tt>buffer</tt> member variable is equal to 
<tt>this->buffer</tt>.
<p/>
Resolution proposal:
<p/>
Change Table 71 to read:
</p>
<blockquote>

<table border="1">

<tr>
<th>Element</th>
<th>Value</th>
</tr>

<tr>
<td><tt>data()</tt></td>
<td>points at the array <del>whose first element was pointed at by <tt>str.data()</tt></del>
<ins>that contains the same characters in the same order as <tt>str.data()</tt> contained before 
<tt>operator=()</tt> was called</ins></td>
</tr>

</table> 

</blockquote>
<blockquote>
</blockquote>
</blockquote>




<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2070"></a>2070. <tt>allocate_shared</tt> should use <tt>allocator_traits&lt;A&gt;::construct</tt></h3>
<p><b>Section:</b> 20.7.2.2.6 [util.smartptr.shared.create] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-07-11 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.7.2.2.6 [util.smartptr.shared.create] says:
</p>
<blockquote><p>
-2- <i>Effects</i>: Allocates memory suitable for an object of type <tt>T</tt> and constructs an object in that memory
via the placement new expression <tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt>. The template
<tt>allocate_shared</tt> uses a copy of a to allocate memory. If an exception is thrown, the functions have
no effect.
</p></blockquote>
<p>
This explicitly requires placement new rather than using
<tt>allocator_traits&lt;A&gt;::construct(a, (T*)pv, std::forward&lt;Args&gt;(args)...)</tt>
In most cases that would result in the same placement new expression,
but would allow more control over how the object is constructed e.g.
using <tt>scoped_allocator_adaptor</tt> to do uses-allocator construction, or
using an allocator declared as a friend to construct objects with no
public constructors.
</p>

<p><i>[
2011-08-16 Bloomington:
]</i></p>

<p>
Agreed to fix in principle, but believe that <tt>make_shared</tt> and
<tt>allocate_shared</tt> have now diverged enough that their descriptions
should be separated.  Pablo and Stefanus to provide revised wording.
</p>

<p><strong>Daniel's (old) proposed resolution:</strong></p>
<blockquote class="note">
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change the following paragraphs of 20.7.2.2.6 [util.smartptr.shared.create] as indicated (The suggested
removal of the last sentence of p1 is not strictly required to resolve this issue, but is still recommended,
because it does not say anything new but may give the impression that it says something new):
</p><blockquote><pre>
template&lt;class T, class... Args&gt; shared_ptr&lt;T&gt; make_shared(Args&amp;&amp;... args);
template&lt;class T, class A, class... Args&gt;
  shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, Args&amp;&amp;... args);
</pre><blockquote>
<p>
-1- <i>Requires</i>: <ins>For the template <tt>make_shared</tt>, t</ins><del>T</del>he expression 
<tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt>, where <tt>pv</tt> 
has type <tt>void*</tt> and points to storage suitable to hold an object of type <tt>T</tt>, shall be well 
formed. <ins>For the template <tt>allocate_shared</tt>, the expression 
<tt>allocator_traits&lt;A&gt;::construct(a, pt, std::forward&lt;Args&gt;(args)...)</tt>,
where <tt>pt</tt> has type <tt>T*</tt> and points to storage suitable to hold an object
of type <tt>T</tt>, shall be well formed.</ins> <tt>A</tt> shall be an allocator ([allocator.requirements]). 
<del>The copy constructor and destructor of  <tt>A</tt> shall not throw exceptions.</del>
<p/>
-2- <i>Effects</i>: Allocates memory suitable for an object of type <tt>T</tt> and constructs an object in 
that memory<ins>. The template <tt>make_shared</tt> constructs the object</ins> via the placement new expression 
<tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt>. The template <tt>allocate_shared</tt> uses a copy 
of <tt>a</tt> to allocate memory<ins> and constructs the object by calling <tt>allocator_traits&lt;A&gt;::construct(a, pt,
std::forward&lt;Args&gt;(args)...)</tt></ins>. If an exception is thrown, the functions have no effect.
<p/>
-3- <i>Returns</i>: A <tt>shared_ptr</tt> instance that stores and owns the address of the newly constructed 
object of type <tt>T</tt>.
<p/>
-4- <i>Postconditions</i>: <tt>get() != 0 &amp;&amp; use_count() == 1</tt>
<p/>
-5- <i>Throws</i>: <tt>bad_alloc</tt>, or<ins>, for the template <tt>make_shared</tt>, an exception thrown from
the constructor of <tt>T</tt>, or, for the template <tt>allocate_shared</tt>,</ins> an exception thrown from 
<tt>A::allocate</tt> or <ins>from <tt>allocator_traits&lt;A&gt;::construct</tt></ins><del>from the constructor of 
<tt>T</tt></del>.
<p/>
-6- <i>Remarks</i>: Implementations are encouraged, but not required, to perform no more than one memory
allocation. [ <i>Note</i>: This provides efficiency equivalent to an intrusive smart pointer. &mdash; <i>end note</i> ]
<p/>
-7- [ <i>Note</i>: These functions will typically allocate more memory than <tt>sizeof(T)</tt> to allow for internal
bookkeeping structures such as the reference counts. &mdash; <i>end note</i> ]
</p>
</blockquote></blockquote>
</li>
</ol>
</blockquote>

<p><i>[2011-12-04: Jonathan and Daniel improve wording]</i></p>


<p>See also c++std-lib-31796</p>






<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change the following paragraphs of 20.7.2.2.6 [util.smartptr.shared.create] as indicated:
</p>
<blockquote><pre>
template&lt;class T, class... Args&gt; shared_ptr&lt;T&gt; make_shared(Args&amp;&amp;... args);
<del>template&lt;class T, class A, class... Args&gt;
  shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, Args&amp;&amp;... args);</del>
</pre></blockquote>
<p>
<del>-1- <i>Requires</i>: The expression <tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt>, where <tt>pv</tt> 
has type <tt>void*</tt> and points to storage suitable to hold an object of type <tt>T</tt>, shall be well 
formed. <tt>A</tt> shall be an allocator (17.6.3.5 [allocator.requirements]). The copy constructor 
and destructor of <tt>A</tt> shall not throw exceptions.</del>
<p/>
-2- <i>Effects</i>: <ins>Equivalent to</ins>
</p>
<blockquote><pre> 
<ins>return allocate_shared&lt;T&gt;(allocator&lt;T&gt;(), std::forward&lt;Args&gt;(args)...);</ins>
</pre></blockquote>
<p>
<del>Allocates memory suitable for an object of type <tt>T</tt> 
and constructs an object in that memory via the placement new expression 
<tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt>. The template <tt>allocate_shared</tt> uses a copy 
of <tt>a</tt> to allocate memory. If an exception is thrown, the functions have no effect.</del>
<p/>
<ins>-?- <i>Remarks</i>: An implementation may meet the effects (and the implied guarantees) without 
creating the allocator object [<i>Note</i>: That is, user-provided specializations of <tt>std::allocator</tt>
may not be instantiated, the expressions <tt>::new (pv) T(std::forward&lt;Args&gt;(args)...)</tt> and 
<tt>pv-&gt;~T()</tt> may be evaluated directly &mdash; <i>end note</i>].</ins>
<p/>
<del>-3- <i>Returns</i>: A <tt>shared_ptr</tt> instance that stores and owns the address of the newly constructed 
object of type <tt>T</tt>.</del>
<p/>
<del>-4- <i>Postconditions</i>: <tt>get() != 0 &amp;&amp; use_count() == 1</tt></del>
<p/>
<del>-5- <i>Throws</i>: <tt>bad_alloc</tt>, or an exception thrown from <tt>A::allocate</tt> or from the 
constructor of <tt>T</tt>.</del>
<p/>
<del>-6- <i>Remarks</i>: Implementations are encouraged, but not required, to perform no more than one memory
allocation. [<i>Note</i>: This provides efficiency equivalent to an intrusive smart pointer. &mdash; <i>end note</i>]</del>
<p/>
<del>-7- [<i>Note</i>: These functions will typically allocate more memory than <tt>sizeof(T)</tt> to allow 
for internal bookkeeping structures such as the reference counts. &mdash; <i>end note</i>]</del>
</p>
</li>
<li><p>
Add the following set of <ins>new paragraphs</ins> immediately following the previous paragraph 7 of
20.7.2.2.6 [util.smartptr.shared.create]:
</p>
<blockquote><pre>
template&lt;class T, class A, class... Args&gt;
  shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, Args&amp;&amp;... args);
</pre></blockquote>
<p>
-?- <i>Requires</i>: The expressions 
<tt>allocator_traits&lt;A&gt;::construct(b, pt, std::forward&lt;Args&gt;(args)...)</tt> and
<tt>allocator_traits&lt;A&gt;::destroy(b, pt)</tt> shall be well-formed and well-defined, 
where <tt>b</tt> has type <tt>A</tt> and is a copy of <tt>a</tt> and where <tt>pt</tt> 
has type <tt>T*</tt> and points to storage suitable to hold an object of type <tt>T</tt>. 
<tt>A</tt> shall meet the allocator requirements (17.6.3.5 [allocator.requirements]). 
<p/>
-?- <i>Effects</i>: Uses an object <tt>a2</tt> 
of type <tt>allocator_traits&lt;A&gt;::rebind_alloc&lt;<i>unspecified</i>&gt;</tt> that compares equal to 
<tt>a</tt> to allocate memory suitable for an object of type <tt>T</tt>. 
Uses a copy <tt>b</tt> of type <tt>A</tt> from <tt>a</tt> to construct an object of type <tt>T</tt> in 
that memory by calling <tt>allocator_traits&lt;A&gt;::construct(b, pt, std::forward&lt;Args&gt;(args)...)</tt>. 
If an exception is thrown, the function has no effect.
<p/>
-?- <i>Returns</i>: A <tt>shared_ptr</tt> instance that stores and owns the address of the newly constructed 
object of type <tt>T</tt>. When ownership is given up, the effects are as follows: Uses a copy <tt>b2</tt> 
of type <tt>A</tt> from <tt>a</tt> to destruct an object of type <tt>T</tt> by calling 
<tt>allocator_traits&lt;A&gt;::destroy(b2, pt2)</tt> where <tt>pt2</tt> has type <tt>T*</tt> 
and refers to the newly constructed object. Then uses an object of type
<tt>allocator_traits&lt;A&gt;::rebind_alloc&lt;<i>unspecified</i>&gt;</tt> that compares equal to 
<tt>a</tt> to deallocate the allocated memory.
<p/>
-?- <i>Postconditions</i>: <tt>get() != 0 &amp;&amp; use_count() == 1</tt>
<p/>
-?- <i>Throws</i>: Nothing unless memory allocation or <tt>allocator_traits&lt;A&gt;::construct</tt> 
throws an exception.
<p/>
-?- <i>Remarks</i>: Implementations are encouraged, but not required, to perform no more than one memory 
allocation. [<i>Note</i>: Such an implementation provides efficiency equivalent to an intrusive smart 
pointer. &mdash; <i>end note</i>]
<p/>
-?- [<i>Note</i>: This function will typically allocate more memory than <tt>sizeof(T)</tt> to allow for internal
bookkeeping structures such as the reference counts. &mdash; <i>end note</i>]
</p>
</li>
</ol>





<hr>
<h3><a name="2071"></a>2071. <tt>std::valarray</tt> move-assignment</h3>
<p><b>Section:</b> 26.6.2.3 [valarray.assign] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2011-05-05 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#valarray.assign">issues</a> in [valarray.assign].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Yesterday I noticed that the language we have in the FDIS about <tt>std::valarray</tt> move assignment 
is inconsistent with the resolution of LWG 675. Indeed, we guarantee constant complexity (vs linear 
complexity). We also want it to be noexcept, that is more subtle, but again it's at variance with all 
the containers.
<p/>
Also, even if we suppose that LWG <a href="lwg-defects.html#675">675</a> applies only to the containers proper, I don't think the current 
"as if by calling resize(v.size())" is internally consistent with the noexcept requirement.
<p/>
So, what do we really want for <tt>std::valarray</tt>? Shall we maybe just strike or fix the as-if, consider it 
some sort of pasto from the copy-assignment text, thus keep the noexcept and constant complexity requirements 
(essentially the whole operation would boild down to a swap of POD data members). Or LWG <a href="lwg-defects.html#675">675</a> should be 
explicitly extended to <tt>std::valarray</tt> too? In that case both noexcept and constant complexity 
would go, I think, and the operation would boil down to the moral equivalent of <tt>clear()</tt> (which 
doesn't really exist in this case) + <tt>swap</tt>?
</p>

<p>
Howard: I agree the current wording is incorrect.  The complexity should be linear in <tt>size()</tt> (not 
<tt>v.size()</tt>) because the first thing this operator needs to do is <tt>resize(0)</tt> (or <tt>clear()</tt> 
as you put it).
<p/>
I think we can keep the <tt>noexcept</tt>.
<p/>
As for proper wording, here's a first suggestion:
</p><blockquote><p>
<i>Effects</i>: <tt>*this</tt> obtains the value of <tt>v</tt>. The value of <tt>v</tt> after the assignment 
is not specified.
<p/>
<i>Complexity</i>: linear.
</p></blockquote><p>
</p>

<p>
See also reflector discussion starting with c++std-lib-30690.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Move to Ready.
</p>
<p>
Some discussion on the types supported by <tt>valarray</tt> concludes that the wording is
trying to say something similar to the core wording for trivial types, but significantly
predates it, and does allow for types with non-trivial destructors.  Howard notes that
the only reason for linear complexity, rather than constant, is to support types with
non-trivial destructors.
</p>
<p>
AJM suggests replacing the word 'value' with 'state', but straw poll prefers moving
forward with the current wording, 5 to 2.
</p>

<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>In 26.6.2.3 [valarray.assign] update as follows:</p>

<blockquote><pre>
valarray&lt;T&gt;&amp; operator=(valarray&lt;T&gt;&amp;&amp; v) noexcept;
</pre><blockquote><p>
3 <i>Effects</i>: <tt>*this</tt> obtains the value of <tt>v</tt>. <del>If the length of <tt>v</tt> 
is not equal to the length of <tt>*this</tt>, resizes <tt>*this</tt> to make the two arrays the 
same length, as if by calling <tt>resize(v.size())</tt>, before performing the assignment.</del><ins>The 
value of <tt>v</tt> after the assignment is not specified.</ins>
<p/>
4 <i>Complexity</i>: <del>Constant</del><ins>Linear</ins>.
</p></blockquote></blockquote>






<hr>
<h3><a name="2072"></a>2072. Unclear wording about capacity of temporary buffers</h3>
<p><b>Section:</b> 20.6.11 [temporary.buffer] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Kazutoshi Satoda <b>Opened:</b> 2011-08-10 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#temporary.buffer">issues</a> in [temporary.buffer].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to 20.6.11 [temporary.buffer] p1+2:

</p><blockquote><pre>
template &lt;class T&gt;
pair&lt;T*, ptrdiff_t&gt; get_temporary_buffer(ptrdiff_t n) noexcept;
</pre><blockquote><p>
-1- <i>Effects</i>: Obtains a pointer to storage sufficient to store up to <tt>n</tt> adjacent <tt>T</tt> 
objects. It is implementation-defined whether over-aligned types are supported (3.11).
<p/>
-2- <i>Returns</i>: A pair containing the buffer's address and capacity (in the units of <tt>sizeof(T)</tt>), 
or a pair of 0 values if no storage can be obtained or if <tt>n &lt;= 0</tt>.
</p></blockquote></blockquote>
<p>
I read this as prohibiting to return a buffer of which capacity is less than <tt>n</tt>, because 
such a buffer is not sufficient to store <tt>n</tt> objects.
<p/>
The corresponding description in <a href="http://www.sgi.com/tech/stl/get_temporary_buffer.html">SGI STL</a> 
is clear on this point, but I think it is a bit too verbose:
</p>

<blockquote class="note"><p>
(for the return value, a pair <tt>P</tt>) [...] the buffer pointed to by <tt>P.first</tt> is large enough 
to hold <tt>P.second</tt> objects of type <tt>T</tt>. <tt>P.second</tt> is greater than or equal to 0, 
and less than or equal to <tt>len</tt>.
</p></blockquote>

<p>
There seems to be two different targets of the "up to n" modification:
The capacity of obtained buffer, and the actual number that the caller
will store into the buffer.
<p/>
First I read as the latter, and got surprised seeing that libstdc++
implementation can return a smaller buffer. I started searching about
<tt>get_temporary_buffer()</tt>. After reading a quote from TC++PL at
<a href="http://stackoverflow.com/questions/3264299/why-do-i-need-stdget-temporary-buffer">stackoverflow</a>, 
I realized that the former is intended.
<p/>
Such misinterpretation seems common:
</p>
<ul>
<li>The above question is likely started from same misinterpretation.</li>
<li><p>JIS standard (Japanese translation of ISO&#47;IEC standard) says nothing
    like "up to". I think the editor misinterpreted the original wording,
    and omitted words for "up to" as it is redundant. (If a buffer is
    sufficient to store <tt>n</tt> objects, it is also sufficient to store
    up to <tt>n</tt> objects.)</p></li>
<li><p>Rogue Wave implementation doesn't return smaller buffer, instead, it
    can return larger buffer on some circumstances. Apache 
	<a href="http://stdcxx.apache.org/">STDCXX</a> is a derived version of that
    implementation, and <a href="https://stdcxx.apache.org/doc/stdlibref/get-temporary-buffer.html">publicly accessible</a>:
</p>
<blockquote class="note"><p>
Specializations of the <tt>get_temporary_buffer()</tt> function template
attempt to allocate a region of storage sufficiently large to store at
least <tt>n</tt> adjacent objects of type <tt>T</tt>.
</p></blockquote>
<p>
I know one commercial compiler package based on Rogue Wave implementation, 
and its implementation is essentially same as the above.
</p>
</li>
</ul>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2074"></a>2074. Off by one error in <tt>std::reverse_copy</tt></h3>
<p><b>Section:</b> 25.3.10 [alg.reverse] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Peter Miller <b>Opened:</b> 2011-08-17 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.reverse">issues</a> in [alg.reverse].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The output of the program below should be:
</p>
<blockquote><pre>
"three two one null \n"
</pre></blockquote>
<p>
But when <tt>std::reverse_copy</tt> is implemented as described in N3291 25.3.10 [alg.reverse] 
it's:
</p>
<blockquote><pre>
"null three two one \n"
</pre></blockquote>
<p>
because there's an off by one error in 25.3.10 [alg.reverse]&#47;4; the definition should read:
</p>
<blockquote><pre>
*(result + (last - first) <span style="color:#C80000;font-weight:bold">- 1</span> - i) = *(first + i)
</pre></blockquote>
<p>
Test program:
</p>
<blockquote><pre>
#include &lt;algorithm&gt;
#include &lt;iostream&gt;

template &lt;typename BiIterator, typename OutIterator&gt;
auto
reverse_copy_as_described_in_N3291(
  BiIterator first, BiIterator last, OutIterator result )
-&gt; OutIterator
{
  // 25.3.10&#47;4 [alg.reverse]:
  // "...such that for any non-negative integer i &lt; (last - first)..."
  for ( unsigned i = 0; i &lt; ( last - first ); ++i )
    // "...the following assignment takes place:"
    *(result + (last - first) - i) = *(first + i);

  // 25.3.10&#47;6
  return result + (last - first);
}

int main()
{
  using std::begin;
  using std::end;
  using std::cout;

  static const char*const in[3]  { "one", "two", "three" };
  const char*             out[4] { "null", "null", "null", "null" };

  reverse_copy_as_described_in_N3291( begin( in ), end( in ), out );

  for ( auto s : out )
    cout &lt;&lt; s &lt;&lt; ' ';

  cout &lt; std::endl;

  return 0;
}
</pre></blockquote>

<p><i>[2012, Kona]</i></p>

<p>
Move to Ready.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>
Change 25.3.10 [alg.reverse] p4 as follows:
</p> 
<blockquote><pre>
template&lt;class BidirectionalIterator, class OutputIterator&gt;
  OutputIterator
    reverse_copy(BidirectionalIterator first,
                 BidirectionalIterator last, OutputIterator result);
</pre><blockquote><p>
-4- <i>Effects</i>: Copies the range [<tt>first,last</tt>) to the range [<tt>result,result+(last-first)</tt>) 
such that for any non-negative integer <tt>i &lt; (last - first)</tt> the following assignment takes place: 
<tt>*(result + (last - first) <ins>- 1</ins> - i) = *(first + i)</tt>.
<p/>
-5- <i>Requires</i>: The ranges [<tt>first,last</tt>) and [<tt>result,result+(last-first)</tt>) shall not overlap.
<p/>
-6- <i>Returns</i>: <tt>result + (last - first)</tt>.
<p/>
-7- <i>Complexity</i>: Exactly <tt>last - first</tt> assignments.
</p></blockquote></blockquote>





<hr>
<h3><a name="2075"></a>2075. Progress guarantees, lock-free property, and scheduling assumptions</h3>
<p><b>Section:</b> 1.10 [intro.multithread], 29.4 [atomics.lockfree], 29.6.5 [atomics.types.operations.req] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Torvald Riegel <b>Opened:</b> 2011-08-18 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to 1.10 [intro.multithread] p2: 
</p>
<blockquote><p>
"Implementations should ensure that all unblocked threads eventually make progress."
</p></blockquote>
<ul>
<li>If taken literally, this cannot be achieved with lock-free atomics in
 general because they only guarantee that some thread makes progress
 (i.e., minimal progress, whereas 1.10 [intro.multithread] p2 seems to 
 require maximal progress).
</li>
<li>What does it mean precisely to "make progress"? Does "unblocked
 threads" exclude live-locked threads (if so, lock-free atomics would
 be sufficient I suppose)?
</li>
<li><p>Which assumptions can an implementation make about the thread
 scheduling? This is relevant for how implementations implement
 compare-exchange with load-linked &#47; store conditional (LL-SC), and
 atomic read-modifiy-write operations with load...compare-exchange-weak
 loops.
</p>
<ul>
<li>Do threads run long enough without being descheduled (e.g.,
   OS timeslices are long enough, interrupt frequency is not too
   high, etc.)?
</li>
<li>Or is this implementation-defined, and the sentence is just about
   stating that the progress guarantees will not hold on, for example,
   systems with unfair scheduling or thread priorities?
</li>
</ul>
</li>
</ul>

<p>
29.4 [atomics.lockfree] p2 declares the lock-free property for a
particular object. However, "lock-free" is never defined, and in discussions 
that I had with committee members it seemed as if the standard's lock-free would be
different from what lock-free means in other communities (eg, research,
text books on concurrent programming, etc.).
</p>
<ul>
<li>Originally, lock-freedom for an object requires minimal progress (ie,
 some thread makes progress, but other threads might never do) without
 any assumptions about the scheduling (threads could be stopped
 executing (so it is "nonblocking"), and threads are not guaranteed to
 execute in isolation, even for very small intervals of cycles).
</li>
<li>In contrast, obstruction-freedom, another nonblocking progress
 condition, guarantees progress for all threads that eventually get
 executed long enough in isolation (ie, without interference by other
 threads).
</li>
<li>Simple load...compare-exchange-weak loops (or LL-SC loops) to
 implement atomic read-modify-write operations can be just
 obstruction-free but not lock-free because they can livelock
 (depending on the hardware's LL-SC implementation, though). However,
 they effectively guarantee the same as lock-free iff threads will
 eventually run in isolation for long enough (that can be an assumption
 about the OS scheduler), or if the implementation adds this (e.g.,
 probabilistically by employing randomized exponential back-off when
 contention is detected, in all operations that can create contention).
</li>
<li>Does the particular object has to be lock-free, or is it only required
 that threads make progress irrespective on which object? Again
 considering compare-exchange-weak or LL-SC here, what happens if the
 compare-exchange object shares a cacheline with an integer counter
 object that is constantly updated by other threads? The
 compare-exchange-weak can always fail, so the object would not be
 lock-free. However, if we consider progress to be overall progress for
 threads, it would be lock-free because other threads succeed updating
 the integer counter. I would have assumed the lock-free property is
 strictly about the atomic object, but in discussions with committee
 members it seemed as if progress for any object could be the intended
 guarantee.
</li>
</ul>

<p>
Following 29.6.5 [atomics.types.operations.req] p7 <tt>is_lock_free()</tt> 
returns "true if the object is lock-free". What is returned if the object is only 
sometimes lock-free?
</p>

<p>
Basically, I would like to see clarifications for the progress
guarantees so that users know what they can expect from implementations
(and what they cannot expect!), and to give implementors a clearer
understanding of which user expectations they have to implement.
</p>
<ol>
<li><p>Elaborate on the intentions of the progress guarantee in 
1.10 [intro.multithread] p2. As I don't know about your intentions, 
it's hard to suggest a resolution.
</p>
<ul>
<li>Is it for straightforward, non-synchronizing code only?</li>
<li>Is it for blocking code only? (Is "unblocked" more than blocked on
 external I/O or on deadlocks?)
</li>
<li>What does it mean to "make progress"?</li>
<li>Is this meant to only waive any progress guarantees if there are
 thread priorities?
</li>
<li>Can an implementation make any assumptions about thread scheduling?
</li>
</ul>
</li>
<li><p>Define the lock-free property. The definition should probably include
the following points:
</p>
<ul>
<li>Is it just nonblocking, or what is the distinction to just being nonblocking?</li>
<li>Does it make any assumptions about the scheduler?</li>
<li>What are the progress guarantees, minimal or maximal (some or all threads finish eventually).</li>
<li>Is progress guaranteed for all operations on the particular object, or
 do operations on other objects also count as "making progress"?
</li>
</ul>
</li>
<li>Add a note explaining that compare-exchange-weak is not necessarily
lock-free (but is nonblocking)? Or is it indeed intended to be lock-free
(only allowed to fail spuriously but guaranteed to not fail eventually)?
Implementing the latter might be a challenge on LL-SC machines or lead
to space overheads I suppose, see the cacheline sharing example above.
</li>
</ol>

<p><i>[2011-12-01: Hans comments]</i></p>


<p>
1.10 [intro.multithread] p2 was an intentional compromise, and it was understood at the 
time that it was not a precise statement.  The wording was introduced by 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3209.htm">N3209</a>, which 
discusses some of the issues. There were additional reflector discussions.
<p/>
This is somewhat separable from the question of what lock-free means, which is probably a more 
promising question to focus on.
</p>

<p><i>[2012, Kona]</i></p>

<p>
General direction: lock-free means obstruction-free. Leave the current "should" recommendation 
for progress. It would take a lot of effort to try to do better. 
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2076"></a>2076. Bad <tt>CopyConstructible</tt> requirement in set constructors</h3>
<p><b>Section:</b> 23.4.6.2 [set.cons] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2011-08-20 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
23.4.6.2 [set.cons] paragraph 4 says: 
</p>

<blockquote><p>
<i>Requires</i>: If the iterators dereference operator returns an lvalue or a non-const rvalue, 
then <tt>Key</tt> shall be <tt>CopyConstructible</tt>.
</p></blockquote>

<p>
I'm confused why a "non-const rvalue" for the return value of the iterator
would require <tt>CopyConstructible</tt>; isn't that exactly the situation 
when you'd want to apply the move constructor?
<p/>
The corresponding requirement for <tt>multimap</tt> seems better in that regard
([multimap.cons] paragraph 3):
</p>
<blockquote><p>
Requires: If the iterators dereference operator returns an lvalue or a const rvalue 
<tt>pair&lt;key_type, mapped_type&gt;</tt>, then both <tt>key_type</tt> and mapped_type 
shall be <tt>CopyConstructible</tt>.
</p></blockquote>
<p>
Obviously, if I have a const rvalue, I can't apply the move constructor (which will 
likely attempt modify its argument).
<p/>
Dave Abrahams:
<p/>
I think you are right.
Proposed resolution: drop "non-" from 23.4.6.2 [set.cons] paragraph 3.
</p>


<p><i>[2012, Kona]</i></p>

<p>
The wording is in this area will be affected by Pablo's paper being adopted at this meeting.
Wait for that paper to be applied before visiting this issue - deliberately leave in New
status until the next meeting.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>
Change 23.4.6.2 [set.cons] p3 as follows:
</p> 
<blockquote><pre>
template &lt;class InputIterator&gt;
  set(InputIterator first, InputIterator last,
    const Compare&amp; comp = Compare(), const Allocator&amp; = Allocator());
</pre><blockquote><p>
-3- Effects: Constructs an empty set using the specified comparison object and allocator, and inserts
elements from the range [<tt>first,last</tt>).
<p/>
-4- <i>Requires</i>: If the iterators dereference operator returns an lvalue or a <del>non-</del>const rvalue, 
then <tt>Key</tt> shall be <tt>CopyConstructible</tt>.
<p/>
-5- <i>Complexity</i>: Linear in <tt>N</tt> if the range [<tt>first,last</tt>) is already sorted using 
<tt>comp</tt> and otherwise <tt>N logN</tt>, where <tt>N</tt> is <tt>last - first</tt>.
</p></blockquote></blockquote>





<hr>
<h3><a name="2077"></a>2077. Further incomplete constraints for type traits</h3>
<p><b>Section:</b> 20.9.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-08-20 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The currently agreed on proposed wording for <a href="lwg-defects.html#2015">2015</a> using 
<tt>remove_all_extents&lt;T&gt;::type</tt> instead of the "an array of 
unknown bound" terminology in the precondition should be extended to 
some further entries especially in Table 49, notably the 
<tt>is_*constructible</tt>, <tt>is_*assignable</tt>, and 
<tt>is_*destructible</tt> entries. To prevent ODR violations, incomplete
element types of arrays must be excluded for value-initialization and
destruction for example. Construction and assignment has to be honored, 
when we have array-to-pointer conversions or pointer conversions of
incomplete pointees in effect.
</p>

<p><i>[2012, Kona]</i></p>

<p>
The issue is that in three type traits, we are accidentally saying that in certain
circumstances the type must give a specified answer when given an incomplete type.
(Specifically: an array of unknown bound of incomplete type.)  The issue asserts
that there's an ODR violation, since the trait returns false in that case but might
return a different version when the trait is completed.
</p>
<p>
Howard argues: no, there is no risk of an ODR violation.
<tt>is_constructible&lt;A[]></tt> must return <tt>false</tt> regardless of whether
<tt>A</tt> is complete, so there's no reason to forbid an array of unknown bound of
incomplete types. Same argument applies to <tt>is_assignable</tt>. General agreement
with Howard's reasoning.
</p>
<p>
There may be a real issue for <tt>is_destructible</tt>. None of us are sure what
<tt>is_destructible</tt> is supposed to mean for an array of unknown bound
(regardless of whether its type is complete), and the standard doesn't make it clear.
The middle column doesn't say what it's supposed to do for incomplete types.
</p>
<p>
In at least one implementation, <tt>is_destructible&lt;A[]></tt> does return <tt>true</tt>
if <tt>A</tt> is complete, which would result in ODR violation unless we forbid it for
incomplete types.
</p>
<p>
Move to open. We believe there is no issue for <tt>is_constructible</tt> or
<tt>is_assignable</tt>, but that there is a real issue for <tt>is_destructible</tt>.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2078"></a>2078. Throw specification of <tt>async()</tt> incomplete</h3>
<p><b>Section:</b> 30.6.8 [futures.async] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2011-08-29 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.async">active issues</a> in [futures.async].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.async">issues</a> in [futures.async].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The current throw specification of <tt>async()</tt> does state:
</p>
<blockquote><p>
-6- <i>Throws</i>: <tt>system_error</tt> if policy is <tt>launch::async</tt> and 
the implementation is unable to start a new thread.
</p></blockquote>
<p>
First it seems not clear whether this only applies if policy equals 
<tt>launch::async</tt> of if the <tt>async</tt> launch mode flag is set 
(if <tt>policy|launch::async!=0</tt>)
<p/>
In the discussion Lawrence Crowl also wrote:
</p>
<blockquote><p>
    More generally, I think what we want to say is that if the
    implementation cannot successfully execute on one of the policies
    allowed, then it must choose another. The principle would apply
    to implementation-defined policies as well.
</p></blockquote>

<p>
Peter Sommerlad:
</p>
<blockquote><p>
Should not throw. That was the intent. "is async" meat exactly.
</p></blockquote>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2079"></a>2079. Required <tt>pow()</tt> overloads</h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2011-08-29 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
<p><b>View all other</b> <a href="lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
LWG issue <a href="lwg-defects.html#550">550</a> removed the functions:
</p>
<blockquote><pre>
float       pow(float, int);
double      pow(double, int);
long double pow(long double, int);
</pre></blockquote>
<p>
from header <tt>&lt;cmath&gt;</tt>. This change does not seem to be mentioned in Annex C, C.2.14.
<p/>
Howard:
</p>
<blockquote><p>
N3290 26.8 [c.math]&#47;p11 says:
</p><blockquote>
<p>
Moreover, there shall be additional overloads sufficient to ensure:
</p>
<ol>
<li>If any argument corresponding to a <tt>double</tt> parameter has type <tt>long double</tt>, 
then all arguments corresponding to <tt>double</tt> parameters are effectively cast to 
<tt>long double</tt>.
</li>
<li>Otherwise, if any argument corresponding to a <tt>double</tt> parameter has type <tt>double</tt> 
or an integer type, then all arguments corresponding to <tt>double</tt> parameters are effectively 
cast to <tt>double</tt>.
</li>
<li>Otherwise, all arguments corresponding to <tt>double</tt> parameters are effectively cast to 
<tt>float</tt>.
</li>
</ol>
</blockquote>
<p>
From C99 7.12.7.4 we have:
</p>
<blockquote><pre>
double pow(double, double);
</pre></blockquote>
<p>
26.8 [c.math]&#47;p11&#47;b2 says that if the client calls <tt>pow(2.0f, 2)</tt>, then the 
<tt>int</tt> for second argument causes the following effective call to be made:
</p>
<blockquote><pre>
pow(static_cast&lt;double&gt;(2.0f), static_cast&lt;double&gt;(2)) -&gt; double
</pre></blockquote>
<p>
The first sentence of p11 implies that this is done by supplying the following additional overload:
</p>
<blockquote><pre>
double pow(float, int);
</pre></blockquote>
<p>
If the client calls <tt>pow(2.0, 2)</tt>, then the same reasoning (b2 again) implies the following 
additional overload:
</p>
<blockquote><pre>
double pow(double, int);
</pre></blockquote>
<p>
If the client calls <tt>pow(2.0l, 2)</tt>, then b1 implies the following additional overload:
</p>
<blockquote><pre>
long double pow(long double, int);
</pre></blockquote>
<p>
In all, p11 implies hundreds (perhaps thousands?) of extra overloads.  All but one of which is a superset 
of the overloads required by C++98&#47;03 (that one being <tt>pow(float, int)</tt> which had its return 
type changed from <tt>float</tt> to <tt>double</tt>).
<p/>
In practice, at least some vendors implement p11 by using templated overloads as opposed to ordinary overloads.
</p></blockquote>

<p>
Steve Clamage:
</p>
<blockquote><p>
Thanks. I didn't see that those extra overloads were actually implied by p11, despite the first sentence. 
Without examples, the point is a bit subtle (at least for me).
</p></blockquote>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2080"></a>2080. Specify when <tt>once_flag</tt> becomes invalid</h3>
<p><b>Section:</b> 30.4.4 [thread.once] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2011-08-30 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In function <tt>call_once</tt> 30.4.4.2 [thread.once.callonce]
paragraph 4 and 5 specify for <tt>call_once()</tt>:
</p>

<blockquote>
<p>
<i>Throws</i>: <tt>system_error</tt> when an exception is required (30.2.2 [thread.req.exception]), 
or any exception thrown by <tt>func</tt>.
<p/>
<i>Error conditions</i>:
</p>
<ul>
<li><tt>invalid_argument</tt> &mdash; if the <tt>once_flag</tt> object is no longer valid.</li>
</ul>
</blockquote>

<p>
However, nowhere in 30.4.4 [thread.once] is specified, when a once-flag becomes invalid.
<p/>
As far as I know this happens if the flag is used for different functions. So we either have to have 
to insert a sentence&#47;paragraph in
</p>
<blockquote><p>
30.4.4.2 Function call_once [thread.once.callonce]
</p></blockquote>
<p>
or
</p>
<blockquote><p>
30.4.4 Call once [thread.once]
</p></blockquote>
<p>
explaining when a <tt>once_flag</tt> becomes invalidated or we should state as error condition something like:
</p>

<ul>
<li><tt>invalid_argument</tt> &mdash; if the <tt>func</tt> used in combination with the <tt>once_flag</tt> is different 
from a previously passed <tt>func</tt> for the same <tt>once_flag</tt>
</li>
</ul>

<p>
Anthony Williams:
</p>
<blockquote>
<p>
A <tt>once_flag</tt> is invalidated if you destroy it (e.g. it is an automatic object, or heap 
allocated and deleted, etc.)
<p/>
If the library can detect that this is the case then it will throw this exception. If it cannot 
detect such a case then it will never be thrown.
</p>
</blockquote>

<p>
Jonathan Wakely:
</p>
<blockquote>
<p>
I have also wondered how that error can happen in C++, where the type
system will reject a non-callable type being passed to <tt>call_once()</tt> and
should prevent a <tt>once_flag</tt> being used after its destructor runs.
<p/>
If a <tt>once_flag</tt> is used after its destructor runs then it is indeed
undefined behaviour, so implementations are already free to throw any
exception (or set fire to a printer) without the standard saying so.
<p/>
My assumption was that it's an artefact of basing the API on pthreads,
which says:
</p>
<blockquote>
<p>
The <tt>pthread_once()</tt> function may fail if:
<p/>
<tt>[EINVAL]</tt>  If either <tt>once_control</tt> or <tt>init_routine</tt> is invalid.
</p>
</blockquote>
</blockquote>

<p>
Pete Becker:
</p>
<blockquote><p>
Yes, probably. We had to clean up several UNIXisms that were in the original design.
</p></blockquote>

<p><i>[2012, Kona]</i></p>

<p>
Remove error conditions, move to Review.
</p>



<p><b>Proposed resolution:</b></p>

<p>This wording is relative to N3337.</p>

<ol>
<li><p>Change 30.4.4.2 [thread.once.callonce] as indicated:</p>
<blockquote><pre>
template&lt;class Callable, class ...Args&gt;
void call_once(once_flag&amp; flag, Callable&amp;&amp; func, Args&amp;&amp;... args);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-4- <i>Throws</i>: <tt>system_error</tt> when an exception is required (30.2.2), or any exception thrown by <tt>func</tt>.
<p/>
<del>-5- Error conditions:</del>
</p>
<ul>
<li><del><tt>invalid_argument</tt> &mdash; if the <tt>once_flag</tt> object is no longer valid.</del></li>
</ul>
</blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2081"></a>2081. <tt>Allocator</tt> requirements should include <tt>CopyConstructible</tt></h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-08-30 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
As discussed in c++std-lib-31054 and c++std-lib-31059, the <tt>Allocator</tt>
requirements implicitly require <tt>CopyConstructible</tt> because
<tt>a.select_on_container_copy_construction()</tt> and
<tt>container.get_allocator()</tt> both return a copy by value, but the
requirement is not stated explicitly anywhere.
<p/>
In order to clarify that allocators cannot have 'explicit' copy
constructors, the requirements should include <tt>CopyConstructible</tt>.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Move to Ready.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change Table 28 &mdash; Allocator requirements in 17.6.3.5 [allocator.requirements]:</p>

<table border="1">
<caption>Table 28 &mdash; Allocator requirements</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Default</th>
</tr> 
<tr>
<td>
<tt>X a1(a);<br/>
<ins>X a1 = a;</ins></tt>
</td>
<td>
</td>
<td>
Shall not exit via an exception.<br/>
post: <tt>a1 == a</tt>
</td>
<td>
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>X a1(move(a));<br/>
<ins>X a1 = move(a);</ins></tt>
</td>
<td>
</td>
<td>
Shall not exit via an exception.<br/>
post: <tt>a1</tt> equals the prior value<br/>
of <tt>a</tt>.
</td>
<td>
</td>
</tr>
</table>

</li>

<li><p>Change 17.6.3.5 [allocator.requirements] paragraph 4:</p>

<blockquote><p>
<ins>An allocator type <tt>X</tt> shall satisfy the requirements of <tt>CopyConstructible</tt> 
(17.6.3.1 [utility.arg.requirements]).</ins> The <tt>X::pointer</tt>, <tt>X::const_pointer</tt>, 
<tt>X::void_pointer</tt>, and <tt>X::const_void_pointer</tt> types shall satisfy the requirements of 
<tt>NullablePointer</tt> (17.6.3.3 [nullablepointer.requirements]). No constructor, comparison 
operator, copy operation, move operation, or swap operation on these types shall exit via an 
exception. <tt>X::pointer</tt> and <tt>X::const_pointer</tt> shall also satisfy the requirements 
for a random access iterator (24.2 [iterator.requirements]).
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2083"></a>2083. const-qualification on <tt>weak_ptr::owner_before</tt></h3>
<p><b>Section:</b> 20.7.2.3 [util.smartptr.weak], 20.7.2.3.5 [util.smartptr.weak.obs] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Ai Azuma <b>Opened:</b> 2011-09-06 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.weak">issues</a> in [util.smartptr.weak].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Is there any reason why <tt>weak_ptr::owner_before</tt> member function templates are not const-qualified?
</p>

<p>
Daniel Kr&uuml;gler:
</p>
<blockquote><p>
I don't think so. To the contrary, without these to be const member function templates, the
semantics of the specializations <tt>owner_less&lt;weak_ptr&lt;T&gt;&gt;</tt>  and
<tt>owner_less&lt;shared_ptr&lt;T&gt;&gt;</tt> described in 20.7.2.3.7 [util.smartptr.ownerless] 
is unclear.
<p/>
It is amusing to note that this miss has remain undetected from the accepted paper
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf">n2637</a> 
on. For the suggested wording changes see below. 
</p></blockquote>


<p><i>[2012, Kona]</i></p>

<p>
Move to Ready.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change the class template <tt>weak_ptr</tt> synopsis in 20.7.2.3 [util.smartptr.weak]
as indicated:</p>
<blockquote><pre>
namespace std {
  template&lt;class T&gt; class weak_ptr {
  public:
    typedef T element_type;
    [&hellip;]
    template&lt;class U&gt; bool owner_before(shared_ptr&lt;U&gt; const&amp; b) <ins>const</ins>;
    template&lt;class U&gt; bool owner_before(weak_ptr&lt;U&gt; const&amp; b) <ins>const</ins>;
  };
  [&hellip;]
}
</pre></blockquote>
</li>
<li><p>Change the prototypes in 20.7.2.3.5 [util.smartptr.weak.obs] before p6 as indicated:</p>
<blockquote><pre>
template&lt;class U&gt; bool owner_before(shared_ptr&lt;U&gt; const&amp; b) <ins>const</ins>;
template&lt;class U&gt; bool owner_before(weak_ptr&lt;U&gt; const&amp; b) <ins>const</ins>;
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="2085"></a>2085. Wrong description of effect 1 of <tt>basic_istream::ignore</tt></h3>
<p><b>Section:</b> 27.7.2.3 [istream.unformatted] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Krzysztof Zelechowski <b>Opened:</b> 2011-09-11 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
<p><b>View all other</b> <a href="lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
27.7.2.3 [istream.unformatted] in N3242 currently has the following to say about the
semantics of <tt>basic_istream::ignore</tt>:
</p>

<blockquote><p>
[..]. Characters are extracted until any of the following occurs:
</p>
<ul>
<li>if <tt>n != numeric_limits&lt;streamsize&gt;::max()</tt> (18.3.2), <tt>n</tt> characters are extracted
</li>
</ul>
</blockquote>

<p>
This statement, apart from being slightly ungrammatical, indicates that if
(<tt>n == numeric_limits&lt;streamsize&gt;::max()</tt>), the method returns without
extracting any characters.
<p/>
The description intends to describe the observable behaviour of an
implementation in terms of logical assertions.  Logical assertions are not
"bullets" that can be "entered" but need not; they are predicates that can
evaluate to true or false.
<p/>
The description contains two predicates, either of them causes extraction to
terminate.  In the incriminated case, the first predicate is evaluates to
true because its premise is false, therefore no characters will be
extracted.
<p/>
The intended semantics would be described by the following statement:
</p>

<blockquote><p>
[..]. Characters are extracted until any of the following occurs:
</p>
<ul>
<li><tt>(n != numeric_limits&lt;streamsize&gt;::max())</tt> (18.3.2) and (<tt>n</tt>) characters
have been extracted so far.
</li>
</ul>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>Change 27.7.2.3 [istream.unformatted] p25 as indicated:</p>

<blockquote><pre>
basic_istream&lt;charT,traits&gt;&amp;
  ignore(streamsize n = 1, int_type delim = traits::eof());
</pre><blockquote><p>
-25- <i>Effects</i>: Behaves as an unformatted input function (as described in 27.7.2.3 [istream.unformatted], paragraph 1). After
constructing a <tt>sentry</tt> object, extracts characters and discards them. Characters are extracted until
any of the following occurs:
</p>
<ul>
<li><del>if</del> <tt>n != numeric_limits&lt;streamsize&gt;::max()</tt> (18.3.2.1 [limits.numeric])<del>,</del><ins>and</ins> 
<tt>n</tt> characters <del>are</del><ins>have been</ins> extracted <ins>so far</ins>
</li>
<li>end-of-file occurs on the input sequence (in which case the function calls <tt>setstate(eofbit)</tt>,
which may throw <tt>ios_base::failure</tt> (27.5.5.4 [iostate.flags]));
</li>
<li><tt>traits::eq_int_type(traits::to_int_type(c), delim)</tt> for the next available input character <tt>c</tt> 
(in which case <tt>c</tt> is extracted).
</li>
</ul>
</blockquote></blockquote>





<hr>
<h3><a name="2086"></a>2086. Overly generic type support for math functions</h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-09-22 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
<p><b>View all other</b> <a href="lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
26.8 [c.math] ends with a description of a rule set for "sufficient overloads"
in p11:
</p>

<blockquote>
<p>Moreover, there shall be additional overloads sufficient to ensure:</p>
<ol>
<li>
If any argument corresponding to a <tt>double</tt> parameter has type <tt>long double</tt>, then all arguments
corresponding to <tt>double</tt> parameters are effectively cast to <tt>long double</tt>.
</li>
<li>
Otherwise, if any argument corresponding to a <tt>double</tt> parameter has type <tt>double</tt> or an integer type,
then all arguments corresponding to <tt>double</tt> parameters are effectively cast to <tt>double</tt>.
</li>
<li>
Otherwise, all arguments corresponding to <tt>double</tt> parameters are effectively cast to <tt>float</tt>.
</li>
</ol>
</blockquote>

<p>
My impression is that this rule set is probably more generic as intended, my assumption is that it is written 
to mimic the C99&#47;C1x rule set in 7.25 p2+3 in the "C++" way:
</p>

<blockquote>
<p>
-2- Of the <tt>&lt;math.h&gt;</tt> and <tt>&lt;complex.h&gt;</tt> functions without an 
<tt>f</tt> (<tt>float</tt>) or <tt>l</tt> (<tt>long double</tt>) suffix, several have 
one or more parameters whose corresponding real type is <tt>double</tt>. For each such 
function, except <tt>modf</tt>, there is a corresponding type-generic macro. (footnote 313) 
The parameters whose corresponding real type is <tt>double</tt> in the function
synopsis are generic parameters. Use of the macro invokes a function whose
corresponding real type and type domain are determined by the arguments for the generic
parameters. (footnote 314)
<p/>
-3- Use of the macro invokes a function whose generic parameters have the corresponding 
real type determined as follows:
</p>
<ul>
<li>
First, if any argument for generic parameters has type <tt>long double</tt>, the type
determined is <tt>long double</tt>.
</li>
<li>
Otherwise, if any argument for generic parameters has type <tt>double</tt> or is of integer
type, the type determined is <tt>double</tt>.
</li>
<li>
Otherwise, the type determined is <tt>float</tt>.
</li>
</ul>
</blockquote>

<p>
where footnote 314 clarifies the intent:
</p>

<blockquote>
<p>
If the type of the argument is not compatible with the type of the parameter for the selected function,
the behavior is undefined.
</p>
</blockquote>

<p>
The combination of the usage of the unspecific term "cast" with otherwise no further constraints 
(note that C constraints the valid set to types that C++ describes as arithmetic types, but see below 
for one important difference) has the effect that it requires the following examples to be well-formed 
and well-defined:
</p>

<blockquote><pre>
#include &lt;cmath&gt;

enum class Ec { };

struct S { explicit operator long double(); };

void test(Ec e, S s) {
 std::sqrt(e); // OK, behaves like std::sqrt((float) e);
 std::sqrt(s); // OK, behaves like std::sqrt((float) s);
}
</pre></blockquote>
<p>
GCC 4.7 does not accept any of these examples.
<p/>
I found another example where the C++ rule differs from the C set, 
but in this case I'm not so sure, which direction C++ should follow. 
The difference is located in the fact, that in C enumerated types are 
<em>integer types</em> as described in 6.2.5 p17 (see e.g. n1569 or n1256):
<p/>
"The type char, the signed and unsigned integer types, and
the enumerated types are collectively called integer types. The
integer and real floating types are collectively called real types."
<p/>
This indicates that in C the following code
</p>
<blockquote><pre>
#include &lt;math.h&gt;

enum E { e };

void test(void) {
  sqrt(e); // OK, behaves like sqrt((double) e);
}
</pre></blockquote>
<p>
seems to be well-defined and <tt>e</tt> is cast to <tt>double</tt>, but in C++
referring to
</p>
<blockquote><pre>
#include &lt;cmath&gt;

enum E { e };

void test() {
  std::sqrt(e); // OK, behaves like sqrt((float) e);
}
</pre></blockquote>

<p>
is also well-defined (because of our lack of constraints) but we
must skip bullet 2 (because E is not an integer type) and effectively
cast <tt>e</tt> to <tt>float</tt>. Accepting this, we would introduce 
a silent, but observable runtime difference for C and C++.
<p/>
GCC 4.7 does not accept this example, but causes an ambiguity
error among the three floating point overloads of sqrt.
<p/>
My current suggestion to fix these problems would be to constrain the 
valid argument types of these functions to arithmetic types.
</p>

<blockquote><p>
Howard provided wording to solve the issue.
</p></blockquote>

<p><i>[2012, Kona]</i></p>

<p>
Moved to Ready.  The proposed wording reflects both original intent from
TR1, and current implementations.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>Change 26.8 [c.math] p11 as indicated:</p>

<blockquote>
<p>Moreover, there shall be additional overloads sufficient to ensure:</p>
<ol>
<li>
If any <ins>arithmetic</ins> argument corresponding to a <tt>double</tt> parameter has 
type <tt>long double</tt>, then all <ins>arithmetic</ins> arguments corresponding to 
<tt>double</tt> parameters are effectively cast to <tt>long double</tt>.
</li>
<li>
Otherwise, if any <ins>arithmetic</ins> argument corresponding to a <tt>double</tt> 
parameter has type <tt>double</tt> or an integer type, then all <ins>arithmetic</ins> 
arguments corresponding to <tt>double</tt> parameters are effectively cast to <tt>double</tt>.
</li>
<li>
Otherwise, all <ins>arithmetic</ins> arguments corresponding to <tt>double</tt> parameters 
<del>are effectively cast to</del><ins>have type</ins> <tt>float</tt>.
</li>
</ol>
</blockquote>






<hr>
<h3><a name="2087"></a>2087. <tt>iostream_category()</tt> and <tt>noexcept</tt></h3>
<p><b>Section:</b> 27.5 [iostreams.base] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2011-09-22 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#iostreams.base">issues</a> in [iostreams.base].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In <tt>&lt;system_error&gt;</tt> we have:
</p>

<blockquote><pre>
const error_category&amp; generic_category() noexcept;
const error_category&amp; system_category() noexcept;
</pre></blockquote>

<p>
In <tt>&lt;future&gt;</tt> we have:
</p>

<blockquote><pre>
const error_category&amp; future_category() noexcept;
</pre></blockquote>

<p>
But in <tt>&lt;ios&gt;</tt> we have:
</p>

<blockquote><pre>
const error_category&amp; iostream_category();
</pre></blockquote>

<p>
Is there any reason that <tt>iostream_category()</tt> is not declared with 
<tt>noexcept</tt> or is this an oversight?
</p>

<p>
Daniel:
<p/>
This looks like an oversight to me. We made the above
mentioned changes as part of noexcept-ifying the thread
library but <tt>iostream_category()</tt> was skipped, so it seems
to be forgotten. There should be no reason, why it cannot
be <tt>noexcept</tt>. When doing so, we should also make these functions
<tt>noexcept</tt> (similar to corresponding overloads):
</p>
<blockquote><pre>
error_code make_error_code(io_errc e);
error_condition make_error_condition(io_errc e);
</pre></blockquote>

<p>
Suggested wording provided by Daniel.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol><li>
<p>Change 27.5.1 [iostreams.base.overview], header <tt>&lt;ios&gt;</tt> synopsis 
as indicated:
</p>
<blockquote><pre>
#include &lt;iosfwd&gt;
namespace std {
  [&hellip;]
  error_code make_error_code(io_errc e) <ins>noexcept</ins>;
  error_condition make_error_condition(io_errc e) <ins>noexcept</ins>;
  const error_category&amp; iostream_category() <ins>noexcept</ins>;
}
</pre></blockquote>

</li>
<li>
<p>Change the prototype declarations in 27.5.6.5 [error.reporting] as indicated:
</p>
<blockquote><pre>
error_code make_error_code(io_errc e) <ins>noexcept</ins>;
</pre></blockquote><blockquote>
<p>
-1- <i>Returns</i>: <tt>error_code(static_cast&lt;int&gt;(e), iostream_category())</tt>.
</p>
</blockquote><blockquote><pre>
error_condition make_error_condition(io_errc e) <ins>noexcept</ins>;
</pre></blockquote><blockquote>
<p>
-2- <i>Returns</i>: <tt>error_condition(static_cast&lt;int&gt;(e), iostream_category())</tt>.
</p>
</blockquote><blockquote><pre>
const error_category&amp; iostream_category() <ins>noexcept</ins>;
</pre></blockquote><blockquote>
<p>
-3- <i>Returns</i>: A reference to an object of a type derived from class <tt>error_category</tt>.
<p/>
-4- The objects <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual functions shall behave as specified
for the class <tt>error_category</tt>. The objects <tt>name</tt> virtual function shall return a pointer to the string
<tt>"iostream"</tt>.
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2088"></a>2088. <tt>std::terminate</tt> problem</h3>
<p><b>Section:</b> 18.8.3 [exception.terminate] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-09-25 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Andrzej Krzemienski reported the following on comp.std.c++:
</p>
<blockquote>
<p>
In N3290, which is to become the official standard, in 18.8.3.4 [terminate],
paragraph 1 reads
</p>
<blockquote><p>
<i>Remarks</i>: Called by the implementation when exception handling must
be abandoned for any of several reasons (15.5.1), in effect immediately after 
evaluating the <em>throw-expression</em> (18.8.3.1). May also be called directly by the 
program.
</p></blockquote>
<p>It is not clear what is "in effect". It was clear in previous drafts where paragraphs 
1 and 2 read:
</p>
<blockquote><p>
Called by the implementation when exception handling must be
abandoned for any of several reasons (15.5.1). May also be called directly
by the program.
<p/>
<i>Effects</i>: Calls the <tt>terminate_handler</tt> function in effect
immediately after evaluating the <em>throw-expression</em> (18.8.3.1), if called by the
implementation, or calls the current <tt>terminate_handler</tt> function,
if called by the program.
</p>
</blockquote>
<p>
It was changed by N3189. The same applies to function unexpected (D. 11.4, paragraph 1).
<p/>
Assuming the previous wording is still intended, the wording can be read
"unless <tt>std::terminate</tt> is called by the program, we will use the handler
that was in effect immediately after evaluating the throw-expression".
<p/>
  This assumes that there is some throw-expression connected to every
  situation that triggers the call to <tt>std::terminate</tt>. But this is not
  the case:
</p>
<ul>
<li>
  In case <tt>std::thread</tt> is assigned to or destroyed while being joinable
  there is no throw-expression involved.
</li>
<li>
  In case <tt>std::unexpected</tt> is called by the program, <tt>std::terminate</tt> is
  triggered by the implementation - no throw-expression involved.
</li>
<li>
  In case a destructor throws during stack unwinding we have two throw-expressions 
  involved.
 </li>
 </ul>
<p>
Which one is referred to?
<p/>
In case <tt>std::nested_exception::rethrow_nested</tt> is called for an object that has 
captured no exception, there is no throw-expression involved directly (and may no throw 
be involved even indirectly).
<p/>
Next, 18.8.3.1 [terminate.handler], paragraph 2 says 
</p>
<blockquote><p>
<i>Required behavior</i>: A <tt>terminate_handler</tt> shall terminate execution
of the program without returning to the caller.
</p></blockquote>
<p>
This seems to allow that the function may exit by throwing an
exception (because word "return" implies a normal return).
<p/>
One could argue that words "terminate execution of the program" are sufficient,
but then why "without returning to the caller" would be mentioned. In
case such handler throws, noexcept specification in function <tt>std::terminate</tt> 
is violated, and <tt>std::terminate</tt> would be called recursively - should 
<tt>std::abort</tt> not be called in case of recursive <tt>std::terminate</tt> 
call? On the other hand some controlled recursion could be useful, like in the 
<a href="http://cplusplus.co.il/2010/03/21/catching-uncaught-exceptions-within-terminate/">following technique</a>.
</p>
</blockquote>

<p>
The here mentioned wording changes by N3189 in regard to 18.8.3.4 [terminate] p1 
were done for a better separation of effects (Effects element) and additional normative 
wording explanations (Remarks element), there was no meaning change intended. Further,
there was already a defect existing in the previous wording, which was not updated when 
further situations where defined, when <tt>std::terminate</tt> where supposed to be 
called by the implementation. 
<p/>
The part
<p/>
"in effect immediately after evaluating the throw-expression"
<p/>
should be removed and the quoted reference to 18.8.3.1 [terminate.handler] 
need to be part of the effects element where it refers to the current <tt>terminate_handler</tt> 
function, so should be moved just after
<p/>
"Effects: Calls the current <tt>terminate_handler</tt> function."
<p/>
It seems ok to allow a termination handler to exit via an exception, but the 
suggested idiom should better be replaced by a more simpler one based on
evaluating the current exception pointer in the terminate handler, e.g.
</p>
<blockquote><pre>
void our_terminate (void) {
  std::exception_ptr p = std::current_exception();
  if (p) {
    ... // OK to rethrow and to determine it's nature
  } else {
    ... // Do something else
  }
}
</pre></blockquote>

<p><i>[2011-12-09: Daniel comments]</i></p>


<p>
A related issue is <a href="lwg-active.html#2111">2111</a>.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Move to Open.
</p>
<p>
There is an interaction with Core issues in this area that Jens is already supplying wording
for.  Review this issue again once Jens wording is available.
</p>
<p>
Alisdair to review clause 15.5 (per Jens suggestion) and recommend any changes, then integrate
Jens wording into this issue.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2089"></a>2089. <tt>std::allocator::construct</tt> should use uniform initialization</h3>
<p><b>Section:</b> 20.6.9.1 [allocator.members] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> David Krauss <b>Opened:</b> 2011-10-07 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
When the <tt>EmplaceConstructible</tt> (23.2.1 [container.requirements.general]&#47;13) requirement is used 
to initialize an object, direct-initialization occurs. Initializing an aggregate or using a <tt>std::initializer_list</tt> 
constructor with emplace requires naming the initialized type and moving a temporary. This is a result of 
<tt>std::allocator::construct</tt> using direct-initialization, not list-initialization (sometimes called "uniform 
initialization") syntax.
<p/>
Altering <tt>std::allocator&lt;T&gt;::construct</tt> to use list-initialization would, among other things, give 
preference to <tt>std::initializer_list</tt> constructor overloads, breaking valid code in an unintuitive and 
unfixable way &mdash; there would be no way for <tt>emplace_back</tt> to access a constructor preempted by 
<tt>std::initializer_list</tt> without essentially reimplementing <tt>push_back</tt>.
</p>
<blockquote><pre>
std::vector&lt;std::vector&lt;int&gt;&gt; v;
v.emplace_back(3, 4); // v[0] == {4, 4, 4}, not {3, 4} as in list-initialization
</pre></blockquote>
<p>
The proposed compromise is to use SFINAE with <tt>std::is_constructible</tt>, which tests whether direct-initialization 
is well formed. If <tt>is_constructible</tt> is false, then an alternative <tt>std::allocator::construct</tt> overload 
is chosen which uses list-initialization. Since list-initialization always falls back on direct-initialization, the 
user will see diagnostic messages as if list-initialization (uniform-initialization) were always being used, because 
the direct-initialization overload cannot fail.
<p/>
I can see two corner cases that expose gaps in this scheme. One occurs when arguments intended for 
<tt>std::initializer_list</tt> satisfy a constructor, such as trying to emplace-insert a value of <tt>{3, 4}</tt> in 
the above example. The workaround is to explicitly specify the <tt>std::initializer_list</tt> type, as in 
<tt>v.emplace_back(std::initializer_list&lt;int&gt;(3, 4))</tt>. Since this matches the semantics as if 
<tt>std::initializer_list</tt> were deduced, there seems to be no real problem here.
<p/>
The other case is when arguments intended for aggregate initialization satisfy a constructor. Since aggregates cannot 
have user-defined constructors, this requires that the first nonstatic data member of the aggregate be implicitly 
convertible from the aggregate type, and that the initializer list have one element. The workaround is to supply an 
initializer for the second member. It remains impossible to in-place construct an aggregate with only one nonstatic 
data member by conversion from a type convertible to the aggregate's own type. This seems like an acceptably small 
hole.
<p/>
The change is quite small because <tt>EmplaceConstructible</tt> is defined in terms of whatever allocator is specified, 
and there is no need to explicitly mention SFINAE in the normative text.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Move to Open.
</p>
<p>
There appears to be a real concern with initializing aggregates, that can be performed only
using brace-initialization.  There is little interest in the rest of the issue, given the existence
of 'emplace' methods in C++11.
</p>
<p>
Move to Open, to find an acceptable solution for intializing aggregates.  There is the potential
that EWG may have an interest in this area of language consistency as well.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>Change 20.6.9.1 [allocator.members] p12 as indicated:</p>

<blockquote><pre>
template &lt;class U, class... Args&gt;
  void construct(U* p, Args&amp;&amp;... args);
</pre><blockquote>
<p>
12 <i>Effects</i>: <tt>::new((void *)p) U(std::forward&lt;Args&gt;(args)...)</tt> <ins>if <tt>is_constructible&lt;U, Args...&gt;::value</tt> 
is <tt>true</tt>, else <tt>::new((void *)p) U{std::forward&lt;Args&gt;(args)...}</tt></ins>
</p>
</blockquote></blockquote>






<hr>
<h3><a name="2091"></a>2091. Misplaced effect in <tt>m.try_lock_for()</tt></h3>
<p><b>Section:</b> 30.4.1.3 [thread.timedmutex.requirements] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2011-10-18 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#thread.timedmutex.requirements">active issues</a> in [thread.timedmutex.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.timedmutex.requirements">issues</a> in [thread.timedmutex.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>

<p>
30.4.1.3 [thread.timedmutex.requirements]&#47;4 says, in part, 
</p><blockquote><p>
"<i>Requires</i>: If the tick period of [the argument] is not exactly 
convertible &hellip; [it] shall be rounded up &hellip;"
</p></blockquote>
<p>
This doesn't belong in the requires clause. It's an effect. It belongs in paragraph 5. 
Nitpickingly, this would be a technical change: as written it imposes an obligation on 
the caller, while moving it imposes an obligation on the callee. Although that's certainly 
not what was intended.
<p/>
Peter Dimov comments:
<p/>
Not to mention that it should round down, not up. :-)
<p/>
Incidentally, I see that the wrong <tt>try_lock</tt> requirement that the caller shall not own 
the mutex has entered the standard, after all. Oh well. Let's hope that the real world 
continues to ignore it.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Remove the offending sentence from the requirements clause. Do <em>not</em> add it back 
anywhere else. The implementation already must have license to wake up late, so the 
rounding is invisible.
<p/>
Move to Review.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3337.</p>

<ol>
<li><p>Change 30.4.1.3 [thread.timedmutex.requirements]&#47;4 as indicated:</p>

<blockquote><p>
-3- The expression <tt>m.try_lock_for(rel_time)</tt> shall be well-formed and have the following semantics:
<p/>
-4- <i>Requires</i>: <del>If the tick period of <tt>rel_time</tt> is not exactly convertible to the native tick period, the
duration shall be rounded up to the nearest native tick period.</del> If <tt>m</tt> is of type <tt>std::timed_mutex</tt>,
the calling thread does not own the mutex.
</p></blockquote>

</li>
</ol>






<hr>
<h3><a name="2092"></a>2092. Vague Wording for <tt>condition_variable_any</tt></h3>
<p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2011-10-20 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.condition.condvarany">issues</a> in [thread.condition.condvarany].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>

<p>
30.5.2 [thread.condition.condvarany]&#47;4 says, in part, that 
<tt>condition_variable_any()</tt> throws an exception 
"if any native handle type manipulated is not available". 
<p/>
I don't know what that means. Is this intended to say something different 
from the analogous words for <tt>condition_variable()</tt> [30.5.1 [thread.condition.condvar]&#47;4], 
"if some non-memory resource limitation prevents initialization"? If not, 
it should be worded the same way.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Copy the corresponding wording from the <tt>condition_variable</tt> constructor in 30.5.1 [thread.condition.condvar] p4.
<p/>
Move to Review.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3337.</p>

<ol>
<li><p>Change 30.4.1.3 [thread.timedmutex.requirements]&#47;4 as indicated:</p>

<blockquote><pre>
condition_variable_any();
</pre><blockquote>
<p>
[&hellip;]
<p/>
-4- <i>Error conditions</i>:
</p>
<ul>
<li><tt>resource_unavailable_try_again</tt> &mdash; <del>if any native handle type manipulated is not available</del>
<ins>if some non-memory resource limitation prevents initialization</ins>.</li>
<li><tt>operation_not_permitted</tt> &mdash; if the thread does not have the privilege to perform the operation.</li>
</ul>
</blockquote></blockquote>

</li>
</ol>






<hr>
<h3><a name="2093"></a>2093. Throws clause of <tt>condition_variable::wait</tt> with predicate</h3>
<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2011-10-27 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>

<p>
the Throws: clause of <tt>condition_variable::wait&#47;wait_xxx</tt> functions that 
take a predicate argument is:
</p>
<blockquote><p>
<i>Throws</i>: <tt>system_error</tt> when an exception is required (30.2.2 [thread.req.exception]).
</p></blockquote>
<p>
If executing the predicate throws an exception, I would expect such exception to propagate unchanged 
to the caller, but the throws clause seems to indicate that it gets mutated into a system_error. T
hat's because of 17.5.1.4 [structure.specifications]&#47;4:
<p/>
"If Fs semantics contains a Throws:, Postconditions:, or Complexity: element, then that supersedes 
any occurrences of that element in the code sequence."
<p/>
Is my interpretation correct? Does it match the intent?
<p/>
Daniel comments:
<p/>
I don't think that this interpretation is entirely correct, the wording does not say that 
<tt>std::system_error</tt> or a derived class must be thrown, it simply is underspecified 
in this regard (The extreme interpretation is that the behaviour would be undefined, but 
that would be too far reaching I think). We have better wording for this in 
30.4.4.2 [thread.once.callonce] p4, where it says:
<p/>
"<i>Throws</i>: <tt>system_error</tt> when an exception is required (30.2.2 [thread.req.exception]), 
or any exception thrown by <tt>func</tt>."
<p/>
or in 30.3.2 [thread.thread.this] p6&#47;p9:
<p/>
"<i>Throws</i>: Nothing if <tt>Clock</tt> satisfies the <tt>TrivialClock</tt> requirements 
(20.11.3 [time.clock.req]) and operations of <tt>Duration</tt> do not throw exceptions. 
[ <i>Note</i>: instantiations of time point types and clocks supplied by the implementation 
as specified in 20.11.7 [time.clock] do not throw exceptions. &mdash; <i>end note</i> ]"
<p/>
So, the here discussed Throws elements should add lines along the lines of
<p/>
"Any exception thrown by operations of <tt>pred</tt>."
<p/>
and similar wording for time-related operations:
<p/>
"Any exception thrown by operations of <tt>Duration</tt>",
<p/>
"Any exception thrown by operations of <tt>chrono::duration&lt;Rep, Period&gt;</tt>"
</p>

<p><i>[2011-11-28: Ganesh comments and suggests wording]</i></p>


<p>
As for the discussion about the exception thrown by the manipulation of time-related objects, 
I believe the argument applies to all functions declared in 30 [thread]. Therefore, 
instead of adding wording to each member, I would simply move those requirements from 
30.3.2 [thread.thread.this] p6&#47;p9 to a new paragraph in 30.2.4 [thread.req.timing]. 
<p/>
As for 30.5.2 [thread.condition.condvarany], the member functions <tt>wait()</tt> and 
<tt>wait_until()</tt> are described only in terms of the Effects: clause (so strictly speaking, 
they need no changes), however, <tt>wait_for()</tt> is described with a full set of clauses 
including Throws: and Error conditions:. Either we should add those clauses to <tt>wait&#47;wait_until</tt> 
with changes similar to the one above, or remove paragraphs 29 to 34 entirely. By the way, 
even paragraph 26 could be removed IMHO.
</p>

<p><i>[2012, Kona]</i></p>

<p>
We like the idea behind the proposed resolution.
<p/>
Modify the first addition to read instead: "Functions that specify a timeout, will throw if an operation 
on a clock, time point, or time duration throws an exception." 
<p/>
In the note near the bottom change "even if the timeout has already expired" to "or if the timeout has 
already expired". (This is independent, but the original doesn't seem to make sense.) 
<p/>
Move to Review.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3337.</p>

<ol>
<li><p>Add a new paragraph at the end of 30.2.4 [thread.req.timing]:</p>

<blockquote>
<p>
[&hellip;]
<p/>
-6- The resolution of timing provided by an implementation depends on both operating system and hardware.
The finest resolution provided by an implementation is called the <i>native resolution</i>.
<p/>
-7- Implementation-provided clocks that are used for these functions shall meet the <tt>TrivialClock</tt> 
requirements (20.11.3 [time.clock.req]).
<p/>
<ins>-?- Functions that specify a timeout, will throw if an operation on a clock, time point, or time 
duration throws an exception. [ <i>Note</i>: instantiations of clock, time point and duration types supplied 
by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. &mdash; 
<i>end note</i>]</ins>
</p>
</blockquote>
</li>

<li><p>Change 30.3.2 [thread.thread.this] as indicated:</p>

<blockquote><pre>
template &lt;class Clock, class Duration&gt;
  void sleep_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);;
</pre><blockquote>
<p>
-4- <i>Effects</i>: Blocks the calling thread for the absolute timeout (30.2.4 [thread.req.timing]) specified by <tt>abs_time</tt>.
<p/>
-5- <i>Synchronization</i>: None.
<p/>
-6- <i>Throws</i>: <ins>timeout-related exceptions (30.2.4 [thread.req.timing]).</ins><del>Nothing if 
<tt>Clock</tt> satisfies the <tt>TrivialClock</tt> requirements (20.11.3 [time.clock.req]) and 
operations of <tt>Duration</tt> do not throw exceptions. [ <i>Note</i>: instantiations of time point types 
and clocks supplied by the implementation as specified in 20.11.7 [time.clock] do not throw 
exceptions. &mdash; <i>end note</i>]</del>
</p>
</blockquote></blockquote>

<blockquote><pre>
template &lt;class Rep, class Period&gt;
  void sleep_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);;
</pre><blockquote>
<p>
-7- <i>Effects</i>: Blocks the calling thread for the relative timeout (30.2.4 [thread.req.timing]) specified by <tt>rel_time</tt>.
<p/>
-8- <i>Synchronization</i>: None.
<p/>
-9- <i>Throws</i>: <ins>timeout-related exceptions (30.2.4 [thread.req.timing]).</ins><del>Nothing 
if operations of <tt>chrono::duration&lt;Rep, Period&gt;</tt> do not throw exceptions. 
[ <i>Note</i>: instantiations of time point types and clocks supplied by the implementation
as specified in 20.11.7 [time.clock] do not throw exceptions. &mdash; <i>end note</i>]</del>
</p>
</blockquote></blockquote>

</li>

<li><p>Change 30.4.1.3 [thread.timedmutex.requirements] as indicated:</p>

<p>
-3- The expression <tt>m.try_lock_for(rel_time)</tt> shall be well-formed and have the following semantics:
<p/>
[&hellip;]
<p/>
-5- <i>Effects</i>: The function attempts to obtain ownership of the mutex within the relative timeout (30.2.4 [thread.req.timing])
specified by <tt>rel_time</tt>. If the time specified by <tt>rel_time</tt> is less than or equal to <tt>rel_time.zero()</tt>, the
function attempts to obtain ownership without blocking (as if by calling <tt>try_lock()</tt>). The function
shall return within the timeout specified by <tt>rel_time</tt> only if it has obtained ownership of the mutex
object. [<i>Note</i>: As with <tt>try_lock()</tt>, there is no guarantee that ownership will be obtained if the lock
is available, but implementations are expected to make a strong effort to do so. &mdash; <i>end note</i>]
<p/>
[&hellip;]
<p/>
-8- <i>Synchronization</i>: If <tt>try_lock_for()</tt> returns <tt>true</tt>, prior <tt>unlock()</tt> operations on the same object
<i>synchronize with</i> (1.10 [intro.multithread]) this operation.
<p/>
-9- <i>Throws</i>: <ins>timeout-related exceptions (30.2.4 [thread.req.timing]).</ins><del>Nothing</del>.
<p/>
-10- The expression <tt>m.try_lock_until(abs_time)</tt> shall be well-formed and have the following semantics:
<p/>
[&hellip;]
<p/>
-12- <i>Effects</i>: The function attempts to obtain ownership of the mutex. If <tt>abs_time</tt> has already passed, the
function attempts to obtain ownership without blocking (as if by calling <tt>try_lock()</tt>). The function
shall return before the absolute timeout (30.2.4 [thread.req.timing]) specified by <tt>abs_time</tt> only 
if it has obtained ownership of the mutex object. [<i>Note</i>: As with <tt>try_lock()</tt>, there is no guarantee 
that ownership will be obtained if the lock is available, but implementations are expected to make a strong effort 
to do so. &mdash; <i>end note</i>]
<p/>
[&hellip;]
<p/>
-15- <i>Synchronization</i>: If <tt>try_lock_until()</tt> returns true, prior <tt>unlock()</tt> operations on the same object
<i>synchronize with</i> (1.10 [intro.multithread]) this operation.
<p/>
-16- <i>Throws</i>: <ins>timeout-related exceptions (30.2.4 [thread.req.timing]).</ins><del>Nothing</del>.
</p>
</li>

<li><p>Change 30.5.1 [thread.condition.condvar] as indicated:</p>

<blockquote><pre>
template &lt;class Predicate&gt;
  void wait(unique_lock&lt;mutex&gt;&amp; lock, Predicate pred);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-15- <i>Effects</i>: <ins>Equivalent to:</ins>
</p>
<blockquote><pre>
while (!pred())
  wait(lock);
</pre></blockquote>
<p>
[&hellip;]
<p/>
-17- <i>Throws</i>: <tt>std::system_error</tt> when an exception is required (30.2.2 [thread.req.exception])<ins>, 
timeout-related exceptions (30.2.4 [thread.req.timing]), or any exception thrown by <tt>pred</tt></ins>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
template &lt;class Clock, class Duration&gt;
  cv_status wait_until(unique_lock&lt;mutex&gt;&amp; lock,
                       const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-23- <i>Throws</i>: <tt>system_error</tt> when an exception is required (30.2.2 [thread.req.exception])
<ins>or timeout-related exceptions (30.2.4 [thread.req.timing])</ins>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
template &lt;class Rep, class Period&gt;
  cv_status wait_for(unique_lock&lt;mutex&gt;&amp; lock,
                     const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-26- <i>Effects</i>: <del>as if</del><ins>Equivalent to:</ins>
</p>
<blockquote><pre>
return wait_until(lock, chrono::steady_clock::now() + rel_time);
</pre></blockquote>
<p>
[&hellip;]
<p/>
-29- <i>Throws</i>: <tt>system_error</tt> when an exception is required (30.2.2 [thread.req.exception])
<ins>or timeout-related exceptions (30.2.4 [thread.req.timing])</ins>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
template &lt;class Clock, class Duration, class Predicate&gt;
  bool wait_until(unique_lock&lt;mutex&gt;&amp; lock,
                  const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
                  Predicate pred);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-32- <i>Effects</i>: <ins>Equivalent to:</ins>
</p>
<blockquote><pre>
while (!pred())
  if (wait_until(lock, abs_time) == cv_status::timeout)
    return pred();
return true;
</pre></blockquote>
<p>
<del>-33- <i>Returns</i>: <tt>pred()</tt></del>
<p/>
[&hellip;]
<p/>
-36- <i>Throws</i>: <tt>std::system_error</tt> when an exception is required (30.2.2 [thread.req.exception])<ins>, 
timeout-related exceptions (30.2.4 [thread.req.timing]), or any exception thrown by <tt>pred</tt></ins>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
template &lt;class Rep, class Period, class Predicate&gt;
  bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
                Predicate pred);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-39- <i>Effects</i>: <del>as if</del><ins>Equivalent to:</ins>
</p>
<blockquote><pre>
return wait_until(lock, chrono::steady_clock::now() + rel_time, std::move(pred));
</pre></blockquote>
<p>
[&hellip;]
<p/>
<del>-42- <i>Returns</i>: <tt>pred()</tt></del>
<p/>
[&hellip;]
<p/>
-44- <i>Throws</i>: <tt>system_error</tt> when an exception is required (30.2.2 [thread.req.exception])<ins>, 
timeout-related exceptions (30.2.4 [thread.req.timing]), or any exception thrown by <tt>pred</tt></ins>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

</li>

<li><p>Change 30.5.2 [thread.condition.condvarany] as indicated:</p>

<blockquote><pre>
template &lt;class Lock, class Predicate&gt;
  void wait(Lock&amp; lock, Predicate pred);
</pre><blockquote>
<p>
-14- <i>Effects</i>: <ins>Equivalent to:</ins>
</p>
<blockquote><pre>
while (!pred())
  wait(lock);
</pre></blockquote>
</blockquote></blockquote>

<blockquote><pre>
template &lt;class Lock, class Clock, class Duration&gt;
  cv_status wait_until(Lock&amp; lock, const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-18- <i>Throws</i>: <tt>system_error</tt> when an exception is required (30.2.2 [thread.req.exception])
<ins>or any timeout-related exceptions (30.2.4 [thread.req.timing])</ins>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
template &lt;class Lock, class Rep, class Period&gt;
  cv_status wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-20- <i>Effects</i>: <del>as if</del><ins>Equivalent to:</ins>
</p>
<blockquote><pre>
return wait_until(lock, chrono::steady_clock::now() + rel_time);
</pre></blockquote>
<p>
[&hellip;]
<p/>
-23- <i>Throws</i>: <tt>system_error</tt> when an exception is required (30.2.2 [thread.req.exception])
<ins>or any timeout-related exceptions (30.2.4 [thread.req.timing])</ins>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
template &lt;class Lock, class Clock, class Duration, class Predicate&gt;
  bool wait_until(Lock&amp; lock, const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time, Predicate pred);
</pre><blockquote>
<p>
-25- <i>Effects</i>: <ins>Equivalent to:</ins>
</p>
<blockquote><pre>
while (!pred())
  if (wait_until(lock, abs_time) == cv_status::timeout)
    return pred();
return true;
</pre></blockquote>
<p>
-26- <del><i>Returns</i>: <tt>pred()</tt></del><ins>[<i>Note</i>: There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>, 
or if the timeout has already expired. &mdash; <i>end note</i>]</ins>
<p/>
-27- [<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>

<blockquote><pre>
template &lt;class Lock, class Rep, class Period, class Predicate&gt;
  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
</pre><blockquote>
<p>
-28- <i>Effects</i>: <del>as if</del><ins>Equivalent to:</ins>
</p>
<blockquote><pre>
return wait_until(lock, chrono::steady_clock::now() + rel_time, std::move(pred));
</pre></blockquote>
<p>
<del>-29- [<i>Note</i>: There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>, 
even if the timeout has already expired. &mdash; <i>end note</i>]</del>
<del>-30- <i>Postcondition</i>: <tt>lock</tt> is locked by the calling thread.</del>
<p/>
<del>-31- <i>Returns</i>: <tt>pred()</tt></del>
<p/>
<del>-32- [<i>Note</i>: The returned value indicates whether the predicate evaluates to <tt>true</tt> 
regardless of whether the timeout was triggered. &mdash; <i>end note</i>]</del>
<p/>
<del>-33- <i>Throws</i>: <tt>system_error</tt> when an exception is required (30.2.2 [thread.req.exception]).</del>
<p/>
<del>-34- <i>Error conditions</i>:</del>
</p>
<ul>
<li><del>equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.</del></li>
</ul>
</blockquote></blockquote>

</li>
</ol>





<hr>
<h3><a name="2094"></a>2094. <tt>duration</tt> conversion overflow shouldn't participate in overload resolution</h3>
<p><b>Section:</b> 20.11.5.1 [time.duration.cons] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Vicente J. Botet Escriba <b>Opened:</b> 2011-10-31 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#time.duration.cons">issues</a> in [time.duration.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>

<p>
20.11.5.1 [time.duration.cons] says:
</p>
<blockquote><pre>
template &lt;class Rep2, class Period2&gt;
  constexpr duration(const duration&lt;Rep2, Period2&gt;&amp; d);
</pre><blockquote>
<p>
<i>Remarks</i>: This constructor shall not participate in overload resolution unless 
<tt>treat_as_floating_point&lt;rep&gt;::value</tt> is <tt>true</tt> or both 
<tt>ratio_divide&lt;Period2, period&gt;::den</tt> is <tt>1</tt> and <tt>treat_as_floating_point&lt;Rep2&gt;::value</tt> 
is <tt>false</tt>.
</p></blockquote></blockquote>
<p>
The evaluation of <tt>ratio_divide&lt;Period2, period&gt;::den</tt> could make 
<tt>ratio_divide&lt;Period2, period&gt;::num</tt> overflow.
<p/>
This occur for example when we try to create a millisecond (<tt>period</tt>=<tt>ratio&lt;1,1000&gt;</tt>) 
from an exa-second (<tt>Period2</tt>=<tt>ratio&lt;10<sup>18</sup>&gt;</tt>).
<p/>
<tt>ratio_divide&lt;ratio&lt;10<sup>18</sup>&gt;, ratio&lt;1,1000&gt;&gt;::num</tt> is 
<tt>10<sup>21</sup></tt> which overflows which makes the compiler error.
<p/>
If the function <tt>f</tt> is overloaded with milliseconds and seconds
</p>
<blockquote><pre>
void f(milliseconds);
void f(seconds);
</pre></blockquote>
<p>
The following fails to compile.
</p>
<blockquote><pre>
duration&lt;int,exa&gt; r(1);
f(r);
</pre></blockquote>
<p>
While the conversion to seconds work, the conversion to milliseconds make the program fail at compile time. 
In my opinion, this program should be well formed and the constructor from <tt>duration&lt;int,exa&gt;</tt> 
to milliseconds shouldn't participate in overload resolution as the result can not be represented.
<p/>
I think the wording of the standard can be improved so no misinterpretations are possible by adding that 
"no overflow is induced by the conversion".
</p>

<p><i>[2012, Kona]</i></p>

<p>
Move to Review.
</p>
<p>Pete: The wording is not right.</p>
<p>Howard: Will implement this to be sure it works.</p>
<p>Jeffrey: If ratio needs a new hook, should it be exposed to users for their own uses?</p>
<p>Pete: No.</p>

<p>
Move to Review,
Howard to implement in a way that mere mortals can understand.
</p>





<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>Change the following paragraphs of 20.11.5.1 [time.duration.cons] p4 indicated:</p>

<blockquote><pre>
template &lt;class Rep2, class Period2&gt;
  constexpr duration(const duration&lt;Rep2, Period2&gt;&amp; d);
</pre><blockquote>
<p>
<i>Remarks</i>: This constructor shall not participate in overload resolution unless <ins>no 
overflow is induced in the conversion and</ins> <tt>treat_as_floating_point&lt;rep&gt;::value</tt> 
is <tt>true</tt> or both <tt>ratio_divide&lt;Period2, period&gt;::den</tt> is <tt>1</tt> and 
<tt>treat_as_floating_point&lt;Rep2&gt;::value</tt> is <tt>false</tt>. [ <i>Note</i>: This 
requirement prevents implicit truncation error when converting between integral-based duration 
types. Such a construction could easily lead to confusion about the value of the 
duration. &mdash; <i>end note</i> ]
</p></blockquote></blockquote>






<hr>
<h3><a name="2095"></a>2095. <tt>promise</tt> and <tt>packaged_task</tt> missing constructors needed for uses-allocator construction</h3>
<p><b>Section:</b> 30.6.5 [futures.promise], 30.6.9 [futures.task] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-11-01 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
This example is ill-formed according to C++11 because <tt>uses_allocator&lt;promise&lt;R&gt;, A&gt;::value</tt> is true, but
<tt>is_constructible&lt;promise&lt;R&gt;, A, promise&lt;R&gt;&amp;&amp;&gt;::value</tt> is false. Similarly for <tt>packaged_task</tt>.
</p>
<blockquote><pre>
#include &lt;future&gt;
#include &lt;memory&gt;
#include &lt;tuple&gt;

using namespace std;

typedef packaged_task&lt;void()&gt; task;
typedef promise&lt;void&gt; prom;
allocator&lt;task&gt; a;

tuple&lt;task, prom&gt; t1{ allocator_arg, a };
tuple&lt;task, prom&gt; t2{ allocator_arg, a, task{}, prom{} };
</pre></blockquote>
<p>
<p/>
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Add to 30.6.5 [futures.promise], class template <tt>promise</tt> synopsis, 
as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class R&gt;
  class promise {
  public:
    promise();
    template &lt;class Allocator&gt;
    promise(allocator_arg_t, const Allocator&amp; a);
    <ins>template &lt;class Allocator&gt;
    promise(allocator_arg_t, const Allocator&amp; a, promise&amp;&amp; rhs) noexcept;</ins>
    promise(promise&amp;&amp; rhs) noexcept;
    promise(const promise&amp; rhs) = delete;
    ~promise();	
    [&hellip;]
  };
  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Change 30.6.5 [futures.promise] as indicated:</p>

<blockquote><pre>
promise(promise&amp;&amp; rhs) noexcept;
<ins>template &lt;class Allocator&gt;
promise(allocator_arg_t, const Allocator&amp; a, promise&amp;&amp; rhs) noexcept;</ins>
</pre><blockquote>
<p>
-5- <i>Effects</i>: constructs a new <tt>promise</tt> object and transfers ownership of 
the shared state of <tt>rhs</tt> (if any) to the newly-constructed object.
<p/>
-6- <i>Postcondition</i>: <tt>rhs</tt> has no shared state.
<p/>
<ins>-?- [<i>Note</i>: <tt>a</tt> is not used &mdash; <i>end note</i>]</ins>
</p>
</blockquote></blockquote>

</li>

<li><p>Add to 30.6.9 [futures.task], class template <tt>packaged_task</tt> synopsis, 
as indicated:</p>

<blockquote><pre>
namespace std {
  template&lt;class&gt; class packaged_task; // <i>undefined</i>

  template&lt;class R, class... ArgTypes&gt;
  class packaged_task&lt;R(ArgTypes...)&gt; {
  public:
    // construction and destruction
    packaged_task() noexcept;
    template &lt;class F&gt;
    explicit packaged_task(F&amp;&amp; f);
    <ins>template &lt;class Allocator&gt;
    explicit packaged_task(allocator_arg_t, const Allocator&amp; a) noexcept;
    template &lt;class Allocator&gt;
    explicit packaged_task(allocator_arg_t, const Allocator&amp; a, packaged_task&amp;&amp; rhs) noexcept;
    template&lt;class Allocator&gt;
    explicit packaged_task(allocator_arg_t, const Allocator&amp; a, const packaged_task&amp;) = delete;</ins>
    template &lt;class F, class Allocator&gt;
    explicit packaged_task(allocator_arg_t, const Allocator&amp; a, F&amp;&amp; f);
    ~packaged_task();
    [&hellip;]
  };
  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Change 30.6.9.1 [futures.task.members] as indicated:</p>

<blockquote><pre>
packaged_task() noexcept;
<ins>template &lt;class Allocator&gt;
  explicit packaged_task(allocator_arg_t, const Allocator&amp; a) noexcept;</ins>
</pre><blockquote>
<p>
-1- <i>Effects</i>: constructs a <tt>packaged_task</tt> object with no shared state and no stored task.
<p/>
<ins>-?- [<i>Note</i>: <tt>a</tt> is not used &mdash; <i>end note</i>]</ins>
</p>
</blockquote></blockquote>
<p>[&hellip;]</p>
<blockquote><pre>
packaged_task(packaged_task&amp;&amp; rhs) noexcept;
<ins>template &lt;class Allocator&gt;
  explicit packaged_task(allocator_arg_t, const Allocator&amp; a, packaged_task&amp;&amp; rhs) noexcept;</ins>
</pre><blockquote>
<p>
-5- <i>Effects</i>: constructs a new <tt>packaged_task</tt> object and transfers ownership of <tt>rhs</tt>s 
shared state to <tt>*this</tt>, leaving <tt>rhs</tt> with no shared state. Moves the stored task from <tt>rhs</tt> 
to <tt>*this</tt>.
<p/>
-6- <i>Postcondition</i>: <tt>rhs</tt> has no shared state.
<p/>
<ins>-?- [<i>Note</i>: <tt>a</tt> is not used &mdash; <i>end note</i>]</ins>
</p>
</blockquote></blockquote>

</li>
</ol>

<blockquote><pre>
</pre><blockquote>
<p>
</p></blockquote></blockquote>






<hr>
<h3><a name="2097"></a>2097. <tt>packaged_task</tt> constructors should be constrained</h3>
<p><b>Section:</b> 30.6.9.1 [futures.task.members] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-11-02 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.task.members">active issues</a> in [futures.task.members].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.task.members">issues</a> in [futures.task.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
With the proposed resolution of <a href="lwg-defects.html#2067">2067</a>, this no longer selects the
copy constructor:
</p>
<blockquote><pre>
std::packaged_task&lt;void()&gt; p1;
std::packaged_task&lt;void()&gt; p2(p1);
</pre></blockquote>
<p>
Instead this constructor is a better match:
</p>
<blockquote><pre>
template &lt;class F&gt;
 explicit packaged_task(F&amp;&amp; f);
</pre></blockquote>
<p>
This attempts to package a <tt>packaged_task</tt>, which internally tries to
copy <tt>p2</tt>, which fails because the copy constructor is deleted. For at
least one implementation the resulting error message is much less
helpful than the expected "cannot call deleted function" because it
happens after instantiating several more templates rather than in the
context where the constructor is called.
<p/>
I believe the solution is to constrain to the template constructors so
the template argument <tt>F</tt> cannot be deduced as (possibly <i>cv</i>)
<tt>packaged_task&amp;</tt> or <tt>packaged_task</tt>.  It could be argued 
this constraint is already implied because <tt>packaged_task</tt> is not 
copyable and the template constructors require that "invoking a copy of <tt>f</tt> 
shall behave the same as invoking <tt>f</tt>".
<p/>
Daniel points out that the variadic constructor of <tt>std::thread</tt>
described in 30.3.1.2 [thread.thread.constr] has a similar problem and 
suggests a similar wording change, which has been integrated below.
<p/>
An alternative is to declare <tt>thread(thread&amp;)</tt> and
<tt>packaged_task(packaged_task&amp;)</tt> as deleted.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Insert a new Remarks element to 30.3.1.2 [thread.thread.constr] around p3 as indicated:</p>

<blockquote><pre>
template &lt;class F, class ...Args&gt; explicit thread(F&amp;&amp; f, Args&amp;&amp;... args);
</pre></blockquote>
<p>
-3- <i>Requires</i>: <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall satisfy the <tt>MoveConstructible</tt> 
requirements. <tt><i>INVOKE</i>(<i>DECAY_COPY</i> ( std::forward&lt;F&gt;(f)), <i>DECAY_COPY</i> (std::forward&lt;Args&gt;(args))...)</tt> 
(20.8.2) shall be a valid expression.
<p/>
<ins>-?- <i>Remarks</i>: This constructor shall not participate in overload resolution if <tt>decay&lt;F&gt;::type</tt> 
is the same type as <tt>std::thread</tt>.</ins>
</p>
</li>

<li><p>Insert a new Remarks element to 30.6.9.1 [futures.task.members] around p2 as indicated:</p>

<blockquote><pre>
template &lt;class F&gt;
  packaged_task(F&amp;&amp; f);
template &lt;class F, class Allocator&gt;
  explicit packaged_task(allocator_arg_t, const Allocator&amp; a, F&amp;&amp; f);
</pre></blockquote>
<p>
-2- <i>Requires</i>: <tt><i>INVOKE</i>(f, t1, t2, ..., tN, R)</tt>, where <tt>t1, t2, ..., tN</tt> are values of the corresponding
types in <tt>ArgTypes...</tt>, shall be a valid expression. Invoking a copy of <tt>f</tt> shall behave the same as invoking <tt>f</tt>.
<p/>
<ins>-?- <i>Remarks</i>: These constructors shall not participate in overload resolution if <tt>decay&lt;F&gt;::type</tt> 
is the same type as <tt>std::packaged_task&lt;R(ArgTypes...)&gt;</tt>.</ins>
</p>
</li>

</ol>






<hr>
<h3><a name="2098"></a>2098. Minor Inconsistency between <tt>promise::set_value</tt> and <tt>promise::set_value_at_thread_exit</tt></h3>
<p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2011-11-14 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
30.6.5 [futures.promise]&#47;16 says that <tt>promise::set_value(const R&amp;)</tt> throws any exceptions 
thrown by <tt>R</tt>'s copy constructor, and that <tt>promise_set_value(R&amp;&amp;)</tt> throws any exceptions 
thrown by <tt>R</tt>'s move constructor.
<p/>
30.6.5 [futures.promise]&#47;22 is the Throws: clause for <tt>promise::set_value_at_thread_exit</tt>. It 
has no corresponding requirements, only that these functions throw "<tt>future_error</tt> if an error condition 
occurs."
<p/>
Daniel suggests wording to fix this: The approach is a bit more ambitious and also attempts to fix wording glitches
of 30.6.5 [futures.promise]&#47;16, because it would be beyond acceptable efforts of implementations to 
determine whether a constructor call of a user-defined type will indeed call a copy constructor or move constructor 
(in the first case it might be a template constructor, in the second case it might also be a copy-constructor, 
if the type has no move constructor).
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change 30.6.5 [futures.promise]&#47;16 as indicated:</p>
<blockquote><pre>
void promise::set_value(const R&amp; r);
void promise::set_value(R&amp;&amp; r);
void promise&lt;R&amp;&gt;::set_value(R&amp; r);
void promise&lt;void&gt;::set_value();
</pre><blockquote><p>
[&hellip;]
<p/>
-16- <i>Throws</i>:
</p>
<ul>
<li><tt>future_error</tt> if its shared state already has a stored value or exception, or</li>
<li>for the first version, any exception thrown by the <del>copy constructor 
of</del><ins>constructor selected to copy an object of</ins> <tt>R</tt>, or</li>
<li>for the second version, any exception thrown by the <del>move constructor 
of</del><ins>constructor selected to move an object of</ins> <tt>R</tt>.</li>
</ul>
</blockquote></blockquote>
</li>

<li><p>Change 30.6.5 [futures.promise]&#47;22 as indicated:</p>
<blockquote><pre>
void promise::set_value_at_thread_exit(const R&amp; r);
void promise::set_value_at_thread_exit(R&amp;&amp; r);
void promise&lt;R&amp;&gt;::set_value_at_thread_exit(R&amp; r);
void promise&lt;void&gt;::set_value_at_thread_exit();
</pre><blockquote><p>
[&hellip;]
<p/>
-16- <i>Throws</i>: <del><tt>future_error</tt> if an error condition occurs.</del>
</p>
<ul>
<li><ins><tt>future_error</tt> if its shared state already has a stored value or exception, or</ins></li>
<li><ins>for the first version, any exception thrown by the constructor selected to copy an object of <tt>R</tt>, or</ins></li>
<li><ins>for the second version, any exception thrown by the constructor selected to move an object of <tt>R</tt>.</ins></li>
</ul>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2099"></a>2099. Unnecessary constraints of <tt>va_start()</tt> usage</h3>
<p><b>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-11-12 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#support.runtime">active issues</a> in [support.runtime].</p>
<p><b>View all other</b> <a href="lwg-index.html#support.runtime">issues</a> in [support.runtime].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In 18.10 [support.runtime] p3 we find (emphasis mine):
</p>
<blockquote><p>
The restrictions that ISO C places on the second parameter to the <tt>va_start()</tt> macro in header <tt>&lt;stdarg.h&gt;</tt>
are different in this International Standard. The parameter <tt>parmN</tt> is the identifier of the rightmost parameter
in the variable parameter list of the function definition (the one just before the ...).227 <em>If the parameter
<tt>parmN</tt> is <strong>declared</strong> with a <strong>function</strong>, <strong>array</strong></em>, or reference type, 
or with a type that is not compatible with the type that results when passing an argument for which there is no parameter, 
the behavior is undefined.
</p></blockquote>

<p>
It seems astonishing that the constraints on function types and array types imposes these 
on the <strong>declared</strong> parameter <tt>parmN</tt>, not to the adjusted one (which would
not require this extra wording, because that is implicit). This seems to say that a function 
definition of the form (Thanks to Johannes Schaub for this example)
</p>
<blockquote><pre>
#include &lt;stdarg.h&gt;

void f(char const paramN[], ...) {
  va_list ap;
  va_start(ap, paramN);
  va_end(ap);
}
</pre></blockquote>
<p>
would produce undefined behaviour when used.
<p/>
Similar wording exists in C99 and in the most recent C11 draft in 7.16.1.4 p4
<p/>
In my opinion the constraints in regard to array types and function types are
unnecessary and should be relaxed. Are there really implementations out in the 
wild that would (according to my understanding incorrectly) provide the declared and
not the adjusted type of <tt>paramN</tt> as deduced type to <tt>va_start()</tt>?
</p>


<p><i>[2012, Kona]</i></p>

<p>
Move to Ready.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>Change 18.10 [support.runtime] p3 as indicated:</p>
<blockquote><p>
The restrictions that ISO C places on the second parameter to the <tt>va_start()</tt> macro in header <tt>&lt;stdarg.h&gt;</tt>
are different in this International Standard. The parameter <tt>parmN</tt> is the identifier of the rightmost parameter
in the variable parameter list of the function definition (the one just before the ...).227 If the parameter
<tt>parmN</tt> is <del>declared with</del><ins>of</ins> a <del>function, array, or</del> reference type, or 
<del>with</del><ins>of</ins> a type that is not compatible with the type that results when passing an argument for 
which there is no parameter, the behavior is undefined.
</p></blockquote>






<hr>
<h3><a name="2100"></a>2100. timed waiting functions cannot timeout if <tt>launch::async</tt> policy used</h3>
<p><b>Section:</b> 30.6.8 [futures.async] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-11-14 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.async">active issues</a> in [futures.async].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.async">issues</a> in [futures.async].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
30.6.8 [futures.async] p5 says
</p>

<blockquote>
<p>
If the implementation chooses the <tt>launch::async</tt> policy,
</p>
<ul><li>a call to a waiting function on an asynchronous return object that shares the 
shared state created by this <tt>async</tt> call shall block until the associated thread has
completed, as if joined (30.3.1.5 [thread.thread.member]);</li>
</ul>
</blockquote>

<p>
That should say a non-timed waiting function, otherwise, calling a timed waiting function 
can block indefinitely waiting for the associated thread to complete, rather than timing 
out after the specified time.
<p/>
Since <tt>std::thread</tt> does not provide a <tt>timed_join()</tt> function (nor does
Pthreads, making it impossible on many platforms) there is no way for a timed waiting 
function to try to join but return early due to timeout, therefore timed waiting 
functions either cannot guarantee to timeout or cannot be used to meet the requirement 
to block until the thread is joined.  In order to allow timed waiting functions to
timeout the requirement should only apply to non-timed waiting functions.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>Change 30.6.8 [futures.async] p5 as indicated:</p>

<blockquote>
<p>
If the implementation chooses the <tt>launch::async</tt> policy,
</p>
<ul><li>a call to a <ins>non-timed</ins> waiting function on an asynchronous return object 
that shares the shared state created by this <tt>async</tt> call shall block until the 
associated thread has completed, as if joined (30.3.1.5 [thread.thread.member]);</li>
</ul>
</blockquote>






<hr>
<h3><a name="2101"></a>2101. Some transformation types can produce impossible types</h3>
<p><b>Section:</b> 20.9.7 [meta.trans] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-11-18 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Table 53 &mdash; "Reference modifications" says in regard to the type trait 
<tt>add_lvalue_reference</tt> (emphasize mine)
</p>

<blockquote>
<p>
If <tt>T</tt> names an object or <strong>function</strong> type then the member typedef type
shall name <tt>T&amp;</tt>;
</p>
</blockquote>

<p>
The problem with this specification is that function types with <i>cv</i>-qualifier or <i>ref</i>-qualifier, 
like
</p>
<blockquote><pre>
void() const
void() &amp;
</pre></blockquote>
<p>
are also affected by the first part of the rule, but this would essentially mean, that
instantiating <tt>add_lvalue_reference</tt> with such a type would attempt to form
a type that is not defined in the C++ type system, namely
</p>
<blockquote><pre>
void(&amp;)() const
void(&amp;)() &amp;
</pre></blockquote>
<p>
The general policy for <i>TransformationTrait</i>s is to define always some meaningful 
mapping type, but this does not hold for <tt>add_lvalue_reference</tt>, <tt>add_rvalue_reference</tt>,
and in addition to these two for <tt>add_pointer</tt> as well. The latter one would 
attempt to form the invalid types
</p>
<blockquote><pre>
void(*)() const
void(*)() &amp;
</pre></blockquote>
<p>
A possible reason why those traits were specified in this way is that in C++03 (and that means
for TR1), <i>cv</i>-qualifier were underspecified in the core language and several compilers
just ignored them during template instantiations. This situation became fixed by adopting
CWG issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#295">295</a> and 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#547">547</a>.
<p/>
While there is possibly some core language clarification needed (see reflector messages
starting from c++std-core-20740), it seems also clear that the library should fix the
specification. The suggested resolution follows the style of the specification of the
support concepts <tt>PointeeType</tt> and <tt>ReferentType</tt> defined in 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>.
</p>


<p><i>[21012, Kona]</i></p>

<p>
Move to NAD.
</p>
<p>
These cv- and ref-qualified function types are abberations in the type system, and do
not represent any actual entity defined by the language.  The notion of cv- and ref-
qualification applies only to the implicit <tt>*this</tt> reference in a member function.
</p>
<p>
However, these types can be produced by quirks of template metaprogramming, the question
remains what the library should do about it.  For exmaple, <tt>add_reference</tt> returns
the original type if passed a reference type, or a <tt>void</tt> type.  Conversely,
<tt>add_pointer</tt> will refurn a pointer to the referenced type when passed a reference.
</p>
<p>
It is most likely that the 'right' answer in any case will depend on the context that the
question is being asked, in terms of forming these obscure types.  The best the LWG can
do is allow an error to propogate back to the user, so they can provide their own meaningful
answer in their context - with additional metaprogramming on their part.  The consensus is
that if anyone is dangerous enough with templates to get themselves into this problem, they
will also have the skills to resolve the problem themselves.  This is not going to trip up
the non-expert developer.
</p>
<p>
Lastly, it was noted that this problem arises only because the language is inconsistent in
providing us these nonesense types that do no really represent anything in the language.
There may be some way Core or Evolution could give us a more consistent type system so that
the LWG does not need to invent an answer at all, should this question need resolving.  This
is another reason to not specify anything at the LWG trait level at this time, leaving the
other working groups free to produce the 'right' answer that we can then follow without
changing the meaning of exisitng, well-defined programs.
</p>

<p><i>[21012, post-Kona]</i></p>

<p>
Move back to Open.  Daniel is concerned that this is not an issue we can simply ignore,
further details to follow.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change Table 53 &mdash; "Reference modifications" in 20.9.7.2 [meta.trans.ref] as indicated:</p>

<table border="1">
<caption>Table 53 &mdash; Reference modifications</caption>
<tr>
<th>Template</th>
<th>Comments</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct<br/>
add_lvalue_reference;</tt>
</td>
<td>
If <tt>T</tt> names an object <tt>type</tt> or <ins>if <tt>T</tt> names a</ins> function type <ins>that does not have<br/>
<i>cv</i>-qualifiers or a <i>ref</i>-qualifier</ins> then the member typedef <tt>type</tt><br/>
shall name <tt>T&amp;</tt>; otherwise, if <tt>T</tt> names a type rvalue reference to <tt>T1</tt> then<br/>
the member typedef <tt>type</tt> shall name <tt>T1&amp;</tt>; otherwise, <tt>type</tt> shall name <tt>T</tt>.
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct<br/>
add_rvalue_reference;</tt>
</td>
<td>
If <tt>T</tt> names an object <tt>type</tt> or <ins>if <tt>T</tt> names a</ins> function type <ins>that does not have<br/>
<i>cv</i>-qualifiers or a <i>ref</i>-qualifier</ins> then the member typedef <tt>type</tt><br/>
shall name <tt>T&amp;&amp;</tt>; otherwise, <tt>type</tt> shall name <tt>T</tt>. [ <i>Note</i>: This rule reflects<br/>
the semantics of reference collapsing (8.3.2 [dcl.ref]). For example, when a type <tt>T</tt><br/>
names a type <tt>T1&amp;</tt>, the type <tt>add_rvalue_reference&lt;T&gt;::type</tt> is not an<br/>
rvalue reference. &mdash; <i>end note</i> ]
</td>
</tr>
</table>

</li>

<li><p>Change Table 56 &mdash; "Pointer modifications" in 20.9.7.5 [meta.trans.ptr] as indicated:</p>

<table border="1">
<caption>Table 56 &mdash; Pointer modifications</caption>
<tr>
<th>Template</th>
<th>Comments</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct add_pointer;</tt>
</td>
<td>
<del>The member typedef <tt>type</tt> shall name the same type as</del><br/>
<ins>If <tt>T</tt> names a function type that has <i>cv</i>-qualifiers or a <i>ref</i>-qualifier<br/>
then the member typedef <tt>type</tt> shall name <tt>T</tt>; otherwise, it<br/> 
shall name the same type as</ins> <tt>remove_reference&lt;T&gt;::type*</tt>.
</td>
</tr>

</table>

</li>
</ol>





<hr>
<h3><a name="2103"></a>2103. <tt>std::allocator_traits&lt;std::allocator&lt;T&gt;&gt;::propagate_on_container_move_assignment</tt></h3>
<p><b>Section:</b> 20.6.9 [default.allocator] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Ai Azuma <b>Opened:</b> 2011-11-08 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#default.allocator">issues</a> in [default.allocator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
&quot;<tt>std::allocator_traits&lt;std::allocator&lt;T&gt;&gt;::propagate_on_container_move_assignment::value</tt>&quot;
is specified as &quot;false&quot;, according to (20.6.9 [default.allocator]) and (20.6.8.1 [allocator.traits.types]).
However, according to (23.2.1 [container.requirements.general]), this specification leads to the unneeded requirements
(<tt>MoveInsertable</tt> and <tt>MoveAssignable</tt> of the value type) on the move assignment operator of containers
with the default allocator. 
<p/>
Proposed resolution:
<p/>
Either of the following two changes;  
</p>
<ol>
<li>
adding the nested typedef like
&quot;<tt>typedef std::true_type propagate_on_container_move_assignment;</tt>&quot;
in the definition of <tt>std::allocator</tt> class template,
</li>
<li>
adding the explicit partial specialization of
&quot;<tt>std::allocator_traits</tt>&quot; class template for &quot;<tt>std::allocator</tt>&quot;
class template, in which &quot;<tt>propagate_on_container_move_assignment</tt>&quot;
nested typedef is specified as &quot;<tt>std::true_type</tt>&quot;. 
</li>
</ol>
<p>
Pablo prefers the first resolution.
</p>

<p><i>[2011-12-02: Pablo comments]</i></p>


<p>
This issue has potentially some overlap with <a href="lwg-active.html#2108">2108</a>. Should the trait <tt>always_compare_equal</tt>
been added, this issue's resolution should be improved based on that.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Move to Ready.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>Change 20.6.9 [default.allocator], the class template <tt>allocator</tt> synopsis as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class T&gt; class allocator;

  <i>// specialize for <tt>void</tt>:</i>
  template &lt;&gt; class allocator&lt;void&gt; {
  public:
    typedef void* pointer;
    typedef const void* const_pointer;
    <i>// reference-to-<tt>void</tt> members are impossible.</i>
    typedef void value_type;
    template &lt;class U&gt; struct rebind { typedef allocator&lt;U&gt; other; };
  };

  template &lt;class T&gt; class allocator {
  public:
    typedef size_t size_type;
    typedef ptrdiff_t difference_type;
    typedef T* pointer;
    typedef const T* const_pointer;
    typedef T&amp; reference;
    typedef const T&amp; const_reference;
    typedef T value_type;
    template &lt;class U&gt; struct rebind { typedef allocator&lt;U&gt; other; };
    <ins>typedef true_type propagate_on_container_move_assignment;</ins>

    [&hellip;]
  };
}
</pre></blockquote>






<hr>
<h3><a name="2104"></a>2104. <tt>unique_lock</tt> move-assignment should not be <tt>noexcept</tt></h3>
<p><b>Section:</b> 30.4.2.2 [thread.lock.unique] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2011-11-27 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
I just noticed that the <tt>unique_lock</tt> move-assignment operator is declared <tt>noexcept</tt>. This 
function may call <tt>unlock()</tt> on the wrapped mutex, which may throw.
<p/>
Suggested change: remove the <tt>noexcept</tt> specification from <tt>unique_lock::operator=(unique_lock&amp;&amp;)</tt> 
in 30.4.2.2 [thread.lock.unique] and 30.4.2.2.1 [thread.lock.unique.cons]. 
<p/>
Daniel:
<p/>
I think the situation is actually a bit more complex as it initially looks.
<p/>
First, the effects of the move-assignment operator are (emphasize mine):
</p>
<blockquote><p>
<i>Effects</i>: <strong>If</strong> <tt>owns</tt> calls <tt>pm->unlock()</tt>.
</p></blockquote>
<p>
Now according to the <tt>BasicLockable</tt> requirements:
</p>
<blockquote><p>
<tt>m.unlock()</tt>
<p/>
3 <i>Requires</i>: The current execution agent shall hold a lock on <tt>m</tt>.
<p/>
4 <i>Effects</i>: Releases a lock on <tt>m</tt> held by the current execution agent.
<p/>
<i>Throws</i>: Nothing.
</p></blockquote>
<p>
This shows that unlock itself is a function with narrow contract and for 
this reasons no unlock function of a mutex or lock itself does have a noexcept 
specifier according to our mental model.
<p/>
Now the move-assignment operator <strong>attempts</strong> to satisfy these
requirement of the function and calls it only when it assumes that the conditions 
are ok, so from the view-point of the caller of the move-assignment operator it 
looks as if the move-assignment operator would in total a function with a
wide contract.
<p/>
The problem with this analysis so far is, that it depends on the assumed 
correctness of the state "owns".
<p/>
Looking at the construction or state-changing functions, there do exist several 
ones that depend on caller-code satisfying the requirements and there is one 
guy, who looks most suspicious:
</p>
<blockquote><p>
<tt>unique_lock(mutex_type&amp; m, adopt_lock_t);</tt>
<p/>
11 <i>Requires</i>: The calling thread own the mutex.<br/>
[&hellip;]<br/>
13 <i>Postconditions</i>: <tt>pm == &amp;m</tt> and <tt>owns == true</tt>.<br/>
</p></blockquote>
<p>
because this function does not even call <tt>lock()</tt> (which may, but is not 
required to throw an exception if the calling thread does already own the mutex). 
So we have in fact still a move-assignment operator that might throw an exception, 
if the mutex was either constructed or used (call of lock) incorrectly.
<p/>
The correct fix seems to me to also add a "<i>Throws</i>: Nothing" element to
the move-assignment operator, because using it correctly shall now throw an
exception.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li>
<p>Change 30.4.2.2 [thread.lock.unique], class template <tt>unique_lock</tt> synopsis as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Mutex&gt;
  class unique_lock {
  public:
    typedef Mutex mutex_type;
    [&hellip;]
    unique_lock(unique_lock&amp;&amp; u) noexcept;
    unique_lock&amp; operator=(unique_lock&amp;&amp; u) <del>noexcept</del>;
    [&hellip;]
  };
}
</pre></blockquote>
</li>

<li>
<p>Change 30.4.2.2.1 [thread.lock.unique.cons] around p22 as indicated:</p>

<blockquote><pre>
unique_lock&amp; operator=(unique_lock&amp;&amp; u) <del>noexcept</del>;
</pre><blockquote>
<p>
-22- <i>Effects</i>: If <tt>owns</tt> calls <tt>pm->unlock()</tt>.
<p/>
-23- <i>Postconditions</i>: <tt>pm == u_p.pm</tt> and <tt>owns == u_p.owns</tt> (where <tt>u_p</tt> 
is the state of <tt>u</tt> just prior to this construction), <tt>u.pm == 0</tt> and <tt>u.owns == false</tt>.
<p/>
-24- [<i>Note</i>: With a recursive mutex it is possible for both <tt>*this</tt> and <tt>u</tt> to own 
the same mutex before the assignment. In this case, <tt>*this</tt> will own the mutex after the assignment 
and <tt>u</tt> will not. &mdash; <i>end note</i>]
</p>
<ins>-??- <i>Throws</i>: Nothing.</ins>
<p/>
</blockquote></blockquote>
</li>

</ol>






<hr>
<h3><a name="2105"></a>2105. Inconsistent requirements on <tt>const_iterator</tt>'s <tt>value_type</tt></h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2011-11-28 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In the FDIS, Table 96 specifies <tt>X::const_iterator</tt> as a "constant iterator type 
whose value type is <tt>T</tt>". However, Table 97 specifies <tt>X::const_reverse_iterator</tt> 
as an "iterator type whose value type is <tt>const T</tt>" and which is defined as 
<tt>reverse_iterator&lt;const_iterator&gt;</tt>. But <tt>reverse_iterator::value_type</tt> is 
just "<tt>typename iterator_traits&lt;Iterator&gt;::value_type</tt>" 24.5.1.1 [reverse.iterator], 
so <tt>const_iterator</tt> and <tt>const_reverse_iterator</tt> must have the same <tt>value_type</tt>.
</p>
<p>
The resolution to issue <a href="lwg-defects.html#322">322</a> implies that
<tt>const_reverse_iterator</tt> should change.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Move to Ready.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>Change Table 97 &mdash; "Reversible container requirements" as indicated</p>

<table border="1">
<caption>Table 97 &mdash; Reversible container requirements</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr> 

<tr>
<td>
<tt>X::reverse_-<br/>
iterator</tt>
</td>
<td>
iterator type whose value type<br/>
is <tt>T</tt>
</td>
<td>
<tt>reverse_iterator&lt;iterator&gt;</tt>
</td>
<td>
compile time
</td>
</tr>

<tr>
<td>
<tt>X::const_-<br/>
reverse_-<br/>
iterator</tt>
</td>
<td>
<ins>constant</ins> iterator type whose value type<br/>
is <tt><del>const</del> T</tt>
</td>
<td>
<tt>reverse_iterator&lt;const_iterator&gt;</tt>
</td>
<td>
compile time
</td>
</tr>
</table>







<hr>
<h3><a name="2106"></a>2106. <tt>move_iterator</tt> wrapping iterators returning prvalues</h3>
<p><b>Section:</b> 24.5.3 [move.iterators] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2011-11-30 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#move.iterators">issues</a> in [move.iterators].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Shouldn't <tt>move_iterator</tt> be specialized so that if the iterator it wraps
returns a prvalue when dereferenced, the <tt>move_iterator</tt> also returns by
value? Otherwise, it creates a dangling reference.
<p/>
Howard: I believe just changing <tt>move_iterator&lt;I&gt;::reference</tt> would do.
A direction might be testing on <tt>is_reference&lt;iterator_traits&lt;I&gt;::reference&gt;</tt>, 
or <tt>is_reference&lt;decltype(*declval&lt;I&gt;())&gt;</tt>.
<p/>
Daniel: I would prefer to use a consistent style among the iterator adaptors, so I
suggest to keep with the <tt>iterator_traits</tt> typedefs if possible. 
</p>
<blockquote><pre>
using reference = typename conditional&lt;
  is_reference&lt;typename iterator_traits&lt;Iterator&gt;::reference&gt;::value,
  value_type&amp;&amp;,
  value_type
&gt;::type;
</pre></blockquote>
<p>
We might also want to ensure that if <tt>Iterator</tt>'s <tt>reference</tt> type <em>is</em>
a reference, the referent is equal to <tt>value_type</tt> (after removal of <i>cv</i>-qualifiers). 
In <em>general</em> we have no such guarantee.
<p/>
Marc: In the default case where we don't return <tt>value_type&amp;&amp;</tt>, should we use 
<tt>value_type</tt> or should we keep the <tt>reference</tt> type of the wrapped iterator?
<p/>
Daniel: This suggestion looks appealing at first, but the problem here is that using this typedef
can make it impossible for <tt>move_iterator</tt> to satisfy its contract, which means returning
an rvalue of the value type (Currently it says rvalue-reference, but this must be fixed as of
this issue anyway). I think that user-code can reasonably expect that when it has constructed
an object <tt>m</tt> of <tt>move_iterator&lt;It&gt;</tt>, where <tt>It</tt> is a valid 
mutable iterator type, the expression
</p>
<blockquote><pre>
<span style="color:#C80000;font-weight:bold">It::value_type&amp;&amp; rv = *m;</span>
</pre></blockquote>
<p>
is well-formed.
<p/>
Let's set <tt>R</tt> equal to <tt>iterator_traits&lt;Iterator&gt;::reference</tt>
in the following. We can discuss the following situations:
</p>
<ol><li><tt>R</tt> is a reference type: We can only return the corresponding xvalue of <tt>R</tt>,
if <tt>value_type</tt> is reference-related to the referent type, else this is presumably no
forward iterator and we cannot say much about it, except that it must be convertible to
<tt>value_type</tt>, so it better should return a prvalue.</li>
<li><tt>R</tt> is not a reference type: In this case we can rely on a conversion to
<tt>value_type</tt> again, but not much more. Assume we would return <tt>R</tt> directly,
this might turn out to have a conversion to an lvalue-reference type of the value type (for
example). If that is the case, this would indirectly violate the contract of 
<tt>move_iterator</tt>.</li>
</ol>
<p>
In regard to the first scenario I suggest that implementations are simply required to
check that <tt>V2 = remove_cv&lt;remove_reference&lt;R&gt;::type&gt;::type</tt> is equal
to the value type <tt>V1</tt> as a criterion to return this reference as an xvalue, in all other
cases it should return the value type directly as prvalue.
<p/>
The additional advantage of this strategy is, that we always ensure that <tt>reference</tt> has 
the correct <i>cv</i>-qualification, if <tt>R</tt> is a real reference.
<p/>
It is possible to improve this a bit by indeed supporting reference-related types,
this would require to test <tt>is_same&lt;V1, V2&gt;::value || is_base_of&lt;V1, V2&gt;::value</tt> 
instead. I'm unsure whether (a) this additional effort is worth it and (b) a strict reading of
the forward iterator requirements seems not to allow to return a reference-related type (Whether 
this is a defect or not is another question).
</p>

<p><i>[2011-12-05: Marc Glisse comments and splits into two resolution alternatives]</i></p>


<p>
I guess I am looking at the speed of:
</p>
<blockquote><pre>
value_type x;
x = *m;
</pre></blockquote>
<p>
(copy construction would likely trigger copy elision and thus be neutral)

instead of the validity of:
</p>
<blockquote><pre>
value_type&amp;&amp; x = *m;
</pre></blockquote>
<p>
In this sense, Daniels earlier proposition that ignored <tt>value_type</tt> and just did 
switch_lvalue_ref_to_rvalue_ref&lt;reference&gt; was easier to understand (and it didn't 
require thinking about reference related types).
<p/>
The currently proposed resolution has been split into two alternatives.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Move to Review.
</p>
<p>
Alisdair: This only applies to input iterators, so keep that in mind when thinking about this.
</p>
<p>
STL: I see what B is doing, but not A.
</p>
<p>
Howard: I agree.
</p>
<p>
Alisdair: Should we use <tt>add_rvalue_reference</tt>?
</p>
<p>
STL: No, we do not want reference collapsing.
</p>
<p>
STL: Re A, messing with the CV qualification scares me.
</p>
<p>
Alisdair: Agree. That would break my intent.
</p>
<p>
STL: Actually I don't think it's actually wrong, but I still don't see what it's doing.
</p>
<p>
Alisdair: A is picking the value type, B is picking the proxy type.
</p>
<p>
Howard: I like returning the proxy type.
</p>
<p>
STL: Returning a reference (B) seems right, because the requirements say "reference".
I suspect that B works correctly if you have a move iterator wrapping a move iterator
wrapping a thing.  I think that A would mess up the type in the middle.
</p>
<p>
Considerable discussion about which version is correct, checking various examples.
</p>
<p>
STL: Still think B is right. Still don't understand A. In A we are losing the proxyness.
</p>
<p>
Howard: Agree 100%. We don't want to lose the proxy. If it's const, so be it.
</p>
<p>
STL: B is also understandable by mortals.
</p>
<p>
Howard: Remove to review, keep A but move it out of the proposed resolution area
(but keep it for rational).
</p>
<p>
Alisdair: Adding an explanatory note might be a good idea, if someone wants to write one.
</p>
<p>
Walter: Concerned about losing the word "reference" in p.1.
</p>
<p>
Howard: <tt>move_iterator</tt> will return an xvalue or a prvalue, both of which are rvalues.
</p>

<p><i>[Proposed resolution A, rejected in preference to the currently proposed resolution (B)

<ol>
<li><p>Change 24.5.3 [move.iterators] p1 as indicated:</p>

<blockquote><p>
Class template <tt>move_iterator</tt> is an iterator adaptor with the same behavior as the underlying iterator
except that its dereference operator implicitly converts the value returned by the underlying iterators
dereference operator to an rvalue <del>reference</del><ins>of the value type</ins>. Some generic algorithms 
can be called with move iterators to replace copying with moving.
</p></blockquote>
</li>

<li><p>Change 24.5.3.1 [move.iterator], class template <tt>move_iterator</tt> synopsis, as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Iterator&gt;
  class move_iterator {
  public:
    typedef Iterator iterator_type;
    typedef typename iterator_traits&lt;Iterator&gt;::difference_type difference_type;
    typedef Iterator pointer;
    typedef typename iterator_traits&lt;Iterator&gt;::value_type value_type;
    typedef typename iterator_traits&lt;Iterator&gt;::iterator_category iterator_category;
    typedef <del>value_type&amp;&amp;</del><ins><i>see below</i></ins> reference;
    [&hellip;]
  };
}
</pre></blockquote>

</li>

<li><p>Immediately following the class template <tt>move_iterator</tt> synopsis in 
24.5.3.1 [move.iterator] insert a new paragraph as indicated:</p>

<blockquote><p>
<ins>-?- Let <tt><i>R</i></tt> be <tt>iterator_traits&lt;Iterator&gt;::reference</tt> and
let <tt><i>V</i></tt> be <tt>iterator_traits&lt;Iterator&gt;::value_type</tt>. If 
<tt>is_reference&lt;<i>R</i>&gt;::value</tt> is <tt>true</tt> and if 
<tt>remove_cv&lt;remove_reference&lt;<i>R</i>&gt;::type&gt;::type</tt> is the same type as <tt><i>V</i></tt>, 
the template instantiation <tt>move_iterator&lt;Iterator&gt;</tt> shall define the nested type 
named <tt>reference</tt> as a synonym for <tt>remove_reference&lt;<i>R</i>&gt;::type&amp;&amp;</tt>, 
otherwise as a synonym for <tt><i>V</i></tt>.</ins>
</p></blockquote>
</li>
</ol>

]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p><strong>This section shows two mutually exclusive resolutions &mdash; only one can
be picked!</strong></p>

<ol>
<li><p>Change 24.5.3 [move.iterators] p1 as indicated:</p>

<blockquote><p>
Class template <tt>move_iterator</tt> is an iterator adaptor with the same behavior as the underlying iterator
except that its dereference operator implicitly converts the value returned by the underlying iterators
dereference operator to an rvalue <del>reference</del>. Some generic algorithms 
can be called with move iterators to replace copying with moving.
</p></blockquote>
</li>

<li><p>Change 24.5.3.1 [move.iterator], class template <tt>move_iterator</tt> synopsis, as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Iterator&gt;
  class move_iterator {
  public:
    typedef Iterator iterator_type;
    typedef typename iterator_traits&lt;Iterator&gt;::difference_type difference_type;
    typedef Iterator pointer;
    typedef typename iterator_traits&lt;Iterator&gt;::value_type value_type;
    typedef typename iterator_traits&lt;Iterator&gt;::iterator_category iterator_category;
    typedef <del>value_type&amp;&amp;</del><ins><i>see below</i></ins> reference;
    [&hellip;]
  };
}
</pre></blockquote>

</li>

<li><p>Immediately following the class template <tt>move_iterator</tt> synopsis in 
24.5.3.1 [move.iterator] insert a new paragraph as indicated:</p>

<blockquote><p>
<ins>-?- Let <tt><i>R</i></tt> be <tt>iterator_traits&lt;Iterator&gt;::reference</tt>. If 
<tt>is_reference&lt;<i>R</i>&gt;::value</tt> is <tt>true</tt>, the template instantiation 
<tt>move_iterator&lt;Iterator&gt;</tt> shall define the nested type named <tt>reference</tt> 
as a synonym for <tt>remove_reference&lt;<i>R</i>&gt;::type&amp;&amp;</tt>, 
otherwise as a synonym for <tt><i>R</i></tt>.</ins>
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="2108"></a>2108. No way to identify allocator types that always compare equal</h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-12-01 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Whether two allocator objects compare equal affects the complexity of
container copy and move assignments and also the possibility of an
exception being thrown by container move assignments. The latter point
means container move assignment cannot be <tt>noexcept</tt> when
<tt>propagate_on_container_move_assignment</tt> (POCMA) is false for the
allocator because there is no way to detect at compile-time if two
allocators will compare equal. LWG <a href="lwg-active.html#2013">2013</a> means this affects all
containers using <tt>std::allocator</tt>, but even if that is resolved, this
affects all stateless allocators which do not explicitly define POCMA
to <tt>true_type</tt>.
<p/>
One solution would be to add an "always_compare_equal" trait to
<tt>allocator_traits</tt>, but that would be duplicating information that is
already defined by the type's equality operator if that operator
always returns true. Requiring users to write <tt>operator==</tt> that simply
returns true and also explicitly override a trait to repeat the same
information would be unfortunate and risk user errors that allow the
trait and actual <tt>operator==</tt> to disagree.
<p/>
Dave Abrahams suggested a better solution in message c++std-lib-31532,
namely to allow <tt>operator==</tt> to return <tt>true_type</tt>, which is convertible
to <tt>bool</tt> but also detectable at compile-time. Adopting this as the
recommended way to identify allocator types that always compare equal
only requires a slight relaxation of the allocator requirements so
that <tt>operator==</tt> is not required to return <tt>bool</tt> exactly.
<p/>
The allocator requirements do not make it clear that it is well-defined 
to compare non-const values, that should be corrected too.
<p/>
In message c++std-lib-31615 Pablo Halpern suggested an <tt>always_compare_equal</tt> 
trait that could still be defined, but with a sensible default value rather 
than requiring users to override it, and using that to set sensible values for 
other allocator traits:
</p>
<blockquote><p>
Do we still need <tt>always_compare_equal</tt> if we can have an <tt>operator==</tt>
that returns <tt>true_type</tt>?  What would its default value be? <tt>is_empty&lt;A&gt;
|| is_convertible&lt;decltype(a == a), true_type&gt;::value</tt>, perhaps?  One
benefit I see to such a definition is that stateless C++03 allocators
that don't use the <tt>true_type</tt> idiom will still benefit from the new
trait.
<p/>
[&hellip;]
<p/>
One point that I want to ensure doesn't get lost is that if we adopt some sort of 
<tt>always_compare_equal</tt>-like trait, then <tt>propagate_on_container_swap</tt> 
and <tt>propagate_on_container_move_assignment</tt> should default to 
<tt>always_compare_equal</tt>. Doing this will eliminate unnecessary requirements 
on the container element type, as per [LWG <a href="lwg-active.html#2103">2103</a>].
</p></blockquote>
<p>
Optionally, <tt>operator==</tt> for <tt>std::allocator</tt> could be made to return 
<tt>true_type</tt>, however if LWG <a href="lwg-active.html#2103">2103</a> is adopted that is less important.
<p/>
Alberto Ganesh Barbati: Suggest either <tt>always_compare_equal</tt>,
<tt>all_objects_(are_)equivalent</tt>, or <tt>all_objects_compare_equal</tt>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change Table 27 &mdash; "Descriptive variable definitions" in 17.6.3.5 [allocator.requirements]:</p>

<table border="1">
<caption>Table 27 &mdash; Descriptive variable definitions</caption>
<tr>
<th>Variable</th>
<th>Definition</th>
</tr> 

<tr>
<td>
<tt>a3<ins>, a4</ins></tt>
</td>
<td>
<del>an rvalue of</del><ins>values of (possibly <tt>const</tt>)</ins> type <tt>X</tt>
</td>
</tr>

<tr>
<td>
<tt>b</tt>
</td>
<td>
a value of <ins>(possibly <tt>const</tt>)</ins> type <tt>Y</tt>
</td>
</tr>

</table>

</li>

<li><p>Change Table 28 &mdash; "Allocator requirements" in 17.6.3.5 [allocator.requirements]:</p>

<table border="1">
<caption>Table 28 &mdash; Allocator requirements</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Default</th>
</tr> 

<tr>
<td>
<tt><del>a1 == a2</del><ins>a3 == a4</ins></tt>
</td>
<td>
<ins>convertible to</ins> <tt>bool</tt>
</td>
<td>
returns true only if storage<br/>
allocated from each can be<br/>
deallocated via the other.<br/>
<tt>operator==</tt> shall be reflexive,<br/>
symmetric, and transitive, and<br/>
shall not exit via an exception.
</td>
<td>
</td>
</tr>

<tr>
<td>
<tt><del>a1 != a2</del><ins>a3 != a4</ins></tt>
</td>
<td>
<ins>convertible to</ins> <tt>bool</tt>
</td>
<td>
same as <tt><del>!(a1 == a2)</del><ins>!(a3 == a4)</ins></tt>
</td>
<td>
</td>
</tr>

<tr>
<td>
<tt>a<ins>3</ins> == b</tt>
</td>
<td>
<ins>convertible to</ins> <tt>bool</tt>
</td>
<td>
same as <tt>a<ins>3</ins> ==<br/>
Y::rebind&lt;T&gt;::other(b)</tt>
</td>
<td>
</td>
</tr>

<tr>
<td>
<tt>a<ins>3</ins> != b</tt>
</td>
<td>
<ins>convertible to</ins> <tt>bool</tt>
</td>
<td>
same as <tt>!(a<ins>3</ins> == b)</tt>
</td>
<td>
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>a.select_on_-<br/>
container_copy_-<br/>
construction()</tt>
</td>
<td>
<tt>X</tt>
</td>
<td>
Typically returns either <tt>a</tt> or<br/>
<tt>X()</tt>
</td>
<td>
<tt>return a;</tt>
</td>
</tr>

<tr>
<td>
<ins><tt>X::always_compares_equal</tt></ins>
</td>
<td>
<ins>Identical to or derived<br/>
from <tt>true_type</tt> or<br/>
<tt>false_type</tt></ins>
</td>
<td>
<ins><tt>true_type</tt> if the expression <tt>x1 == x2</tt> is<br/>
guaranteed to be <tt>true</tt> for any two (possibly<br/>
<tt>const</tt>) values <tt>x1, x2</tt> of type <tt>X</tt>, when<br/>
implicitly converted to <tt>bool</tt>. See Note B, below.</ins>
</td>
<td>
<ins><tt>true_type</tt>, if <tt>is_empty&lt;X&gt;::value</tt> is <tt>true</tt> or if<br/>
<tt>decltype(declval&lt;const X&amp;&gt;() == declval&lt;const X&amp;&gt;())</tt><br/> 
is convertible to <tt>true_type</tt>, otherwise <tt>false_type</tt>.</ins>
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

</table>
<p>
Note A: [&hellip;]
<p/>
<ins>Note B: If <tt>X::always_compares_equal::value</tt> or <tt>XX::always_compares_equal::value</tt> evaluate 
to <tt>true</tt> and an expression equivalent to <tt>x1 == x2</tt> or <tt>x1 != x2</tt> for any two values 
<tt>x1, x2</tt> of type <tt>X</tt> evaluates to <tt>false</tt> or <tt>true</tt>, respectively, the behaviour 
is undefined.</ins>
</p>

</li>

<li><p>Change class template <tt>allocator_traits</tt> synopsis, 20.6.8 [allocator.traits] as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Alloc&gt; struct allocator_traits {
    typedef Alloc allocator_type;
    [&hellip;]
    <ins>typedef <i>see below</i> always_compares_equal;</ins>
    typedef <i>see below</i> propagate_on_container_copy_assignment;
    [&hellip;]
  };
}
</pre></blockquote>
</li>

<li><p>Insert the following between 20.6.8.1 [allocator.traits.types] p6 and p7 as indicated:</p>

<blockquote><pre>
<ins>typedef <i>see below</i> always_compares_equal;</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Type</i>: <tt>Alloc::always_compares_equal</tt> if such a type exists; otherwise, 
<tt>true_type</tt> if <tt>is_empty&lt;Alloc&gt;::value</tt> is <tt>true</tt> or if 
<tt>decltype(declval&lt;const Alloc&amp;&gt;() == declval&lt;const Alloc&amp;&gt;())</tt> 
is convertible to <tt>true_type</tt>; otherwise, <tt>false_type</tt>
.</ins>
</p>
</blockquote></blockquote>
<blockquote><pre>
typedef <i>see below</i> propagate_on_container_copy_assignment;
</pre><blockquote>
<p>
-7- <i>Type</i>: <tt>Alloc::propagate_on_container_copy_assignment</tt> if such a type exits, 
otherwise <tt>false_type</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Change class template <tt>allocator</tt> synopsis, 20.6.9 [default.allocator] as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class T&gt; class allocator;

  <i>// specialize for <tt>void</tt>:</i>
  template &lt;&gt; class allocator&lt;void&gt; {
  public:
    typedef void* pointer;
    typedef const void* const_pointer;
    <i>// reference-to-<tt>void</tt> members are impossible.</i>
    typedef void value_type;
    template &lt;class U&gt; struct rebind { typedef allocator&lt;U&gt; other; };
  };

  template &lt;class T&gt; class allocator {
  public:
    typedef size_t size_type;
    typedef ptrdiff_t difference_type;
    typedef T* pointer;
    typedef const T* const_pointer;
    typedef T&amp; reference;
    typedef const T&amp; const_reference;
    typedef T value_type;
    template &lt;class U&gt; struct rebind { typedef allocator&lt;U&gt; other; };
    <ins>typedef true_type always_compares_equal;</ins>

    [&hellip;]
  };
}
</pre></blockquote>
</li>

</ol>






<hr>
<h3><a name="2109"></a>2109. Incorrect requirements for <tt>hash</tt> specializations</h3>
<p><b>Section:</b> 19.5.5 [syserr.hash], 20.7.2.6 [util.smartptr.hash], 20.8.12 [unord.hash], 20.13.1 [type.index.synopsis], 21.6 [basic.string.hash], 23.3.7 [vector.bool], 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="lwg-active.html#Review">Review</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-12-04 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Review">Review</a> status.</p>
<p><b>Discussion:</b></p>

<p>
20.7.2.6 [util.smartptr.hash] p2 is specified as follows:
</p>

<blockquote><p>
<i>Requires</i>: the template specializations shall meet the requirements of class template 
<tt>hash</tt> (20.8.12).
</p></blockquote>

<p>
The problem here is the usage of a <i>Requires</i> element, which is actually a pre-condition
that a <em>user</em> of a component has to satisfy. But the intent of this wording is actually
to be a requirement on implementations. The <i>Requires</i> element should be removed here and
the wording should be improved to say what it was intended for.
<p/>
We have similar situations in basically all other places where the specification of library-provided
<tt>hash</tt> specializations is defined. Usually, the <i>Requires</i> element is incorrect. In the
special case of <tt>hash&lt;unique_ptr&lt;T, D&gt;&gt;</tt> the implementation depends on 
the behaviour of <tt>hash</tt> specializations, that could be user-provided. In this case
the specification needs to separate the requirements on these specializations and those
that are imposed on the implementation.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Update wording and move to Review.
</p>
<p>
Believe a simpler formulation is to simply string the term <i>Requires:</i> and leave the
current wording intact, rather than strike the whole clause and replace it.
</p>

<p><i>[Originally proposed wording for reference
<ol>
<li><p>Change 19.5.5 [syserr.hash] as indicated:</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;error_code&gt;;
</pre><blockquote>
<p>
-1- <del><i>Requires</i>: the template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash])</del><ins>The header 
<tt>&lt;system_error&gt;</tt> provides a definition for a specialization of the 
template <tt>hash&lt;error_code&gt;</tt>. The requirements for the members of 
this specialization are given in sub-clause 20.8.12 [unord.hash]</ins>.
</p>
</blockquote></blockquote>
</li>

<li><p>Change 20.5.3 [bitset.hash] as indicated:</p>

<blockquote><pre>
template &lt;size_t N&gt; struct hash&lt;bitset&lt;N&gt; &gt;;
</pre><blockquote>
<p>
-1- <del><i>Requires</i>: the template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash])</del><ins>The header 
<tt>&lt;bitset&gt;</tt> provides a definition for a partial specialization of the 
<tt>hash</tt> class template for specializations of class template <tt>bitset&lt;N&gt;</tt>. 
The requirements for the members of instantiations of this specialization are given 
in sub-clause 20.8.12 [unord.hash]</ins>.
</p>
</blockquote></blockquote>
</li>

<li><p>Change 20.7.2.6 [util.smartptr.hash] as indicated:</p>

<blockquote><pre>
template &lt;class T, class D&gt; struct hash&lt;unique_ptr&lt;T, D&gt; &gt;;
</pre><blockquote>
<p>
-1- <del><i>Requires</i>: the template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash])</del><ins>The header 
<tt>&lt;memory&gt;</tt> provides a definition for a partial specialization of the 
<tt>hash</tt> class template for specializations of class template <tt>unique_ptr&lt;T, D&gt;</tt>. 
The requirements for the members of instantiations of this specialization are given 
in sub-clause 20.8.12 [unord.hash]</ins>. For an object <tt>p</tt> of type 
<tt>UP</tt>, where <tt>UP</tt> is <tt>unique_ptr&lt;T, D&gt;</tt>, 
<tt>hash&lt;UP&gt;()(p)</tt> shall evaluate to the same value as 
<tt>hash&lt;typename UP::pointer&gt;()(p.get())</tt>. <del>The specialization 
<tt>hash&lt;typename UP::pointer&gt;</tt> shall be well-formed.</del>
<p/>
<ins>-?- <i>Requires</i>: The specialization <tt>hash&lt;typename UP::pointer&gt;</tt> 
shall be well-formed and well-defined [<i>Note:</i> the general requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash]) are implied &mdash; 
<i>end note</i>].</ins>
</p>
</blockquote></blockquote>

<blockquote><pre>
template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt; &gt;;
</pre><blockquote>
<p>
-2- <del><i>Requires</i>: the template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash])</del><ins>The header 
<tt>&lt;memory&gt;</tt> provides a definition for a partial specialization of the 
<tt>hash</tt> class template for specializations of class template <tt>shared_ptr&lt;T&gt;</tt>. 
The requirements for the members of instantiations of this specialization are given 
in sub-clause 20.8.12 [unord.hash]</ins>. For an object <tt>p</tt> of type 
<tt>shared_ptr&lt;T&gt;</tt>, <tt>hash&lt;shared_ptr&lt;T&gt; &gt;()(p)</tt> 
shall evaluate to the same value as <tt>hash&lt;T*&gt;()(p.get())</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Change 20.8.12 [unord.hash] p2 as indicated: [<i>Comment</i>: For unknown
reasons the extended integer types are not mentioned here, which looks like an oversight to
me and makes also the wording more complicated. See <a href="lwg-active.html#2119">2119</a> for this part
of the problem. &mdash; <i>end comment</i>]</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;bool&gt;;
template &lt;&gt; struct hash&lt;char&gt;;
[&hellip;]
template &lt;&gt; struct hash&lt;long double&gt;;
template &lt;class T&gt; struct hash&lt;T*&gt;;
</pre><blockquote>
<p>
-2- <del><i>Requires</i>: the template specializations shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash])</del><ins>The header 
<tt>&lt;functional&gt;</tt> provides definitions for specializations of the 
<tt>hash</tt> class template for each <i>cv</i>-unqualified arithmetic type except 
for the extended integer types. This header also provides a definition for a partial 
specialization of the <tt>hash</tt> class template for any pointer type. The 
requirements for the members of these specializations are given in sub-clause 
20.8.12 [unord.hash]</ins>.
</p>
</blockquote></blockquote>
</li>

<li><p>Change 20.13.4 [type.index.hash] p1 as indicated:</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;type_index&gt;;
</pre><blockquote>
<p>
-1- <del><i>Requires</i>: the template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash])</del><ins>The header 
<tt>&lt;typeindex&gt;</tt> provides a definition for a specialization of the 
template <tt>hash&lt;type_index&gt;</tt>. The requirements for the members 
of this specialization are given in sub-clause 20.8.12 [unord.hash]</ins>. For 
an object <tt>index</tt> of type <tt>type_index</tt>, <tt>hash&lt;type_index&gt;()(index)</tt> 
shall evaluate to the same result as <tt>index.hash_code()</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Change 21.6 [basic.string.hash] p1 as indicated:</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;string&gt;;
template &lt;&gt; struct hash&lt;u16string&gt;;
template &lt;&gt; struct hash&lt;u32string&gt;;
template &lt;&gt; struct hash&lt;wstring&gt;;
</pre><blockquote>
<p>
-1- <del><i>Requires</i>: the template specializations shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash])</del><ins>The header 
<tt>&lt;string&gt;</tt> provides definitions for specializations of the 
<tt>hash</tt> class template for the types <tt>string</tt>, <tt>u16string</tt>,
<tt>u32string</tt>, and <tt>wstring</tt>. The requirements for the members 
of these specializations are given in sub-clause 20.8.12 [unord.hash]</ins>.
</p>
</blockquote></blockquote>
</li>

<li><p>Change 23.3.7 [vector.bool] p7 as indicated:</p>

<blockquote><pre>
template &lt;class Allocator&gt; struct hash&lt;vector&lt;bool, Allocator&gt; &gt;;
</pre><blockquote>
<p>
-7- <del><i>Requires</i>: the template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash])</del><ins>The header 
<tt>&lt;vector&gt;</tt> provides a definition for a partial specialization of the 
<tt>hash</tt> class template for specializations of class template <tt>vector&lt;bool, Allocator&gt;</tt>. 
The requirements for the members of instantiations of this specialization are given 
in sub-clause 20.8.12 [unord.hash]</ins>.
</p>
</blockquote></blockquote>
</li>

<li><p>Change 30.3.1.1 [thread.thread.id] p14 as indicated:</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;thread::id&gt;;
</pre><blockquote>
<p>
-14- <del><i>Requires</i>: the template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash])</del><ins>The header 
<tt>&lt;thread&gt;</tt> provides a definition for a specialization of the 
template <tt>hash&lt;thread::id&gt;</tt>. The requirements for the members of this 
specialization are given in sub-clause 20.8.12 [unord.hash]</ins>.
</p>
</blockquote></blockquote>
</li>

</ol>
]</i></p>




<p><b>Proposed resolution:</b></p>

<ol>
<li><p>Change 19.5.5 [syserr.hash] as indicated:</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;error_code&gt;;
</pre><blockquote>
<p>
-1- <del><i>Requires</i>: t</del><ins>T</ins>he template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash].
</p>
</blockquote></blockquote>
</li>

<li><p>Change 20.5.3 [bitset.hash] as indicated:</p>

<blockquote><pre>
template &lt;size_t N&gt; struct hash&lt;bitset&lt;N&gt; &gt;;
</pre><blockquote>
<p>
-1- <del><i>Requires</i>: t</del><ins>T</ins>he template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash]).
</p>
</blockquote></blockquote>
</li>

<li><p>Change 20.7.2.6 [util.smartptr.hash] as indicated:</p>

<blockquote><pre>
template &lt;class T, class D&gt; struct hash&lt;unique_ptr&lt;T, D&gt; &gt;;
</pre><blockquote>
<p>
-1- <del><i>Requires</i>: t</del><ins>T</ins>he template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash]). For an object <tt>p</tt> of type 
<tt>UP</tt>, where <tt>UP</tt> is <tt>unique_ptr&lt;T, D&gt;</tt>, 
<tt>hash&lt;UP&gt;()(p)</tt> shall evaluate to the same value as 
<tt>hash&lt;typename UP::pointer&gt;()(p.get())</tt>.  <del>The specialization 
<tt>hash&lt;typename UP::pointer&gt;</tt> shall be well-formed.</del>
<p/>
<ins>-?- <i>Requires</i>: The specialization <tt>hash&lt;typename UP::pointer&gt;</tt> 
shall be well-formed and well-defined, and shall meet the requirements of class template
<tt>hash</tt> (20.8.12 [unord.hash]).</ins>
</p>
</blockquote></blockquote>

<blockquote><pre>
template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt; &gt;;
</pre><blockquote>
<p>
-2- <del><i>Requires</i>: t</del><ins>T</ins>he template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash]). For an object <tt>p</tt> of type 
<tt>shared_ptr&lt;T&gt;</tt>, <tt>hash&lt;shared_ptr&lt;T&gt; &gt;()(p)</tt> 
shall evaluate to the same value as <tt>hash&lt;T*&gt;()(p.get())</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Change 20.8.12 [unord.hash] p2 as indicated: [<i>Comment</i>: For unknown
reasons the extended integer types are not mentioned here, which looks like an oversight to
me and makes also the wording more complicated. See <a href="lwg-active.html#2119">2119</a> for this part
of the problem. &mdash; <i>end comment</i>]</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;bool&gt;;
template &lt;&gt; struct hash&lt;char&gt;;
[&hellip;]
template &lt;&gt; struct hash&lt;long double&gt;;
template &lt;class T&gt; struct hash&lt;T*&gt;;
</pre><blockquote>
<p>
-2- <del><i>Requires</i>: t</del><ins>T</ins>he template specializations shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash]).
</p>
</blockquote></blockquote>
</li>

<li><p>Change 20.13.4 [type.index.hash] p1 as indicated:</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;type_index&gt;;
</pre><blockquote>
<p>
-1- <del><i>Requires</i>: t</del><ins>T</ins>he template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash]). For 
an object <tt>index</tt> of type <tt>type_index</tt>, <tt>hash&lt;type_index&gt;()(index)</tt> 
shall evaluate to the same result as <tt>index.hash_code()</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Change 21.6 [basic.string.hash] p1 as indicated:</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;string&gt;;
template &lt;&gt; struct hash&lt;u16string&gt;;
template &lt;&gt; struct hash&lt;u32string&gt;;
template &lt;&gt; struct hash&lt;wstring&gt;;
</pre><blockquote>
<p>
-1- <del><i>Requires</i>: t</del><ins>T</ins>he template specializations shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash]).
</p>
</blockquote></blockquote>
</li>

<li><p>Change 23.3.7 [vector.bool] p7 as indicated:</p>

<blockquote><pre>
template &lt;class Allocator&gt; struct hash&lt;vector&lt;bool, Allocator&gt; &gt;;
</pre><blockquote>
<p>
-7- <del><i>Requires</i>: t</del><ins>T</ins>he template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash]).
</p>
</blockquote></blockquote>
</li>

<li><p>Change 30.3.1.1 [thread.thread.id] p14 as indicated:</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;thread::id&gt;;
</pre><blockquote>
<p>
-14- <del><i>Requires</i>: t</del><ins>T</ins>he template specialization shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash]).
</p>
</blockquote></blockquote>
</li>

</ol>






<hr>
<h3><a name="2110"></a>2110. <tt>remove</tt> can't swap but note says it might</h3>
<p><b>Section:</b> 25.3.8 [alg.remove] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2011-12-07 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
25.3.8 [alg.remove]&#47;p1 says:
</p>

<blockquote><p>
1 <i>Requires</i>: The type of <tt>*first</tt> shall satisfy the <tt>MoveAssignable</tt> requirements (Table 22).
</p></blockquote>

<p>
This means that <tt>remove</tt>&#47;<tt>remove_if</tt> can only use move assignment to permute the sequence. But then 
25.3.8 [alg.remove]&#47;p6 (non-normatively) contradicts p1:
</p>

<blockquote><p>
6 <i>Note</i>: each element in the range <tt>[ret,last)</tt>, where <tt>ret</tt> is the returned value, has a valid 
but unspecified state, because the algorithms can eliminate elements by swapping with or moving from elements that 
were originally in that range.
</p></blockquote>

<p><i>[2012, Kona]</i></p>

<p>
Move to Ready.
</p>
<p>
Alisdair notes we could extend permission to use <tt>swap</tt> if it is available, but there
is no interest.  Accept the proposed resolution as written.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>Change 25.3.8 [alg.remove] as indicated:</p>

<blockquote><pre>
template&lt;class ForwardIterator, class T&gt;
  ForwardIterator remove(ForwardIterator first, ForwardIterator last,
                         const T&amp; value);

template&lt;class ForwardIterator, class Predicate&gt;
  ForwardIterator remove_if(ForwardIterator first, ForwardIterator last,
                            Predicate pred);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-6-<i>Note</i>: each element in the range <tt>[ret,last)</tt>, where <tt>ret</tt> is the 
returned value, has a valid but unspecified state, because the algorithms can eliminate 
elements by <del>swapping with or</del> moving from elements that were originally in that range.
</p>
</blockquote></blockquote>






<hr>
<h3><a name="2111"></a>2111. Which <tt>unexpected</tt>&#47;<tt>terminate</tt> handler is called from the exception handling runtime?</h3>
<p><b>Section:</b> 18.8.3.4 [terminate], D.13.3 [unexpected] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2011-12-06 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#terminate">issues</a> in [terminate].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Prior to N3242, modified by N3189, we said this about <tt>unexpected()</tt>:
</p>

<blockquote><p>
<i>Effects</i>: Calls the <tt>unexpected_handler</tt> function in effect immediately after evaluating the throw-expression 
(D.13.1), if called by the implementation, or calls the current <tt>unexpected_handler</tt>, if called by the program.
</p></blockquote>

<p>
and this about <tt>terminate()</tt>:
</p>

<blockquote><p>
<i>Effects</i>: Calls the <tt>terminate_handler</tt> function in effect immediately after evaluating the throw-expression (18.8.3.1), 
if called by the implementation, or calls the current <tt>terminate_handler</tt> function, if called by the program.
</p></blockquote>

<p>
But now in both places we say:
</p>

<blockquote><p>
Calls the current <tt>unexpected_handler</tt> function.
</p></blockquote>

<p>
and:
</p>

<blockquote><p>
Calls the current <tt>terminate</tt> function.
</p></blockquote>

<p>
The difference is that in C++98&#47;03 if a destructor reset a handler during stack unwinding, that new handler was 
not called if the unwinding later led to <tt>unexpected()</tt> or <tt>terminate()</tt> being called.  But these new 
words say that this new handler <em>is</em> called. This is an ABI-breaking change in the way exceptions are handled.  
Was this change intentional?
<p/>
N3189 was mainly about introducing exception safety and getters for the handlers. I don't recall the issue of 
<em>which</em> handler gets called being part of the discussion.
<p/>
I propose that we revert to the C++98&#47;03 behavior in this regard, lest ABI's such as the Itanium ABI are invalidated.  
A mechanical way to do this is to revert bullets 9 and 12 of N3189.
</p>

<p><i>[2011-12-09: Daniel comments]</i></p>


<p>
There was no such semantic change intended. It was an unfortunate side effect when trying to better separate different
responsibilities in the previous wording.
<p/>
A related issue is <a href="lwg-active.html#2088">2088</a>.
</p>

<p><i>[2012-01-30: Howard comments]</i></p>


<p>
The C++98&#47;03 wording is somewhat ambiguous:
</p>
<blockquote><p>
Calls the terminate_handler function in effect immediately after evaluating the throw-expression...
</p></blockquote>
<p>
There are potentially two throw-expressions being referred to here, and it is not clear if this sentence is referring to just the first or both:
</p>
<ol>
<li><tt>throw <i>assignment-expression</i>;</tt></li>
<li><tt>throw;</tt></li>
</ol>
<p>
There is ample evidence in current implementations that it is understood that <i>only</i> 
1. was meant. But clearly both 1 and 2 could have been meant. We need a clarification. Does an execution 
of a rethrow (throw;) update which handlers can potentially be called?
</p>
<ol>
<li value="2"><tt>throw;</tt> // update handlers to get_xxx()?</li>
</ol>
<p>
My opinion: Go with existing practice, and clarify what that practice is, if surveys find that everyone 
does the same thing. Gcc 4.2 and Apple do 1. only, and do not reset the handlers to the current handlers 
on throw;.
<p/>
If current practice is not unanimously one way or the other, I have no strong opinion. I have not found 
a motivating use case for the use of any particular handler. Most applications set the handlers once at 
the beginning of the program and then do not change them, and so will not be impacted by whatever decision 
is made here.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2112"></a>2112. User-defined classes that cannot be derived from</h3>
<p><b>Section:</b> 17.6.5 [conforming], 20.6.8 [allocator.traits], 20.12.1 [allocator.adaptor.syn] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-11-30 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#conforming">issues</a> in [conforming].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
It is a very established technique for implementations to derive internally from user-defined class types that are
used to customize some library component, e.g. deleters and allocators are typical candidates. The advantage of this
approach is to possibly take advantage of the empty-base-class optimization (EBCO).
<p/>
Whether or whether not libraries did take advantage of such a detail didn't much matter in C++03. Even though there
did exist a portable idiom to prevent that a class type could be derived from, this idiom has never reached great
popularity: The <a href="http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Final_Class">technique</a> required
to introduce a virtual base class and it did not really prevent the derivation, but only any construction of
such a type. Further, such types are not <em>empty</em> as defined by the <tt>std::is_empty</tt> trait, so
could easily be detected by implementations from TR1 on.
<p/>
With the new C++11 feature of final classes and final member functions it is now very easy to define an empty,
but not derivable from class type. From the point of the user it is quite natural to use this feature for
types that he or she did not foresee to be derivable from.
<p/>
On the other hand, most library implementations (including third-party libraries) often take advantage of EBCO 
applied to user-defined types used to instantiate library templates internally. As the time of submitting this 
issue the following program failed to compile on all tested library implementations:
</p>
<blockquote><pre>
#include &lt;memory&gt;

struct Noop <span style="color:#C80000;font-weight:bold">final</span> {
 template&lt;class Ptr&gt;
 void operator()(Ptr) const {}
};

std::unique_ptr&lt;int, Noop&gt; up;
</pre></blockquote>
<p>
In addition, many <tt>std::tuple</tt> implementations with empty, final classes as element types failed as well, 
due to a popular inheritance-based implementation technique. EBCO has also a long tradition to be 
used in library containers to efficiently store potentially stateless, empty allocators.
<p/>
It seems that both user and library did the best they could: None of the affected types did impose explicit
requirements on the corresponding user-defined types to be derivable from (This capability was not part of
the required operations), and libraries did apply EBCO whereever possible to the convenience of the customer.
<p/>
Nonetheless given the existence of non-derivable-from class types in C++11, libraries have to cope with
failing derivations. How should that problem be solved?
<p/>
It would certainly be possible to add weazel wording to the allocator requirements similar to what we had
in C++03, but restricted to derivation-from requirements. I consider this as the bad solution, because it
would add new requirements that never had existed before in this explicit form onto types like allocators.
<p/>
Existing libraries presumably will need internal traits like <tt>__is_final</tt> or <tt>__is_derivable</tt>
to make EBCO possible in the current form but excluding non-derivable class types. As of this writing this
seems to happen already. Problem is that without a <tt>std::is_derivable</tt> trait, third-party libraries
have no portable means to do the same thing as standard library implementations. This should be a good 
reason to make such a trait public available soon, but seems not essential to have now. Further, this issue
should also be considered as a chance to recognice that EBCO has always been a very special corner case
(There exist parallels to the previously existing odd core language rule that did make the interplay 
between <tt>std::auto_ptr</tt> and <tt>std::auto_ptr_ref</tt> possible) and that it would be better to
provide explicit means for space-efficient storage, not necessarily restricted to inheritance relations, 
e.g. by marking data members with a special attribute.
<p/>
At least two descriptions in the current standard should be fixed now for better clarification:
</p>
<ol>
<li><p>As mentioned by Ganesh, 20.6.8 [allocator.traits] p1 currently contains a (non-normative) note
"Thus, it is always possible to create a derived class from an allocator." which should be removed.
</p>
</li>
<li><p>As pointed out by Howard, the specification of <tt>scoped_allocator_adaptor</tt> as of
20.12.1 [allocator.adaptor.syn] already requires derivation from <tt>OuterAlloc</tt>, but 
only implies indirectly the same for the inner allocators due to the <em>exposition-only</em> 
description of member <tt>inner</tt>. This indirect implication should be normatively required for 
all participating allocators.
</p></li>
</ol>


<p><i>[2012, Kona]</i></p>

<p>
What we really need is a type trait to indicate if a type can be derived from.  Howard reports
Clang and libc++ have had success with this approach.
</p>
<p>
Howard to provide wording, and AJM to alert Core that we may be wanting to add a new trait
that requires compiler support.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2114"></a>2114. Incorrect "<em>contextually</em> convertible to <tt>bool</tt>" requirements</h3>
<p><b>Section:</b> 17.6.3.3 [nullablepointer.requirements], 24.2.3 [input.iterators], 24.2.7 [random.access.iterators], 25.1 [algorithms.general], 25.4 [alg.sorting], 30.2.1 [thread.req.paramname] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-12-09 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
As of 17.6.3.1 [utility.arg.requirements] Table 17&#47;18, the return types of the expressions
</p>
<blockquote><pre>
a == b
</pre></blockquote>
<p>
or
</p>
<blockquote><pre>
a &lt; b
</pre></blockquote>
<p>
for types satisfying the <tt>EqualityComparable</tt> or <tt>LessThanComparable</tt>
types, respectively, are required to be "convertible to <tt>bool</tt>" which corresponds to
a copy-initialization context. But several newer parts of the library that refer to 
such contexts have lowered the requirements taking  advantage of the new terminology of 
"<em>contextually</em> convertible to <tt>bool</tt>" instead, which corresponds to a 
direct-initialization context (In addition to "normal" direct-initialization constructions, 
operands of logical operations as well as <tt>if</tt> or <tt>switch</tt> conditions also 
belong to this special context).
<p/>
One example for these new requirements are input iterators which satisfy <tt>EqualityComparable</tt> 
but also specify that the expression
</p>
<blockquote><pre>
a != b
</pre></blockquote>
<p>
shall be just "<strong>contextually</strong> convertible to <tt>bool</tt>". The same discrepancy 
exists for requirement set <tt>NullablePointer</tt> in regard to several equality-related expressions.
<p/>
For random access iterators we have
</p>
<blockquote><p>
<tt>a &lt; b</tt>      contextually convertible to <tt>bool</tt>
</p></blockquote>
<p>
as well as for all derived comparison functions, so strictly speaking we could have a random access 
iterator that does not satisfy the <tt>LessThanComparable</tt> requirements, which looks like an
artifact to me.
<p/>
Even if we keep with the existing requirements based on <tt>LessThanComparable</tt> or
<tt>EqualityComparable</tt> we still would have the problem that some current specifications 
are actually  based on the assumption of implicit convertibility instead of "explicit convertibility", e.g. 
20.7.1.4 [unique.ptr.special] p3:
</p>
<blockquote><pre>
template &lt;class T1, class D1, class T2, class D2&gt;
bool operator!=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
</pre>
<blockquote>
<p>
-3- <i>Returns</i>: <tt>x.get() != y.get()</tt>.
</p>
</blockquote></blockquote>
<p>
Similar examples exist in 20.7.1.2.2 [unique.ptr.single.dtor] p2, 20.7.1.2.3 [unique.ptr.single.asgn] p9,
20.7.1.2.4 [unique.ptr.single.observers] p1+3+8, etc.
<p/>
In all these places the expressions involving comparison functions (but <em>not</em> those of the conversion 
of a <tt>NullablePointer</tt> to <tt>bool</tt>!) assume to be "convertible to <tt>bool</tt>". I think this
is a very natural assumption and all delegations of the comparison functions of some type <tt>X</tt> to some
other API type <tt>Y</tt> in third-party code does so assuming that copy-initialization semantics will
just work.
<p/>
The actual reason for using the newer terminology can be rooted back to LWG <a href="lwg-defects.html#556">556</a>. My hypotheses 
is that the resolution of that issue also needs a slight correction. Why so?
<p/>
The reason for opening that issue were worries based on the previous "convertible to <tt>bool</tt>"
wording. An expressions like "<tt>!pred(a, b)</tt>" might not be well-formed in those situations, because
<tt>operator!</tt> might not be accessible or might have an unusual semantics (and similarly for other logical
operations). This can indeed happen with unusual proxy return types, so the idea was that the evaluation of 
<tt>Predicate</tt>, <tt>BinaryPredicate</tt> (25.1 [algorithms.general] p8+9), and <tt>Compare</tt> 
(25.4 [alg.sorting] p2) should be defined based on contextual conversion to <tt>bool</tt>. 
Unfortunately this <em>alone</em> is not sufficient: In addition, I think, we <em>also</em> want the predicates 
to be (implicitly) convertible to <tt>bool</tt>! Without this wording, several conditions are plain wrong, 
e.g. 25.2.5 [alg.find] p2, which talks about "<tt>pred(*i) != false</tt>" (<tt>find_if</tt>) and 
"<tt>pred(*i) == false</tt>" (<tt>find_if_not</tt>). These expressions are not within a boolean context! 
<p/>
While we could simply fix all these places by proper wording to be considered in a "contextual conversion to
<tt>bool</tt>", I think that this is not the correct solution: Many third-party libraries already refer to
the previous C++03 <tt>Predicate</tt> definition &mdash; it actually predates C++98 and is as old as the 
<a href="http://www.sgi.com/tech/stl/Predicate.html">SGI specification</a>. It seems to be a high price to
pay to switch to direct initialization here instead of fixing a completely different specification problem.
<p/>
A final observation is that we have another definition for a <tt>Predicate</tt> in 30.2.1 [thread.req.paramname] p2:
</p>
<blockquote><p>
If a parameter is <tt>Predicate</tt>, <tt>operator()</tt> applied to the actual template argument shall return a value that
is convertible to <tt>bool</tt>.
</p></blockquote>
<p>
The problem here is not that we have two different definitions of <tt>Predicate</tt> in the standard &mdash; this 
is confusing, but this fact alone is not a defect. The first (minor) problem is that this definition does not properly 
apply to function objects that are function pointers, because <tt>operator()</tt> is not defined in a strict sense. 
But the actually worse second problem is that this wording has the very <tt>same</tt> problem that has originally lead to
LWG <a href="lwg-defects.html#556">556</a>! We only need to look at 30.5.1 [thread.condition.condvar] p15 to recognice this:
</p>
<blockquote><pre>
while (!pred())
  wait(lock);
</pre></blockquote>
<p>
The negation expression here looks very familiar to the example provided in LWG <a href="lwg-defects.html#556">556</a> and is sensitive
to the same "unusual proxy" problem. Changing the 30.2.1 [thread.req.paramname] wording to a corresponding
"contextual conversion to <tt>bool</tt>" wouldn't work either, because existing specifications rely on "convertible
to <tt>bool</tt>", e.g. 30.5.1 [thread.condition.condvar] p32+33+42 or 30.5.2 [thread.condition.condvarany] 
p25+26+32+33.
<p/>
To summarize: I believe that LWG <a href="lwg-defects.html#556">556</a> was not completely resolved. A pessimistic interpretation is,
that even with the current wording based on "contextually convertible to <tt>bool</tt>" the actual problem of that 
issue has <em>not</em> been fixed. What actually needs to be required here is some normative wording that basically
expresses something along the lines of:
</p>
<blockquote><p>
The semantics of <em>any</em> contextual conversion to <tt>bool</tt> shall be equivalent to the semantics of 
any implicit conversion to <tt>bool</tt>.
</p></blockquote>
<p>
This is still not complete without having concepts, but it seems to be a better approximation. Another way of solving
this issue would be to define a minimum requirements table with equivalent semantics. The proposed wording is a bit
simpler but attempts to express the same thing.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Agree with Daniel that we potentially broke some C++03 user code, accept the changes striking
"contextually" from tables.  Stefan to provide revised wording for section 25, and figure out
changes to section 30.
</p>
<p>
Move to open, and then to Review when updated wording from Stefan is available.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Change Table 25 &mdash; "<tt>NullablePointer</tt> requirements" in 17.6.3.3 [nullablepointer.requirements]
as indicated:</p>

<table border="1">
<caption>Table 25 &mdash; <tt>NullablePointer</tt> requirements</caption>
<tr align="center">
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
</tr> 

<tr>
<td colspan="3" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>a != b</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>!(a == b)</tt>
</td>
</tr>

<tr>
<td>
<tt>a == np<br/>
np == a</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>a == P()</tt>
</td>
</tr>

<tr>
<td>
<tt>a != np<br/>
np != a</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>!(a == np)</tt>
</td>
</tr>

</table>
 
</li>

<li><p>Change Table 107 &mdash; "Input iterator requirements" in 24.2.3 [input.iterators]
as indicated:</p>

<table border="1">
<caption>Table 107 &mdash; Input iterator requirements (in addition to Iterator)</caption>
<tr align="center">
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr> 

<tr>
<td>
<tt>a != b</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>!(a == b)</tt>
</td>
<td>
pre: <tt>(a, b)</tt> is in the domain of <tt>==</tt>.
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

</table>
 
</li>

<li><p>Change Table 111 &mdash; "Random access iterator requirements" in 24.2.7 [random.access.iterators]
as indicated:</p>

<table border="1">
<caption>Table 111 &mdash; Random access iterator requirements (in addition to bidirectional iterator)</caption>
<tr align="center">
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr> 

<tr>
<td colspan="4" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>a &lt; b</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>b - a &gt; 0</tt>
</td>
<td>
<tt>&lt;</tt> is a total ordering relation
</td>
</tr>

<tr>
<td>
<tt>a &gt; b</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>b &lt; a</tt>
</td>
<td>
<tt>&gt;</tt> is a total ordering relation opposite to <tt>&lt;</tt>.
</td>
</tr>

<tr>
<td>
<tt>a &gt;= b</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>!(a &lt; b)</tt>
</td>
<td>
</td>
</tr>

<tr>
<td>
<tt>a &lt;= b</tt>
</td>
<td>
<del>contextually</del> convertible to <tt>bool</tt>
</td>
<td>
<tt>!(a &gt; b)</tt>
</td>
<td>
</td>
</tr>

</table>
 
</li>

<li><p>Change 25.1 [algorithms.general] p8+9 as indicated:</p>

<blockquote>
<p>
-8- The <tt>Predicate</tt> parameter is used whenever an algorithm expects a function object 
(20.8 [function.objects]) that, when applied to the result of dereferencing the corresponding iterator, 
returns a value testable as <tt>true</tt>. In other words, if an algorithm takes <tt>Predicate pred</tt> 
as its argument and first as its iterator argument, it should work correctly in the construct 
<tt>pred(*first)</tt> <ins>implicitly or</ins> contextually converted to <tt>bool</tt> (Clause 4 [conv]). 
The function object <tt>pred</tt> shall not apply any non-constant function through the dereferenced iterator.
<p/>
-9- The <tt>BinaryPredicate</tt> parameter is used whenever an algorithm expects a function object that when applied
to the result of dereferencing two corresponding iterators or to dereferencing an iterator and type
<tt>T</tt> when <tt>T</tt> is part of the signature returns a value testable as <tt>true</tt>. In other words, if an algorithm takes
<tt>BinaryPredicate binary_pred</tt> as its argument and <tt>first1</tt> and <tt>first2</tt> as its iterator arguments, it should
work correctly in the construct <tt>binary_pred(*first1, *first2)</tt> <ins>implicitly or</ins> contextually converted to 
<tt>bool</tt> (Clause 4 [conv]).
<tt>BinaryPredicate</tt> always takes the first iterator's <tt>value_type</tt> as its first argument, that is, in those cases
when <tt>T</tt> value is part of the signature, it should work correctly in the construct <tt>binary_pred(*first1, value)</tt> 
<ins>implicitly or</ins> contextually converted to <tt>bool</tt> (Clause 4 [conv]). <tt>binary_pred</tt> shall 
not apply any non-constant function through the dereferenced iterators.
</p>
</blockquote>
</li>

<li><p>Change 25.4 [alg.sorting] p2 as indicated:</p>

<blockquote>
<p>
-2- <tt>Compare</tt> is a function object type (20.8 [function.objects]). The return value of the function 
call operation applied to an object of type <tt>Compare</tt>, when <ins>implicitly or</ins> contextually converted 
to <tt>bool</tt> (4 [conv]), yields <tt>true</tt> if the first argument of the call is less than the second, and 
<tt>false</tt> otherwise. <tt>Compare comp</tt> is used throughout for algorithms assuming an ordering relation. It is assumed 
that <tt>comp</tt> will not apply any non-constant function through the dereferenced iterator.
</p>
</blockquote>
</li>

<li><p>Change 30.2.1 [thread.req.paramname] p2 as indicated:</p>

<blockquote>
<p>
-2- <del>If a parameter is <tt>Predicate</tt>, operator() applied to the actual template argument shall return a value that
is convertible to <tt>bool</tt></del><ins><tt>Predicate</tt> is a function object type (20.8 [function.objects]).
The return value of the function call operation applied to an object of type <tt>Predicate</tt>, when implicitly or 
contextually converted to <tt>bool</tt> (4 [conv]), yields <tt>true</tt> if the corresponding test condition is
satisfied, and <tt>false</tt> otherwise</ins>.
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2115"></a>2115. Undefined behaviour for <tt>valarray</tt> assignments with <tt>mask_array</tt> index?</h3>
<p><b>Section:</b> 26.6.8 [template.mask.array] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2011-12-10 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Recently I received a Service Request (SR) alleging that one of our testcases causes an 
undefined behavior. The complaint is that 26.6.8 [template.mask.array] in C++11 
(and the corresponding subclause in C++03) are interpreted by some people to require that 
in an assignment "<tt>a[mask] = b</tt>", the subscript <tt>mask</tt> and the rhs <tt>b</tt> 
must have the same number of elements.
<p/>
IMHO, if that is the intended requirement, it should be stated explicitly.
<p/>
In any event, there is a tiny editorial cleanup that could be made:
<p/>
In C++11, 26.6.8.1 [template.mask.array.overview] para 2 mentions
</p>
<blockquote><p>
"the expression <tt>a[mask] = b;</tt>"
</p></blockquote>
<p>
but the semicolon cannot be part of an expression. The correction could omit the 
semicolon, or change the word "expression" to "assignment" or "statement".
<p/>
Here is the text of the SR, slightly modified for publication:
</p>
<blockquote>
<p>
Subject:  SR01174 LVS _26322Y31 has undefined behavior [open]
<p/>
[Client:]<br/>
The test case t263.dir&#47;_26322Y31.cpp seems to be illegal as it has an undefined 
behaviour. I searched into the SRs but found SRs were not related to the topic 
explained in this mail (SR00324, SR00595, SR00838).
</p>
<blockquote><pre>
const char vl[] = {"abcdefghijklmnopqrstuvwxyz"};
const char vu[] = {"ABCDEFGHIJKLMNOPQRSTUVWXYZ"};
const std::valarray&lt;char&gt; v0(vl, 27), vm5(vu, 5), vm6(vu, 6);
std::valarray&lt;char&gt; x = v0;
[&hellip;]
const bool vb[] = {false, false, true, true, false, true};
const std::valarray&lt;bool&gt; vmask(vb, 6);
x = v0;
x[vmask] = vm5;      // ***** HERE....
steq(&amp;x[0], "abABeCghijklmnopqrstuvwxyz");
x2 = x[vmask];       // ***** ....AND HERE
[&hellip;]
</pre></blockquote>
<p>
This problem has already been discussed between [experts]:
See thread <a href="http://gcc.gnu.org/ml/libstdc++/2009-11/threads.html#00051">http:&#47;&#47;gcc.gnu.org&#47;ml&#47;libstdc++&#47;2009-11&#47;threads.html#00051</a> 
Conclusion <a href="http://gcc.gnu.org/ml/libstdc++/2009-11/msg00099.html">http:&#47;&#47;gcc.gnu.org&#47;ml&#47;libstdc++&#47;2009-11&#47;msg00099.html</a>
<p/>
[Plum Hall:]<br/>
Before I log this as an SR, I need to check one detail with you.
<p/>
I did read the email thread you mentioned, and I did find a citation (see INCITS ISO&#47;IEC 14882-2003 
Section 26.3.2.6 on valarray computed assignments):
<p/>
Quote: "If the array and the argument array do not have the same length, the behavior is undefined",
<p/>
But this applies to computed assignment (<tt>*=</tt>, <tt>+=</tt>, etc), not to simple assignment. Here is the C++03 citation 
re simple assignment:
<p/>
26.3.2.2 valarray assignment [lib.valarray.assign]
</p>
<blockquote><pre>
valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;);
</pre><blockquote>
<p>
1 Each element of the <tt>*this</tt> array is assigned the value of the corresponding element of the argument array.
The resulting behavior is undefined if the length of the argument array is not equal to the length of the
<tt>*this</tt> array.
</p>
</blockquote></blockquote>
<p>
In the new C++11 (N3291), we find ...
<p/>
26.6.2.3 valarray assignment [valarray.assign]
</p>
<blockquote><pre>
valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp; v);
</pre><blockquote>
<p>
1 Each element of the <tt>*this</tt> array is assigned the value of the corresponding element of the argument
array. If the length of <tt>v</tt> is not equal to the length of <tt>*this</tt>, resizes <tt>*this</tt> to make 
the two arrays the same length, as if by calling <tt>resize(v.size())</tt>, before performing the assignment.
</p>
</blockquote></blockquote>
<p>
So it looks like the testcase might be valid for C++11 but not for C++03; what do you think?
<p/>
[Client:]<br/>
I quite agree with you but the two problems I mentioned:
</p>
<blockquote><pre>
x[vmask] = vm5;      // ***** HERE....
[&hellip;]
x2 = x[vmask];       // ***** ....AND HERE
</pre></blockquote>
<p>
refer to <tt>mask_array</tt> assignment hence target the C++03 26.3.8 paragraph. Correct?
<p/>
[Plum Hall:]<br/>
I mentioned the contrast between C++03 26.3.2.2 para 1 versus C++11 26.6.2.3 para 1.
<p/>
But in C++03 26.3.8, I don't find any corresponding restriction. Could you quote the specific 
requirement you're writing about?
<p/>
[Client:]<br/>
I do notice the difference between c++03 26.3.2.2 and c++11 26.6.2.3 about assignments between 
different sized <tt>valarray</tt> and I perfectly agree with you.
<p/>
But, as already stated, this is not a simple <tt>valarray</tt> assignment but a
<tt>mask_array</tt> assignment (c++03 26.3.8 &#47; c++11 26.6.8). See c++11 quote below:
<p/>
26.6.8 Class template mask_array<br/>
26.6.8.1 Class template mask_array overview<br/>
[....]
</p>
<ol>
<li><p>This template is a helper template used by the mask subscript operator:
<tt>mask_array&lt;T&gt; valarray&lt;T&gt;::operator[](const valarray&lt;bool&gt;&amp;)</tt>.
</p></li>
<li><p>It has reference semantics to a subset of an array specified by a boolean mask. Thus, 
the expression <tt>a[mask] = b;</tt> has the effect of assigning <em>the elements of <tt>b</tt></em> 
to the masked elements in <tt>a</tt> (those for which the corresponding element in <tt>mask</tt> is true.)
</p></li>
</ol>
<p>
26.6.8.2 mask_array assignment
</p>
<blockquote><pre>
void operator=(const valarray&lt;T&gt;&amp;) const;
const mask_array&amp; operator=(const mask_array&amp;) const;
</pre><blockquote>
<p>
1 These assignment operators have reference semantics, assigning the values of the argument array 
elements to selected elements of the <tt>valarray&lt;T&gt;</tt> object to which it refers.
</p>
</blockquote></blockquote>
<p>
In particular, [one of the WG21 experts] insisted on the piece "the elements of <tt>b</tt>".
<p/>
That is why I reported the test t263.dir&#47;_26322Y31.cpp having an undefined behaviour.
<p/>
[Plum Hall:]<br/>
OK, I can see that I will have to ask WG21; I will file an appropriate issue 
with the Library subgroup. In the meantime, I will mark this testcase as "DISPUTED" 
so that it is not required for conformance testing, until we get a definitive opinion.
</p>
</blockquote>

<p><i>[2012, Kona]</i></p>

<p>
Moved to Open.
</p>
<p>
There appears to be a real need for clarification in the standard, and
implementations differ in their current interpretation.  This will need
some research by implementers and a proposed resolution before further
discussion is likely to be fruitful.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2116"></a>2116. <tt>std::swap noexcept(what?)</tt></h3>
<p><b>Section:</b> 20.9.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2011-12-09 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
IMO if we specified <tt>is_[nothrow_]constructible</tt> in terms of a variable
declaration whose validity requires destructibility, it is clearly a bug
in our specification and a failure to realize the actual original
intent. The specification should have been in terms of placement-new.
<p/>
Daniel:<br/>
At the time of the specification this was intended and the solution is
<em>not</em> done by removing the destruction semantics of <tt>is_constructible</tt>.
<p/>
The design of <tt>is_constructible</tt> was also impacted by the previous
<tt>Constructible</tt> concept that <em>explicitly</em> contained destruction semantics,
because during conceptification of the library it turned out to simplify
the constraints  in the library because you did not need to add
<tt>Destructible</tt> all the time. It often was implied but never spoken out
in C++03.
<p/>
Pure construction semantics was considered as useful as well, so <tt>HasConstructor</tt> 
did also exist and would surely be useful as trait as well.
<p/>
Another example that is often overlooked: This also affects wrapper types like <tt>pair</tt>, 
<tt>tuple</tt>, <tt>array</tt> that contain potentially more than one type:
This is easy to understand if you think of <tt>T1</tt> having a deleted destructor
and <tt>T2</tt> having a constructor that may throw: Obviously the compiler has
potentially need to use the <tt>destructor</tt> of <tt>T1</tt> in the <em>constructor</em>
of <tt>std::pair&lt;T1, T2&gt;</tt> to ensure that the core language requirements
are satisfied (All previous fully constructed sub-objects must be destructed).
<p/>
The core language also honors this fact in 12.8 [class.copy] p11:
</p>
<blockquote><p>
A defaulted copy&#47;move constructor for a class <tt>X</tt> is defined as deleted (8.4.3 [dcl.fct.def.delete]) 
if <tt>X</tt> has:<br/>
[&hellip;]<br/>
&mdash; any direct or virtual base class or non-static data member of a type with a destructor that is deleted
or inaccessible from the defaulted constructor,<br/>
[&hellip;]
</p></blockquote>
<p>
Dave:<br/>
This is about <tt>is_nothrow_constructible</tt> in particular. The fact that it is 
foiled by not having a <tt>noexcept</tt> dtor is a defect.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Move to Open.
</p>
<p>
<tt>is_nothrow_constructible</tt> is defined in terms of <tt>is_constructible</tt>, which is defined
by looking at a hypothetical variable and asking whether the variable definition is known not to
throw exceptions. The issue claims that this also examines the type's destructor, given the context,
and thus will return <tt>false</tt> if the destructor can potentially throw. At least one
implementation (Howard's) does return <tt>false</tt> if the constructor is <tt>noexcept(true)</tt>
and the destructor is <tt>noexcept(false)</tt>. So that's not a strained interpretation.
The issue is asking for this to be defined in terms of placement <tt>new</tt>, instead of in terms
of a temporary object, to make it clearer that <tt>is_nothrow_constructible</tt> looks at the
<tt>noexcept</tt> status of only the constructor, and not the destructor.
</p>
<p>
Sketch of what the wording would look like:
</p>
<p>
require <tt>is_constructible</tt>, and then also require that a placement <tt>new</tt> operation
does not throw. (Remembering the title of this issue... What does this imply for <tt>swap</tt>?
</p>
<p>
If we accept this resolution, do we need any changes to <tt>swap</tt>?
</p>
<p> STL argues: no, because you are already forbidden from passing anything with a throwing
desturctor to <tt>swap</tt>.
</p>
<p>
Dietmar argues: no, not true. Maybe statically the destructor can conceivably throw for some
values, but maybe there are some values known not to throw. In that case, it's correct to
pass those values to <tt>swap</tt>.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2117"></a>2117. <tt>ios_base</tt> manipulators should have <tt>showgrouping&#47;noshowgrouping</tt></h3>
<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals], 27.5.3.1.2 [ios::fmtflags], 27.5.6.1 [fmtflags.manip] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Benjamin Kosnik <b>Opened:</b> 2011-12-15 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Iostreams should include a manipulator to toggle grouping on&#47;off for
locales that support grouped digits. This has come up repeatedly and
been deferred. See LWG <a href="lwg-closed.html#826">826</a> for the previous attempt.
<p/>
If one is using a locale that supports grouped digits, then output
will always include the generated grouping characters. However, very
plausible scenarios exist where one might want to output the number,
un-grouped. This is similar to existing manipulators that toggle
on&#47;off the decimal point, numeric base, or positive sign.
<p/>
See some user commentary <a href="http://www.tablix.org/~avian/blog/archives/2008/01/c_streams_suck/">here</a>.
</p>


<p><i>[21012, Kona]</i></p>

<p>
Move to Open.
</p>
<p>
This is a feature request.
</p>
<p>
Walter is slightly uncomfortable with processing feature requests through the issues lists.
</p>
<p>
Alisdair says this is far from the first feature request that has come in from the issues list.
</p>
<p>
STL: The fact that you can turn off grouping on hex output is compelling.
</p>
<p>
Marshall: if we add this flag, we'll need to update tables 87-91 as well.
</p>
<p>
STL: If it has been implemented somewhere, and it works, we'd be glad to add it.
</p>
<p>
Howard: We need to say what the default is.
</p>
<p>
Alisdair sumarizes:
</p>
<p>
(1) We want clear wording that says what the effect is of turning the flag off;
</p>
<p>
(2) what the default values are, and
</p>
<p>
(3) how this fits into tables 87-90. (and 128)
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li>
<p>Insert in 22.4.2.2.2 [facet.num.put.virtuals] paragraph 5:</p>

<blockquote><p>
<strong>Stage 1</strong>: The first action of stage 1 is to determine a conversion specifier. The tables that describe
this determination use the following local variables
</p>
<pre>
fmtflags flags = str.flags() ;
fmtflags basefield = (flags &amp; (ios_base::basefield));
fmtflags uppercase = (flags &amp; (ios_base::uppercase));
fmtflags floatfield = (flags &amp; (ios_base::floatfield));
fmtflags showpos = (flags &amp; (ios_base::showpos));
fmtflags showbase = (flags &amp; (ios_base::showbase));
<ins>fmtflags showgrouping = (flags &amp; (ios_base::showgrouping));</ins>
</pre>
</blockquote>
</li>

<li><p>Change header <tt>&lt;ios&gt;</tt> synopsis, 27.5.1 [iostreams.base.overview] as indicated:</p>

<blockquote><pre>
#include &lt;iosfwd&gt;

namespace std {
  [&hellip;]
  <i>// 27.5.6, manipulators:</i>
  [&hellip;]
  ios_base&amp; showpoint     (ios_base&amp; str);
  ios_base&amp; noshowpoint   (ios_base&amp; str);
  <ins>ios_base&amp; showgrouping  (ios_base&amp; str);</ins>
  <ins>ios_base&amp; noshowgrouping(ios_base&amp; str);</ins>
  ios_base&amp; showpos       (ios_base&amp; str);
  ios_base&amp; noshowpos     (ios_base&amp; str);
  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Change class <tt>ios_base</tt> synopsis, 27.5.3 [ios.base] as indicated:</p>

<blockquote><pre>
namespace std {
  class ios_base {
  public:
  class failure;
    <i>// 27.5.3.1.2 fmtflags</i>
    typedef <i>T1</i> fmtflags;
    [&hellip;]
    static constexpr fmtflags showpoint = <i>unspecified</i> ;
    <ins>static constexpr fmtflags showgrouping = <i>unspecified</i> ;</ins>
    static constexpr fmtflags showpos = <i>unspecified</i> ;
    [&hellip;]
  };
}
</pre></blockquote>
</li>

<li><p>Add a new entry to Table 122 &mdash; "<tt>fmtflags</tt> effects" as indicated:</p>

<table border="1">
<caption>Table 122 &mdash; <tt>fmtflags</tt> effects</caption>
<tr align="center">
<th>Element</th>
<th>Effect(s) if set</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>showpoint</tt>
</td>
<td>
generates a decimal-point character unconditionally in generated floatingpoint output
</td>
</tr>

<tr>
<td>
<ins><tt>showgrouping</tt></ins>
</td>
<td>
<ins>generates grouping characters unconditionally in generated output</ins>
</td>
</tr>

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

</table>
 
</li>

<li><p>After 27.5.3.1.2 [ios::fmtflags] p12 insert the following:</p>
<blockquote><pre>
<ins>ios_base&amp; showgrouping(ios_base&amp; str);</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Effects</i>: Calls <tt>str.setf(ios_base::showgrouping)</tt>.</ins>
<p/>
<ins>-?- <i>Returns</i>: <tt>str</tt>.</ins>
</p>
</blockquote>
<pre>
<ins>ios_base&amp; noshowgrouping(ios_base&amp; str);</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Effects</i>: Calls <tt>str.unsetf(ios_base::showgrouping)</tt>.</ins>
<p/>
<ins>-?- <i>Returns</i>: <tt>str</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2118"></a>2118. <tt>unique_ptr</tt> for array does not support <i>cv</i> qualification conversion of actual argument</h3>
<p><b>Section:</b> 20.7.1.3 [unique.ptr.runtime] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Alf P. Steinbach <b>Opened:</b> 2011-12-16 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#unique.ptr.runtime">issues</a> in [unique.ptr.runtime].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
N3290 20.7.1.3.1 [unique.ptr.runtime.ctor] "<tt>unique_ptr</tt> constructors":
</p>
<blockquote><p>
These constructors behave the same as in the primary template except that they do not accept pointer types 
which are convertible to <tt>pointer</tt>. [<i>Note:</i> One implementation technique is to create private 
templated overloads of these members. &mdash; <i>end note</i>]
</p></blockquote>
<p>
This language excludes even <tt>pointer</tt> itself as type for the actual argument.
<p/>
But of more practical concern is that both Visual C++ 10.0 and MinGW g++ 4.1.1 reject the code below, where 
only an implicit <i>cv</i> qualification is needed, which <i>cv</i> qualification is supported by the non-array 
version:
</p>
<blockquote><pre>
#include &lt;memory&gt;
using namespace std;

struct T {};

T* foo() { return new T; }
T const* bar() { return foo(); }

int main()
{
   unique_ptr&lt; T const &gt;       p1( bar() );        // OK
   unique_ptr&lt; T const [] &gt;    a1( bar() );        // OK

   unique_ptr&lt; T const &gt;       p2( foo() );        // OK
   unique_ptr&lt; T const [] &gt;    a2( foo() );        // <span style="color:#C80000;font-weight:bold">? this is line #15</span>
}
</pre></blockquote>
<p>
The <em>intent</em> seems to be clearly specified in 20.7.1.3 [unique.ptr.runtime]&#47;1 second bullet:
</p>
<blockquote><p>
&mdash; Pointers to types derived from <tt>T</tt> are rejected by the constructors, and by <tt>reset</tt>.
</p></blockquote>

<p>
But the following language in 20.7.1.3.1 [unique.ptr.runtime.ctor] then rejects far too much...
<p/>
Proposed new wording of N3290 20.7.1.3.1 [unique.ptr.runtime.ctor] "<tt>unique_ptr</tt> constructors":
</p>
<blockquote><p>
These constructors behave the same as in the primary template except that actual argument pointers <tt>p</tt> 
to types derived from <tt>T</tt> are rejected by the constructors. [<i>Note:</i> One implementation technique 
is to create private templated overloads of these members. &mdash; <i>end note</i>]
</p></blockquote>
<p>
This will possibly capture the intent better, and avoid the inconsistency between the non-array and array 
versions of <tt>unique_ptr</tt>, by using nearly the exact same phrasing as for the paragraph explaining 
the intent.
</p>

<p><i>[2012-08-25 Geoffrey Romer comments in <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=32978">c++std-lib-32978</a>]</i></p>


<ol>
<li><p>
The current P/R seems to intend to support at least two different implementation techniques &mdash; additional 
unusable templates that catch forbidden arguments or replacing existing constructors by templates that 
ensure ill-formed code inside the template body, when the requirements are not met. It seems unclear whether
the current wording allows the second approach, though. It should be considered to allow both strategies or
if that is not possible the note should be clearer.
</p></li>

<li><p>
The very same problem exists for the <tt>reset</tt> member function, but even worse, because the current
specification is more than clear that the deleted <tt>reset</tt> function will catch all cases not equal to 
<tt>pointer</tt>. It seems confusing at best to have different policies for the constructor and for the <tt>reset</tt> 
function. In this case, the question in regard to implementation freedom mentioned above is even more important.
</p></li>

<li><p>
It's awkward to refer to "the constructors" twice in the same sentence; I suggest revising the sentence as 
"...except that they do not accept argument pointers <tt>p</tt> to types derived from <tt>T</tt>"
</p></li>
</ol>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>Change 20.7.1.3.1 [unique.ptr.runtime.ctor] as indicated:</p>

<blockquote><pre>
explicit unique_ptr(pointer p) noexcept;
unique_ptr(pointer p, <i>see below</i> d) noexcept;
unique_ptr(pointer p, <i>see below</i> d) noexcept;
</pre>
<blockquote><p>
These constructors behave the same as in the primary template except that <del>they do not accept pointer
types which are convertible to <tt>pointer</tt></del><ins>argument pointers <tt>p</tt> to types derived 
from <tt>T</tt> are rejected by the constructors</ins>. [<i>Note:</i> One implementation technique is to 
create private templated overloads of these members. &mdash; <i>end note</i>]
</p></blockquote></blockquote>





<hr>
<h3><a name="2119"></a>2119. Missing <tt>hash</tt> specializations for extended integer types</h3>
<p><b>Section:</b> 20.8.12 [unord.hash] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-12-16 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to the header <tt>&lt;functional&gt;</tt> synopsis 20.8 [function.objects] 
and to the explicit description in 20.8.12 [unord.hash] class template 
<tt>hash</tt> specializations shall be provided for all arithmetic types that are 
not extended integer types. This is not explicitly mentioned, but neither the list 
nor any normative wording does include them, so it follows by implication.
<p/>
What are the reasons that extended integer types are excluded? E.g. for 
<tt>numeric_limits</tt> corresponding specializations are required. I would 
expect that an <tt>unordered_map</tt> with key type <tt>std::uintmax_t</tt> would 
just work, but that depends now on whether this type is an extended integer type 
or not.
<p/>
This issue is <em>not</em> asking for also providing specializations for the
<i>cv</i>-qualified arithmetic types. While this is surely a nice-to-have feature,
I consider that restriction as a more secondary problem in practice.
<p/>
The proposed resolution also fixes a problem mentioned in <a href="lwg-active.html#2109">2109</a> in regard
to confusing requirements on user-defined types and those on implementations.
</p>


<p><i>[2012, Kona]</i></p>

<p>
Move to Open.
</p>
<p>
Agreed that it's a real issue and that the proposed wording fixes it. However, the wording
change is not minimal and isn't consistent with the way we fixed hash wording elsewhere.
</p>
<p>Alisdair will provide updated wording.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<p>Change 20.8.12 [unord.hash] p2 as indicated:</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;bool&gt;;
template &lt;&gt; struct hash&lt;char&gt;;
[&hellip;]
template &lt;&gt; struct hash&lt;long double&gt;;
template &lt;class T&gt; struct hash&lt;T*&gt;;
</pre><blockquote>
<p>
-2- <del><i>Requires</i>: the template specializations shall meet the requirements 
of class template <tt>hash</tt> (20.8.12 [unord.hash])</del><ins>The header 
<tt>&lt;functional&gt;</tt> provides definitions for specializations of the 
<tt>hash</tt> class template for each <i>cv</i>-unqualified arithmetic type. This 
header also provides a definition for a partial specialization of the <tt>hash</tt> 
class template for any pointer type. The requirements for the members of these 
specializations are given in sub-clause 20.8.12 [unord.hash]</ins>.
</p>
</blockquote></blockquote>






<hr>
<h3><a name="2120"></a>2120. What should <tt>async</tt> do if neither '<tt>async</tt>' nor '<tt>deferred</tt>' is set in policy?</h3>
<p><b>Section:</b> 30.6.8 [futures.async] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-01-01 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.async">active issues</a> in [futures.async].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.async">issues</a> in [futures.async].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Implementations already disagree, one returns an invalid future with
no shared state, one chooses <tt>policy == async</tt> and one chooses <tt>policy ==
deferred</tt>, see c++std-lib-30839, c++std-lib-30840 and c++std-lib-30844.
It's not clear if returning an invalid future is allowed by the current wording.
<p/>
If the intention is to allow an empty future to be returned, then
30.6.8 [futures.async] p3 and p4 should be adjusted to clarify that a
shared state might not be created and an invalid future might be returned.
<p/>
If the intention is that a valid future is always returned, p3 should
say something about the case where none of the conditions applies.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2121"></a>2121. <tt>app</tt> for string streams</h3>
<p><b>Section:</b> 27.8.6 [stringstream.cons] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2012-01-15 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
This issue was raised while discussing issue <a href="lwg-defects.html#1448">1448</a>.
<p/>
Note the following program:
</p>
<blockquote><pre>
string s("s1: 123456789");
ostringstream s1(s, ios_base::out|ios_base::app);
s1 &lt;&lt; "hello";
cout &lt;&lt; s1.str() &lt;&lt; endl;
</pre></blockquote>
<p>
With g++4.x it prints:
</p>
<blockquote><pre>
s1: 123456789hello
</pre></blockquote>
<p>
With VisualC++10 it prints:
</p>
<blockquote><pre>
hello23456789
</pre></blockquote>
<p>
From my intuitive understanding the flag "app" should result in the output of g++4.x.
I also would read that from 27.5.3.1.4 [ios::openmode] claiming:
</p>
<blockquote><p>
<tt>app</tt>&nbsp;&nbsp;&nbsp;seek to end before each write
</p></blockquote>
<p>
However in issue <a href="lwg-defects.html#1448">1448</a> P.J.Plauger comments:
</p>
<blockquote><p>
I think we should say nothing special about <tt>app</tt> at construction time (thus leaving the write pointer at the beginning of the buffer).
Leave implementers wiggle room to ensure subsequent append writes as they see fit, but don't change existing rules for initial seek
position.
</p></blockquote>
<p>
Note that the flag <tt>ate</tt> on both platforms appends "hello" to <tt>s</tt>.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2122"></a>2122. <tt>merge()</tt> stability for lists versus forward lists</h3>
<p><b>Section:</b> 23.3.5.5 [list.ops], 23.3.4.6 [forwardlist.ops] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2012-01-15 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#list.ops">issues</a> in [list.ops].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
<tt>forward_list::merge()</tt> is specified in  23.3.4.6 [forwardlist.ops], p19 as follows:
</p>
<blockquote><p>
This operation shall be stable: for equivalent elements in the two lists,
the elements from <tt>*this</tt> shall always precede the elements from <tt>x</tt>.
</p></blockquote>
<p>
But <tt>list::merge()</tt> is only specified in 23.3.5.5 [list.ops], p24 as follows:
</p>
<blockquote><p>
<i>Remarks</i>: Stable.
</p></blockquote>
<p>
Note that in general we define "stable" only for algorithms (see  [defns.stable] and 
17.6.5.7 [algorithm.stable]) so for member function we should explain it everywhere we use it.
<p/>
Thus for lists we have to add:
</p>
<blockquote><p>
Stable: for equivalent elements in the two lists, the elements from the list always precede the elements
from the argument list.
</p></blockquote>
<p>
This, BTW, was the specification we had with C++03.
<p/>
In addition, I wonder whether we also have some guarantees regarding stability saying that the order 
of equivalent elements of each list merged remains stable (which would be my interpretation of just 
saying "stable", BTW).
<p/>
Thus, I'd expect that for equivalent elements we guarantee that
</p>
<ul>
 <li> we first have all element of <tt>*this</tt> (in the same order as on entry)</li>
 <li> and then all elements of the passed argument (in the same order as on entry).</li>
</ul>


<p><i>[2012, Kona]</i></p>

<p>
Move to Open.
</p>
<p>
STL says we need to fix up 17.6.5.7 to be stronger, and then the remarks for merge should
just say "Remarks: Stable (see 17.6.5.7)"
</p>
<p>
Assigned to STL for word-smithing.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li>
<p>Change 23.3.5.5 [list.ops] as indicated:</p>

<blockquote><pre>
void                          merge(list&lt;T,Allocator&gt;&amp; x);
void                          merge(list&lt;T,Allocator&gt;&amp;&amp; x);
template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp; x, Compare comp);
template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);</pre>
<blockquote><p>
[&hellip;]
<p/>
-24- <i>Remarks</i>: <del>Stable</del><ins>This operation shall be stable: for equivalent elements 
in the two lists, the elements from <tt>*this</tt> shall always precede the elements from <tt>x</tt>
and the order of equivalent elements of <tt>*this</tt> and <tt>x</tt> remains stable</ins>. If 
<tt>(&amp;x != this)</tt> the range <tt>[x.begin(), x.end())</tt> 
is empty after the merge. No elements are copied by this operation. The behavior is undefined if 
<tt>this-&gt;get_allocator() != x.get_allocator()</tt>.
</p></blockquote></blockquote>
</li>

<li>
<p>Change 23.3.4.6 [forwardlist.ops] as indicated:</p>

<blockquote><pre>
void merge(forward_list&lt;T,Allocator&gt;&amp; x);
void merge(forward_list&lt;T,Allocator&gt;&amp;&amp; x);
template &lt;class Compare&gt; void merge(forward_list&lt;T,Allocator&gt;&amp; x, Compare comp);
template &lt;class Compare&gt; void merge(forward_list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);</pre>
<blockquote><p>
[&hellip;]
<p/>
-19- <i>Effects</i>: Merges <tt>x</tt> into <tt>*this</tt>. This operation shall be stable: for 
equivalent elements in the two lists, the elements from <tt>*this</tt> shall always precede the 
elements from <tt>x</tt> <ins>and the order of equivalent elements of <tt>*this</tt> and <tt>x</tt> 
remains stable</ins>. <tt>x</tt> is empty after the merge. If an exception is thrown other 
than by a comparison there are no effects. 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></blockquote>
</li>
</ol>






<hr>
<h3><a name="2123"></a>2123. <tt>merge()</tt> allocator requirements for lists versus forward lists</h3>
<p><b>Section:</b> 23.3.4.6 [forwardlist.ops] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2012-01-15 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Sub-clause 23.3.5.5 [list.ops], p24 states for lists:
</p>
<blockquote><p>
The behavior is undefined if <tt>this-&gt;get_allocator() != x.get_allocator()</tt>.
</p></blockquote>
<p>
But there is nothing like that for forward lists in 23.3.4.6 [forwardlist.ops],
although I would expect the same undefined behavior there.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Move to Ready.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li>
<p>Add a new paragraph after 23.3.4.6 [forwardlist.ops] p19 as indicated:</p>

<blockquote><pre>
void merge(forward_list&lt;T,Allocator&gt;&amp; x);
void merge(forward_list&lt;T,Allocator&gt;&amp;&amp; x);
template &lt;class Compare&gt; void merge(forward_list&lt;T,Allocator&gt;&amp; x, Compare comp);
template &lt;class Compare&gt; void merge(forward_list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);</pre>
<blockquote><p>
[&hellip;]
<p/>
-19- <i>Effects</i>: [&hellip;]
<p/>
<ins>-?- <i>Remarks</i>: The behavior is undefined if <tt>this-&gt;get_allocator() != x.get_allocator()</tt>.</ins>
</p></blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2124"></a>2124. Seed sequence over-specified</h3>
<p><b>Section:</b> 26.5.1.2 [rand.req.seedseq] <b>Status:</b> <a href="lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2012-01-16 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#rand.req.seedseq">active issues</a> in [rand.req.seedseq].</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.req.seedseq">issues</a> in [rand.req.seedseq].</p>
<p><b>Discussion:</b></p>

<p>
The seed sequence requirements described in 26.5.1.2 [rand.req.seedseq] appear to be over-specified. 
All seed sequence types are required to have a <tt>result_type</tt> nested type, a specific set of 
constructors, function members <tt>size()</tt> and <tt>param()</tt>, which are never used by the library. 
In fact, the only library components that actively use seed sequences are the random engines and all the 
engines need is the <tt>generate()</tt> member function. In particular, library components never attempts 
to construct seed sequence objects. These extraneous requirements are clearly written to describe the 
library provided type <tt>seed_seq</tt> type; while it's good that seed_seq has all those constructors and 
members, it's not a compelling reason to require a user-provided seed sequence type to implement all of 
them.
<p/>
Suppose I want to write my own seed sequence class, this should do fine (and actually works as expected with libc++):
</p>
<blockquote><pre>
class my_seed_seq
{
  /* internals */
public:
  my_seed_seq(/* my own parameters */);

  template &lt;class It&gt;
  void generate(It first, It last);
};

my_seed_seq s(/* params */);
std::default_random_engine e(s);
</pre></blockquote>
<p>
The only reason to have these extra members would be to provide some support for generic serializability&#47;persistence 
of seed sequence objects. I believe that would be out of the scope of the random library, so I doubt we will ever need 
those requirements in the future.
<p/>
I therefore propose to remove all requirements from 26.5.1.2 [rand.req.seedseq] except for the presence of the 
<tt>generate()</tt> function.
</p>

<p><i>[2012, Kona]</i></p>

<p>
Move to Tenatively NAD.  (Tentative as issue was not in pre-meeting mailing)
</p>
<p>
The 'overspecification', as such, was a deliberate intent to provide guarantees consumers of the whole
random number framework may rely upon, especially in generic code.  While the standard engines may be
built without relying on these guarantees, this specification is part of a commitment to a broader
framework, and Walter indicated future proposals in preparation for parallel generation of random
numbers that may depend more inimately on these existing requirements.
</p>
<p>
Alisdair noted that the <tt>result_type</tt> typedef was a call-back to how we used to specify
adaptable functors before TR1 <tt>result_of</tt> and the addition of <tt>std::bind</tt> and is
probably not something we should be actively promoting in future libraries.  However, it is too
late to remove this requirement from seed sequences unless we are doing further surgery, as
recommended by this issue.
</p>
<p>
Walter notes that the <tt>result_type</tt> protocol has not been formally deprecated by the
standard.  Alisdair replies that was the intent of deprecating the <tt>bind_1st</tt>/
<tt>unary_function</tt> set of templates in C++11, although we did not say anything about
<tt>result_type</tt> in general.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li>
<p>Edit 26.5.1.2 [rand.req.seedseq] p2 as indicated:</p>

<blockquote><p>
A class <tt>S</tt> satisfies the requirements of a seed sequence if the expressions shown in Table 115 are valid and
have the indicated semantics, and if <tt>S</tt> also satisfies all other requirements of this section 26.5.1.2 [rand.req.seedseq]. 
In that Table and throughout this section:
</p>
<ol style="list-style-type:lower-alpha">
<li>
<del><tt>T</tt> is the type named by <tt>S</tt>'s associated <tt>result_type</tt>;</del>
</li>
<li>
<tt>q</tt> is a value of <tt>S</tt><del> and <tt>r</tt> is a possibly const value of <tt>S</tt></del>; <ins>and</ins>
</li>
<li>
<del><tt>ib</tt> and <tt>ie</tt> are input iterators with an unsigned integer <tt>value_type</tt> of at least 32 bits;</del>
</li>
<li><tt>rb</tt> and <tt>re</tt> are mutable random access iterators with an unsigned integer <tt>value_type</tt> of at least 32 bits;</li>
<li>
<del><tt>ob</tt> is an output iterator; and</del>
</li>
<li>
<del><tt>il</tt> is a value of <tt>initializer_list&lt;T&gt;</tt>.</del>
</li>
</ol>
</blockquote>
</li>

<li>
<p>Ditto, in Table 115, remove all rows except the one describing <tt>q.generate(rb, re)</tt>:</p>

<table border="1">
<caption>Table 115 &mdash; Seed sequence requirements</caption>
<tr align="center">
<th>Expression</th>
<th>Return type</th>
<th>Pre&#47;Post-condition</th>
<th>Complexity</th>
</tr> 

<tr>
<td>
<del><tt>S::result_type</tt></del>
</td>
<td>
<del><tt>T</tt></del>
</td>
<td>
<del><tt>T</tt> is an unsigned integer<br/>
type (3.9.1 [basic.fundamental]) of at least 32 bits.</del>
</td>
<td>
<del>compile-time</del>
</td>
</tr>

<tr>
<td>
<del><tt>S()</tt></del>
</td>
<td>
&nbsp;
</td>
<td>
<del>Creates a seed sequence with<br/>
the same initial state as all<br/>
other default-constructed seed<br/>
sequences of type <tt>S</tt>.</del>
</td>
<td>
<del>constant</del>
</td>
</tr>

<tr>
<td>
<del><tt>S(ib,ie)</tt></del>
</td>
<td>
&nbsp;
</td>
<td>
<del>Creates a seed sequence having<br/>
internal state that depends on<br/>
some or all of the bits of the<br/>
supplied sequence <tt>[ib, ie)</tt>.</del>
</td>
<td>
<del><tt>&#x1d4aa;(ie - ib)</tt></del>
</td>
</tr>

<tr>
<td>
<del><tt>S(il)</tt></del>
</td>
<td>
&nbsp;
</td>
<td>
<del>Same as <tt>S(il.begin(),<br/>
il.end())</tt>.</del>
</td>
<td>
<del>same as<br/>
<tt>S(il.begin(),<br/>
il.end())</tt></del>
</td>
</tr>

<tr>
<td>
<tt>q.generate(rb,re)</tt>
</td>
<td>
<tt>void</tt>
</td>
<td>
Does nothing if <tt>rb == re</tt>.<br/>
Otherwise, fills the supplied<br/>
sequence <tt>[rb, re)</tt> with 32-bit<br/>
quantities that depend on the<br/>
sequence supplied to the<br/>
constructor and possibly also<br/>
depend on the history of<br/>
<tt>generate</tt>'s previous<br/>
invocations.
</td>
<td>
<tt>&#x1d4aa;(re - rb)</tt>
</td>
</tr>

<tr>
<td>
<del><tt>r.size()</tt></del>
</td>
<td>
<del><tt>size_t</tt></del>
</td>
<td>
<del>The number of 32-bit units that<br/>
would be copied by a call to<br/>
<tt>r.param</tt>.</del>
</td>
<td>
<del>constant</del>
</td>
</tr>

<tr>
<td>
<del><tt>r.param(ob)</tt></del>
</td>
<td>
<del><tt>void</tt></del>
</td>
<td>
<del>Copies to the given destination
a sequence of 32-bit units that<br/>
can be provided to the<br/>
constructor of a second object<br/>
of type <tt>S</tt>, and that would<br/>
reproduce in that second object<br/>
a state indistinguishable from<br/>
the state of the first object.</del>
</td>
<td>
<del><tt>&#x1d4aa;(r.size())</tt></del>
</td>
</tr>

</table>
 </li>

</ol>






<hr>
<h3><a name="2125"></a>2125. <tt>TimedMutex</tt> specification problem</h3>
<p><b>Section:</b> 30.4.1.3 [thread.timedmutex.requirements], 30.4.1.3.1 [thread.timedmutex.class] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Vicente J. Botet Escriba <b>Opened:</b> 2012-01-01 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#thread.timedmutex.requirements">active issues</a> in [thread.timedmutex.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.timedmutex.requirements">issues</a> in [thread.timedmutex.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
30.4.1.3.1 [thread.timedmutex.class] says:
</p>
<blockquote><p>
The class <tt>timed_mutex</tt> shall satisfy all of the <tt>TimedMutex</tt> requirements (30.4.1.3 [thread.timedmutex.requirements]). 
It shall be a standardlayout class (Clause 9 [class]).
</p></blockquote>
<p>
Problem here is that 30.4.1.3 [thread.timedmutex.requirements] does not define a requirement set named &quot;<tt>TimedMutex</tt>&quot;,
it only refers to &quot;<i>timed mutex types</i>&quot;
</p>

<p><i>[See also issue <a href="lwg-active.html#2126">2126</a>]</i></p>




<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2126"></a>2126. Several specification problems in regard to mutex requirements</h3>
<p><b>Section:</b> 30.4.1 [thread.mutex.requirements], 30.4.1.2.1 [thread.mutex.class], 30.4.1.2 [thread.mutex.requirements.mutex], 30.4.1.2.2 [thread.mutex.recursive], 30.4.1.3 [thread.timedmutex.requirements], 30.4.1.3.1 [thread.timedmutex.class], 30.4.1.3.2 [thread.timedmutex.recursive] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-01-16 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
 30.4.1.2.1 [thread.mutex.class]&#47;3 says that the class mutex "shall satisfy all the <tt>Mutex</tt> requirements (30.4.1 [thread.mutex.requirements])". 
 30.4.1.2.1 [thread.mutex.class] is part of 30.4.1 [thread.mutex.requirements], so at the very least, this 
 requirement is recursive. But worse, there is nothing that says what "the <tt>Mutex</tt> requirements" refers to. For example, 
 the "<tt>Lockable</tt> requirements" section starts with "A type <tt>L</tt> meets the <tt>Lockable</tt> requirements if &hellip;". There is no such 
 statement for "the <tt>Mutex</tt> requirements".
<p/>
Organizationally, paragraphs 1-26 in 30.4.1.2 [thread.mutex.requirements.mutex] should probably be in a subclause with a name. 
(This is actually an ISO requirement, to avoid exactly this kind of ambiguous referencing) Then the first sentence of 
30.4.1.2.1 [thread.mutex.class]&#47;3 can become a note: "The class mutex meets the requirements of (whatever)", since that 
subclause already says that the mutex types "shall meet the requirements set out in this section."
<p/>
And similarly for 30.4.1.2.2 [thread.mutex.recursive]&#47;2 (<tt>recursive_mutex</tt>).
<p/>
30.4.1.3 [thread.timedmutex.requirements], Timed mutex types, also needs the same rearrangement: its introductory 
requirements should be moved into a subclause, and the first sentences of 30.4.1.3.1 [thread.timedmutex.class]&#47;2 
and 30.4.1.3.2 [thread.timedmutex.recursive]&#47;2 should be turned into notes that refer to this new subclause and 
to the new subclause in 30.4.1.2 [thread.mutex.requirements.mutex].
</p>

<p><i>[See also issue <a href="lwg-active.html#2125">2125</a>]</i></p>




<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2127"></a>2127. Move-construction with <tt>raw_storage_iterator</tt></h3>
<p><b>Section:</b> 20.6.10 [storage.iterator] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-01-23 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#storage.iterator">issues</a> in [storage.iterator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Aliaksandr Valialkin pointed out that <tt>raw_storage_iterator</tt> only supports constructing 
a new object from lvalues so cannot be used to construct move-only types:
</p>
<blockquote><pre>
template &lt;typename InputIterator, typename T&gt;
void move_to_raw_buffer(InputIterator first, InputIterator last, T *raw_buffer)
{
  std::move(first, last, std::raw_storage_iterator&lt;T *, T&gt;(raw_buffer));
}
</pre></blockquote>
<p>
This could easily be solved by overloading <tt>operator=</tt> for rvalues.
<p/>
Dave Abrahams:
<p/>
<tt>raw_storage_iterator</tt> causes exception-safety problems when used with any
generic algorithm. I suggest leaving it alone and not encouraging its use.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf">N3337</a>.</p>

<ol>
<li><p>Add a new signature to the synopsis in 20.6.10 [storage.iterator] p1:</p>

<blockquote><pre>
namespace std {
  template &lt;class OutputIterator, class T&gt;
  class raw_storage_iterator
    : public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
  public:
    explicit raw_storage_iterator(OutputIterator x);

    raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator*();
    raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(const T&amp; element);
    <ins>raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(T&amp;&amp; element);</ins>
    raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator++();
    raw_storage_iterator&lt;OutputIterator,T&gt; operator++(int);
};
}
</pre></blockquote>
</li>

<li><p>Insert the new signature and a new paragraph before p4:</p>

<blockquote><pre>
raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(const T&amp; element);
<ins>raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(T&amp;&amp; element);</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Requires</i>: For the first signature <tt>T</tt> shall be <tt>CopyConstructible</tt>. For
the second signature <tt>T</tt> shall be <tt>MoveConstructible</tt>.</ins>
<p/>
-4- <i>Effects</i>: Constructs a value from <tt>element</tt> at the location to which the iterator points.
<p/>
-5- <i>Returns</i>: A reference to the iterator.
</p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2128"></a>2128. Absence of global functions <tt>cbegin&#47;cend</tt></h3>
<p><b>Section:</b> 24.3 [iterator.synopsis], 24.6.5 [iterator.range] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Dmitry Polukhin <b>Opened:</b> 2012-01-23 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.synopsis">issues</a> in [iterator.synopsis].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
All standard containers support <tt>cbegin&#47;cend</tt> member functions but corresponding global functions are 
missing. Proposed resolution it to add global <tt>cbegin&#47;cend</tt> functions by analogy with global <tt>begin&#47;end</tt> 
functions. This addition will unify things for users.
</p>

<p><i>[2012, Kona]</i></p>


<p>STL: Range-based for loops do not use global <tt>begin</tt>/<tt>end</tt> (anymore).</p>
<p>Alisdair: We will have to make sure these will be available through many headers.</p>
<p>STL: Do this, including <tt>r</tt> and <tt>cr</tt>. This won't add any additional work.</p>
<p>Matt: Users will find it strange if these are not all available.</p>
<p>Alisdair: Should we have these available everywhere begin/end are available?</p>
<p>Marshall: Yes. Not any extra work.</p>
<p>Howard: Adding all of these means we need all of <tt>&lt;iterator></tt>.</p>
<p>STL: We already need it all.</p>
<p>Matt: We have to be careful what we are requiring if we include the <tt>r</tt> versions.</p>
<p>Jeffrey: If we include <tt>r</tt>, should they adapt if the container does not define reverse iteration?</p>
<p>STL: No. No special behavior. Should fail to compile. Up to user to add the reverse code--it's easy.</p>
<p>Howard: Anyway it will SFINAE out.</p>
<p>Alisdair: Error messages due to SFINAE are harder to understand than simple failure to compile.</p>
<p>STL: Agrees that SFINAE makes error messages much worse.</p>

<p>
Action: STL to provide additional wording for the <tt>r</tt> variants.
Move to Review once that wording is availalbe.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf">N3337</a>.</p>

<ol>
<li><p>In 24.3 [iterator.synopsis], header iterator synopsis, add the following declarations::</p>

<blockquote><pre>
namespace std {
  [&hellip;]
  <i>// 24.6.5, range access:</i>
  template &lt;class C&gt; auto begin(C&amp; c) -> decltype(c.begin());
  template &lt;class C&gt; auto begin(const C&amp; c) -> decltype(c.begin());
  template &lt;class C&gt; auto end(C&amp; c) -> decltype(c.end());
  template &lt;class C&gt; auto end(const C&amp; c) -> decltype(c.end());
  <ins>template &lt;class C&gt; auto cbegin(const C&amp; c) -> decltype(c.cbegin());</ins>
  <ins>template &lt;class C&gt; auto cend(const C&amp; c) -> decltype(c.cend());</ins>
  template &lt;class T, size_t N&gt; T* begin(T (&amp;array)[N]);
  template &lt;class T, size_t N&gt; T* end(T (&amp;array)[N]);
  <ins>template &lt;class T, size_t N&gt; const T* cbegin(T (&amp;array)[N]);</ins>
  <ins>template &lt;class T, size_t N&gt; const T* cend(T (&amp;array)[N]);</ins>
}
</pre></blockquote>
</li>

<li><p>In 24.6.5 [iterator.range] after p5 add the following series of paragraphs:</p>

<blockquote>
<pre>
<ins>template &lt;class C&gt; auto cbegin(const C&amp; c) -> decltype(c.cbegin());</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Returns</i>: <tt>c.cbegin()</tt>.</ins>
</p>
</blockquote>

<pre>
<ins>template &lt;class C&gt; auto cend(const C&amp; c) -> decltype(c.cend());</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Returns</i>: <tt>c.cend()</tt>.</ins>
</p>
</blockquote>

<pre>
<ins>template &lt;class T, size_t N&gt; const T* cbegin(T (&amp;array)[N]);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Returns</i>: <tt>array</tt>.</ins>
</p>
</blockquote>

<pre>
<ins>template &lt;class T, size_t N&gt; const T* cend(T (&amp;array)[N]);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Returns</i>: <tt>array + N</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2129"></a>2129. User specializations of <tt>std::initializer_list</tt></h3>
<p><b>Section:</b> 17.6.4.2.1 [namespace.std], 18.9 [support.initlist] <b>Status:</b> <a href="lwg-active.html#Open">Open</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2012-01-18 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#namespace.std">active issues</a> in [namespace.std].</p>
<p><b>View all other</b> <a href="lwg-index.html#namespace.std">issues</a> in [namespace.std].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Since the implementation is intended to magically synthesize instances of <tt>std::initializer_list</tt> 
(rather than by a constructor call, for instance), user specializations of this type can't generally be 
made to work. I can't find any wording which makes such specializations ill-formed, though, which leads 
me to suspect that they're technically legal under the provisions of 17.6.4.2.1 [namespace.std] p1.</p>



<p><i>[2012, Kona]</i></p>

<p>
This sounds correct, but we need wording for a resultion.
</p>
<p>
Marshall Clow volunteers to produce wording.
</p>

<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2130"></a>2130. Missing ordering constraints</h3>
<p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Mark Batty <b>Opened:</b> 2012-02-22 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>C11 issue 407</b></p>

<p>
It seems that both C11 and C++11 are missing the following two derivatives of this 
rule:
</p>
<blockquote><p>
  For atomic modifications <tt>A</tt> and <tt>B</tt> of an atomic object <tt>M</tt>, if there is
  a <tt>memory_order_seq_cst</tt> fence <tt>X</tt> such that <tt>A</tt> is sequenced before <tt>X</tt>,
  and <tt>X</tt> precedes <tt>B</tt> in <tt>S</tt>, then <tt>B</tt> occurs later than <tt>A</tt> in the
  modification order of <tt>M</tt>.
</p></blockquote>
<blockquote><p>
  For atomic modifications <tt>A</tt> and <tt>B</tt> of an atomic object <tt>M</tt>, if there is
  a <tt>memory_order_seq_cst</tt> fence <tt>Y</tt> such that <tt>Y</tt> is sequenced before <tt>B</tt>,
  and <tt>A</tt> precedes <tt>Y</tt> in <tt>S</tt>, then <tt>B</tt> occurs later than <tt>A</tt> in the
  modification order of <tt>M</tt>.
</p></blockquote>
<p>
Above wording has been suggested for the Technical Corrigendum of C11 via issue 407, details can be found 
<a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1584.pdf">here</a>.
</p>

<p><i>[2012-03-19: Daniel proposes a slightly condensed form to reduce wording duplications]</i></p>


<p><i>[2012-03-20: Hans comments]</i></p>

<p>
The usage of the term <em>atomic operations</em> in 29.3 [atomics.order] p7 is actually
incorrect and should better be replaced by <em>atomic modifications</em> as used in the C11
407 wording.
<p/>
There seems to be a similar wording incorrectness used in 1.10 [intro.multithread] p17
which should be corrected as well.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p><em>[Drafting note: The project editor is kindly asked to consider to replace in 1.10 [intro.multithread] p17
the phrase <em>"before an operation <i>B</i> on <i>M</i>"</em> by <em>"before a modification <i>B</i> of <i>M</i>"</em>.]</em></p>
</li>
<li><p>Change 29.3 [atomics.order] paragraph 7 as indicated: <em>[Drafting note: Note that the
wording change intentionally does also replace the term <em>atomic operation</em> by <em>atomic modification</em>]</em>
</p>

<p>
-7- <del>For atomic operations <i>A</i> and <i>B</i> on an atomic object <i>M</i>, if there are 
<tt>memory_order_seq_cst</tt> fences <i>X</i> and <i>Y</i> such that <i>A</i> is sequenced before <i>X</i>, 
<i>Y</i> is sequenced before <i>B</i>, and <i>X</i> precedes <i>Y</i> in <i>S</i>, then <i>B</i> 
occurs later than <i>A</i> in the modification order of <i>M</i>.</del>
<ins>For atomic modifications <i>A</i> and <i>B</i> of an atomic object <i>M</i>, <i>B</i> occurs
later than <i>A</i> in the modification order of <i>M</i> if:</ins>
<ul>
<li><ins>there is a <tt>memory_order_seq_cst</tt> fence <i>X</i> such that <i>A</i> is sequenced before <i>X</i>, 
and <i>X</i> precedes <i>B</i> in <i>S</i>, or</ins>
</li>
<li><ins>there is a <tt>memory_order_seq_cst</tt> fence <i>Y</i> such that <i>Y</i> is sequenced before <i>B</i>,
and <i>A</i> precedes <i>Y</i> in <i>S</i>, or</ins>
</li>
<li><ins>there are <tt>memory_order_seq_cst</tt> fences <i>X</i> and <i>Y</i> such that <i>A</i> is sequenced 
before <i>X</i>, <i>Y</i> is sequenced before <i>B</i>, and <i>X</i> precedes <i>Y</i> in <i>S</i>.</ins>
</li>
</ul>
<p/>
-8- [ <i>Note</i>: <tt>memory_order_seq_cst</tt> ensures sequential consistency only for a program that is free of data races
and 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 ensure a total order
only for the fences themselves. Fences cannot, in general, be used to restore sequential consistency for atomic
operations with weaker ordering specifications. &mdash; <i>end note</i> ]
</p>
</li>
</ol>






<hr>
<h3><a name="2131"></a>2131. Member function getline taking a string as parameter</h3>
<p><b>Section:</b> 27.7.2.3 [istream.unformatted] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Lo&iuml;c Joly <b>Opened:</b> 2012-03-05 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
<p><b>View all other</b> <a href="lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I think the following code should be legal:
</p>
<blockquote><pre>
void f(std::istream&amp; is)
{
  std::string s;
  is.getline(s); // Would be equivalent to std::getline(is, s)
}
</pre></blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change the class template <tt>basic_istream</tt> synopsis, 27.7.2.1 [istream], as indicated</p>
<blockquote><pre>
namespace std {
  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
  class basic_istream : virtual public basic_ios&lt;charT,traits&gt; {
  public:
    [&hellip;]
    <i>// 27.7.2.3 Unformatted input:</i>
    [&hellip;]
    basic_istream&lt;charT,traits&gt;&amp; getline(char_type* s, streamsize n);
    basic_istream&lt;charT,traits&gt;&amp; getline(char_type* s, streamsize n,
      char_type delim);
    <ins>template&lt;class Allocator&gt;
    basic_istream&lt;charT,traits&gt;&amp; getline(basic_string&lt;charT,traits,Allocator&gt;&amp; str);
    template&lt;class Allocator&gt;
    basic_istream&lt;charT,traits&gt;&amp; getline(basic_string&lt;charT,traits,Allocator&gt;&amp; str,
      char_type delim);</ins>
    [&hellip;]
  };
}
</pre></blockquote>
</li>

<li><p>Insert the following two new prototype descriptions after 27.7.2.3 [istream.unformatted] paragraph 24:</p>

<blockquote>
<pre>
basic_istream&lt;charT,traits&gt;&amp; getline(char_type* s, streamsize n);
</pre>
<blockquote><p>
-24- <i>Returns</i>: <tt>getline(s,n,widen('\n'))</tt>
</p>
</blockquote>

<pre>
<ins>template&lt;class Allocator&gt;
basic_istream&lt;charT,traits&gt;&amp; getline(basic_string&lt;charT,traits,Allocator&gt;&amp; str);</ins>
</pre>
<blockquote><p>
<ins>-??- <i>Returns</i>: <tt>std::getline(*this, str)</tt></ins>
</p>
</blockquote>

<pre>
<ins>template&lt;class Allocator&gt;
basic_istream&lt;charT,traits&gt;&amp; getline(basic_string&lt;charT,traits,Allocator&gt;&amp; str, char_type delim);</ins>
</pre>
<blockquote><p>
<ins>-??- <i>Returns</i>: <tt>std::getline(*this, str, delim)</tt></ins>
</p>
</blockquote>

</blockquote>
</li>
</ol>






<hr>
<h3><a name="2132"></a>2132. <tt>std::function</tt> ambiguity</h3>
<p><b>Section:</b> 20.8.11.2.1 [func.wrap.func.con] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2012-02-28 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider the following:
</p>
<blockquote><pre>
#include &lt;functional&gt;

void f(std::function&lt;void()&gt;) {}
void f(std::function&lt;void(int)&gt;) {}

int main() {
  f([]{});
  f([](int){});
}
</pre></blockquote>
<p>
The calls to <tt>f</tt> in <tt>main</tt> are ambiguous. Apparently because the
conversion sequences to <tt>std::function</tt> from the lambdas are identical. 
The standard specifies that the function object given to <tt>std::function</tt>
"shall be <em>Callable</em> (20.8.11.2) for argument types <tt>ArgTypes</tt> and 
return type <tt>R</tt>." It doesn't say that if this is not the case, the 
constructor isn't part of the overload set.
<p/>
Daniel: During the preparation of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3123.html">N3123</a>
it turned out that there are no longer reasons to refer to <em>INVOKE</em> as a
conceptually entity alone, its real implementation as a function template <tt>invoke</tt>
is possible but was deferred for a later point in time. Defining a type trait for
the <em>Callable</em> requirement would also be possible, so there seem to be no technical
reasons why the template constructor of <tt>std::function</tt> should not be
constrained. The below suggested wording does this without introducing a special
trait for this. This corresponds to the way that has been used to specify the
<tt>result_of</tt> trait. Note that the definition of the <em>Callable</em>
requirement is perfectly suitable for this, because it is a pure syntactically
based requirement and can be directly transformed into a constrained template.
<p/>
The suggested resolution also applies such wording to the "perfectly forwarding"
assignment operator
</p>
<blockquote><pre>
template&lt;class F&gt; function&amp; operator=(F&amp;&amp;);
</pre></blockquote>
<p>
The positive side-effect of this is that it automatically implements a solution to
a problem similar to that mentioned in issue <a href="lwg-defects.html#1234">1234</a>.
<p/>
It would be possible to apply similar constraints to the member signatures
</p>
<blockquote><pre>
template&lt;class F&gt; function&amp; operator=(reference_wrapper&lt;F&gt;);

template&lt;class F, class A&gt; void assign(F&amp;&amp;, const A&amp;);
</pre></blockquote>
<p>
as well. At this point there does not seem to be a pestering reason to do so.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change the following paragraphs in 20.8.11.2.1 [func.wrap.func.con]:
[<em>Editorial comment</em>: The removal of the seemingly additional no-throw
requirements of copy constructor and destructor of <tt>A</tt> is recommended,
because they are already part of the Allocator requirements. Similar clean-up
has been suggested by <a href="lwg-active.html#2070">2070</a> &mdash; <em>end comment</em>]</p>

<blockquote>
<pre>
template&lt;class F> function(F f);
template&lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre>
<blockquote>
<p>
-7- <i>Requires</i>: <tt>F</tt> shall be <tt>CopyConstructible</tt>. <del><tt>f</tt> shall be Callable 
(20.8.11.2 [func.wrap.func]) for argument types <tt>ArgTypes</tt> and return type <tt>R</tt>. 
The copy constructor and destructor of <tt>A</tt> shall not throw exceptions.</del>
<p/>
<ins>-?- <i>Remarks</i>: These constructors shall not participate in overload resolution unless
<tt>declval&lt;F&amp;&gt;()</tt> is Callable (20.8.11.2 [func.wrap.func]) for argument types <tt>ArgTypes</tt> 
and return type <tt>R</tt>.</ins>
</p>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template&lt;class F> function&amp; operator=(F&amp;&amp; f);
</pre>
<blockquote>
<p>
-18- <i>Effects</i>: <tt>function(std::forward&lt;F&gt;(f)).swap(*this);</tt>
<p/>
-19- <i>Returns</i>: <tt>*this</tt>
<p/>
<ins>-?- <i>Remarks</i>: This assignment operator shall not participate in overload resolution unless
<tt>declval&lt;decay&lt;F&gt;::type&amp;&gt;()</tt> is Callable (20.8.11.2 [func.wrap.func]) 
for argument types <tt>ArgTypes</tt> and return type <tt>R</tt>.</ins>
</p>
</blockquote>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2133"></a>2133. Attitude to overloaded comma for iterators</h3>
<p><b>Section:</b> 17.6.5.4 [global.functions] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Yakov Galka <b>Opened:</b> 2012-01-25 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#global.functions">issues</a> in [global.functions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
17.6.5.4 [global.functions] says
</p>
<blockquote><p>
Unless otherwise specified, global and non-member functions in the standard library 
shall not use functions from another namespace which are found through argument-dependent 
name lookup (3.4.2).
</p></blockquote>
<p>
This sounds clear enough. There are just two problems:
</p>
<ol>
<li><p>
Both implementations I tested (VS2005 and GCC 3.4.3) do unqualified
calls to the comma operator in some parts of the library with operands
of user-defined types.
</p></li>
<li>
<p>
The standard itself does this in the description of some algorithms. E.g. <tt>uninitialized_copy</tt> 
is defined as:
</p>
<blockquote><p>
<i>Effects</i>:
</p><blockquote>
<pre>
for (; first != last; <span style="color:#C80000;font-weight:bold">++result, ++first</span>)
  ::new (static_cast&lt;void*&gt;(&amp;*result))
    typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
</pre>
</blockquote>
</blockquote>
</li>
</ol>
<p>
If understood literally, it is required to call <tt>operator,(ForwardIterator, InputIterator)</tt>.
<p/>
For detailed discussion with code samples see 
<a href="http://stackoverflow.com/questions/8719829/should-the-implementation-guard-itself-against-comma-overloading">here</a>.
<p/>
Proposal:
</p>
<ol>
<li>
Add an exception to the rule in 17.6.5.4 [global.functions] by permitting
the implementation to call the comma operator as much as it wants to. I doubt we want this. or
</li>
<li>
Fix the description of the said algorithms and perhaps add a note to 17.6.5.4 [global.functions] 
that brings attention of the implementers to avoid this pitfall.
</li>
</ol>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2134"></a>2134. Redundant Mutex requirement?</h3>
<p><b>Section:</b> 30.4.1.2 [thread.mutex.requirements.mutex] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-03-05 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.mutex.requirements.mutex">issues</a> in [thread.mutex.requirements.mutex].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
30.4.1.2 [thread.mutex.requirements.mutex]&#47;11 says that prior unlock operations <em>synchronize with</em> <tt>m.lock()</tt>.
<p/>
30.4.1.2 [thread.mutex.requirements.mutex]&#47;19 says that if <tt>m.try_lock()</tt> succeeds, prior unlock operations 
<em>synchronize with</em> the operation. 
<p/>
30.4.1.2 [thread.mutex.requirements.mutex]&#47;25 says that <tt>m.unlock()</tt> <em>synchronizes with</em> subsequent 
successful lock operations. 
<p/>
Does the third requirement add anything to the first two? If not, it should probably be a non-normative note.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2135"></a>2135. Unclear requirement for exceptions thrown in <tt>condition_variable::wait()</tt></h3>
<p><b>Section:</b> 30.5.1 [thread.condition.condvar], 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-03-06 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
<tt>condition_varible::wait()</tt> (and, presumably, <tt>condition_variable_any::wait()</tt>, although 
I haven't looked at it) says that it calls <tt>lock.unlock()</tt>, and if <tt>condition_variable::wait()</tt> 
exits by an exception it calls <tt>lock.lock()</tt> on the way out. But if the initial call to 
<tt>lock.unlock()</tt> threw an exception, does it make sense to call <tt>lock.lock()</tt>? We simply 
don't know the state of that lock object, and it's probably better not to touch it.
<p/>
That aside, once the <tt>wait()</tt> call has been unblocked, it calls <tt>lock.lock()</tt>. If <tt>lock.lock()</tt> 
throws an exception, what happens? The requirement is:
</p>
<blockquote><p>
If the function exits via an exception, <tt>lock.lock()</tt> shall be called prior to exiting the function scope.
</p></blockquote>
<p>
That can be read in two different ways. One way is as if it said "<tt>lock.lock()</tt> shall have been called ", 
i.e. the original, failed, call to <tt>lock.lock()</tt> is all that's required. But a more natural reading is 
that wait has to call <tt>lock.lock()</tt> again, even though it already failed.
<p/>
I think this wording suffers from being too general. There are two possible exception sources: the initial call 
to <tt>lock.unlock()</tt> and the final call to <tt>lock.lock()</tt>. Each one should have its own requirement. 
Lumping them together muddles things.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2136"></a>2136. Postconditions vs. exceptions</h3>
<p><b>Section:</b> 17.5.1 [structure] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2012-03-08 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The front matter in clause 17 should clarify that postconditions will not hold if a 
standard library function exits via an exception. Postconditions or guarantees that 
apply when an exception is thrown (beyond the basic guarantee) are described in an 
"Exception safety" section.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2137"></a>2137. Misleadingly constrained post-condition in the presence of exceptions</h3>
<p><b>Section:</b> 28.8.3 [re.regex.assign] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-03-08 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#re.regex.assign">issues</a> in [re.regex.assign].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The post-conditions of <tt>basic_regex&lt;&gt;::assign</tt> 28.8.3 [re.regex.assign] p16 say:
</p>
<blockquote><p>
<span style="color:#C80000;font-weight:bold">If no exception is thrown,</span> <tt>flags()</tt> returns 
<tt>f</tt> and <tt>mark_count()</tt> returns the number of marked sub-expressions within the expression.
</p></blockquote>
<p>
The default expectation in the library is that post-conditions only hold, if there is no failure 
(see also <a href="lwg-active.html#2136">2136</a>), therefore the initial condition should be removed to prevent any
misunderstanding.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<blockquote><pre>
template &lt;class string_traits, class A&gt;
  basic_regex&amp; assign(const basic_string&lt;charT, string_traits, A&gt;&amp; s,
    flag_type f = regex_constants::ECMAScript);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-15- <i>Effects</i>: Assigns the regular expression contained in the string <tt>s</tt>, interpreted according 
the flags specified in <tt>f</tt>. If an exception is thrown, <tt>*this</tt> is unchanged.
<p/>
-16- <i>Postconditions</i>: <del>If no exception is thrown,</del> <tt>flags()</tt> returns <tt>f</tt> and 
<tt>mark_count()</tt> returns the number of marked sub-expressions within the expression.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="2138"></a>2138. <tt>atomic_flag::clear</tt> should not accept <tt>memory_order_consume</tt></h3>
<p><b>Section:</b> 29.7 [atomics.flag] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Ben Viglietta <b>Opened:</b> 2012-03-08 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#atomics.flag">active issues</a> in [atomics.flag].</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.flag">issues</a> in [atomics.flag].</p>
<p><b>View all issues with</b> <a href="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/2012/n3376.pdf">N3376</a> 29.7 [atomics.flag]&#47;7 says
this about <tt>atomic_flag::clear</tt>:
</p>
<blockquote><p>
<i>Requires</i>: The <tt>order</tt> argument shall not be <tt>memory_order_acquire</tt> or <tt>memory_order_acq_rel</tt>.
</p></blockquote>
<p>
In addition, <tt>memory_order_consume</tt> should be disallowed, since it doesn't meaningfully apply to store operations.  
It's already disallowed on the analogous <tt>atomic&lt;T&gt;::store</tt>. The proposed updated text would be:
</p>
<blockquote><p>
<i>Requires</i>: The <tt>order</tt> argument shall not be <ins><tt>memory_order_consume</tt>,</ins> 
<tt>memory_order_acquire</tt><ins>,</ins> or <tt>memory_order_acq_rel</tt>.
</p></blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<blockquote><pre>
void atomic_flag_clear(volatile atomic_flag *object) noexcept;
void atomic_flag_clear(atomic_flag *object) noexcept;
void atomic_flag_clear_explicit(volatile atomic_flag *object, memory_order order) noexcept;
void atomic_flag_clear_explicit(atomic_flag *object, memory_order order) noexcept;
void atomic_flag::clear(memory_order order = memory_order_seq_cst) volatile noexcept;
void atomic_flag::clear(memory_order order = memory_order_seq_cst) noexcept;
</pre><blockquote>
<p>
-7- <i>Requires</i>: The <tt>order</tt> argument shall not be <ins><tt>memory_order_consume</tt>,</ins> 
<tt>memory_order_acquire</tt><ins>, n</ins>or <tt>memory_order_acq_rel</tt>.
<p/>
-8- <i>Effects</i>: Atomically sets the value pointed to by <tt>object</tt> or by <tt>this</tt> to false. Memory is affected
according to the value of <tt>order</tt>.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="2139"></a>2139. What is a <em>user-defined</em> type?</h3>
<p><b>Section:</b> 17.6.4.2.1 [namespace.std], 19.5 [syserr], 20.6.7.1 [allocator.uses.trait], 20.8.9.1.1 [func.bind.isbind], X [func.bind.isplace], 20.8.12 [unord.hash], 20.9.7.6 [meta.trans.other], 22.3.1 [locale], 22.4.1.4 [locale.codecvt], 28.12.1.4 [re.regiter.incr] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Lo&iuml;c Joly <b>Opened:</b> 2012-03-08 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#namespace.std">active issues</a> in [namespace.std].</p>
<p><b>View all other</b> <a href="lwg-index.html#namespace.std">issues</a> in [namespace.std].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The expression "user-defined type" is used in several places in the standard, but I'm not sure what 
it means. More specifically, is a type defined in the standard library a user-defined type?
<p/>
From my understanding of English, it is not. From most of the uses of this term in the standard, it 
seem to be considered as user defined. In some places, I'm hesitant, e.g. 17.6.4.2.1 [namespace.std] p1:
</p>
<blockquote><p>
A program may add a template specialization for any standard library template to namespace <tt>std</tt> 
only if the declaration depends on a user-defined type and the specialization meets the standard library 
requirements for the original template and is not explicitly prohibited.
</p></blockquote>
<p>
Does it mean we are allowed to add in the namespace <tt>std</tt> a specialization for 
<tt>std::vector&lt;std::pair&lt;T, U&gt;&gt;</tt>, for instance?
<p/>
Additional remarks from the reflector discussion: The traditional meaning of user-defined types refers
to class types and enum types, but the library actually means here user-defined types that are not
(purely) library-provided. Presumably a new term - like <em>user-provided type</em> - should be introduced
and properly defined.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2140"></a>2140. Meaning of <tt>notify_all_at_thread_exit</tt> synchronization requirement?</h3>
<p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-03-06 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
<tt>notify_all_at_thread_exit</tt> has the following synchronization requirement:
</p>
<blockquote><p>
<i>Synchronization</i>: The call to <tt>notify_all_at_thread_exit</tt> and the completion of the destructors 
for all the current thread's variables of thread storage duration <em>synchronize with</em> (1.10 [intro.multithread]) 
calls to functions waiting on <tt>cond</tt>.
</p></blockquote>
<p>
The functions waiting on <tt>cond</tt> have already been called, otherwise they wouldn't be waiting. So how can a subsequent 
call to <tt>notify_all_at_thread_exit</tt> synchronize with them?
<p/>
Also, "synchronizes with" is a relationship between library calls (1.10 [intro.multithread]&#47;8), so it's not 
meaningful for completion of destructors for non-library objects. Presumably the intention wasn't so make library 
destructors special here.
</p>

<p><i>[2012-03-09 Jeffrey Yasskin comments:]</i></p>


<p>
I think the text should say that "<tt>notify_all_at_thread_exit</tt> and destructor calls are sequenced before
the <tt>lk.unlock()</tt>", and leave it at that, unless there's a funny implementation I haven't thought of.
</p>

<p><i>[2012-03-19 Hans Boehm comments:]</i></p>


<p>
I think the synchronization clause should just be replaced with (modulo wording tweaks):
<p/>
"The implied <tt>lk.unlock()</tt> call is sequenced after the destruction of all objects with thread storage duration 
associated with the current thread."
<p/>
as Jeffrey suggested.
<p/>
To use this correctly, the notifying thread has to essentially acquire the lock, set a variable indicating it's done, 
call <tt>notify_all_at_thread_exit()</tt>, while the waiting thread acquires the lock, and repeatedly waits on the 
cv until the variable is set, and then releases the lock.  That ensures that we have the proper synchronizes with 
relationship as a result of the lock.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol><li><p>Modify 30.5 [thread.condition] p8 as indicated:</p>

<blockquote>
<pre>
void notify_all_at_thread_exit(condition_variable&amp; cond, unique_lock&lt;mutex&gt; lk);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-8- <i>Synchronization</i>: <del>The call to <tt>notify_all_at_thread_exit</tt> and the completion of the destructors for
all the current thread's variables of thread storage duration synchronize with (1.10 [intro.multithread]) 
calls to functions waiting on <tt>cond</tt></del> <ins>The implied <tt>lk.unlock()</tt> call is sequenced after the 
destruction of all objects with thread storage duration associated with the current thread</ins>.
</p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2141"></a>2141. <tt>common_type</tt> trait produces reference types</h3>
<p><b>Section:</b> 20.9.7.6 [meta.trans.other] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2012-03-11 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The type computation of the <tt>common_type</tt> type trait is defined as
</p>
<blockquote><pre>
template &lt;class T, class U&gt;
 struct common_type&lt;T, U&gt; {
   typedef decltype(true ? declval&lt;T&gt;() : declval&lt;U&gt;()) type;
 };
</pre></blockquote>
<p>
This means that <tt>common_type&lt;int, int&gt;::type</tt> is <tt>int&amp;&amp;</tt>, because
</p>
<ul>
<li><tt>declval&lt;int&gt;()</tt> returns <tt>int&amp;&amp;</tt></li>
<li>The conditional operator returns an xvalue when its second and third operands have the same type 
and are both xvalues (5.16 [expr.cond] p4)</li>
<li><tt>decltype</tt> returns <tt>T&amp;&amp;</tt> when its expression is an xvalue (7.1.6.2 [dcl.type.simple] p4)</li>
</ul>
<p>
Users of <tt>common_type</tt> do not expect to get a reference type as the result; the expectation is that 
<tt>common_type</tt> will return a non-reference type to which all of the types can be converted.
<p/>
Daniel: In addition to that it should be noted that without such a fix the definition of <tt>std::unique_ptr</tt>'s
<tt>operator&lt;</tt> in 20.7.1.4 [unique.ptr.special] (around p4) is also broken: In the most typical case 
(with default deleter), the determination of the common pointer type <em>CT</em> will instantiate 
<tt>std::less&lt;<em>CT</em>&gt;</tt> which can now be <tt>std::less&lt;T*&amp;&amp;&gt;</tt>, which will
<em>not</em> be the specialization of pointer types that guarantess a total order.
<p/>
Given the historic constext of <tt>common_type</tt> original specification, the proper resolution to me
seems to be using <tt>std::decay</tt> instead of <tt>std::remove_reference</tt>: 
</p>
<blockquote><pre>
template &lt;class T, class U&gt;
struct common_type&lt;T, U&gt; {
  typedef <ins>typename decay&lt;</ins>decltype(true ? declval&lt;T&gt;() : declval&lt;U&gt;())<ins>&gt;::type</ins> type;
};
</pre></blockquote>
<p>
At that time rvalues had no identity in this construct and rvalues of non-class types have no cv-qualification.
With this change we would ensure that
</p>
<blockquote><pre>
common_type&lt;int, int&gt;::type == common_type&lt;const int, const int&gt;::type == int
</pre></blockquote>
<p>
Note that this harmonizes with the corresponding heterogenous case, which has already the exact same effect:
</p>
<blockquote><pre>
common_type&lt;int, long&gt;::type == common_type&lt;const int, const long&gt;::type == long
</pre></blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol><li><p>In 20.9.7.6 [meta.trans.other] p3, change the <tt>common_type</tt> definition to</p>
<blockquote><pre>
template &lt;class T, class U&gt;
struct common_type&lt;T, U&gt; {
  typedef <ins>typename decay&lt;</ins>decltype(true ? declval&lt;T&gt;() : declval&lt;U&gt;())<ins>&gt;::type</ins> type;
};
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="2142"></a>2142. <tt>packaged_task::operator()</tt> synchronization too broad?</h3>
<p><b>Section:</b> 30.6.9.1 [futures.task.members] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-03-12 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.task.members">active issues</a> in [futures.task.members].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.task.members">issues</a> in [futures.task.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to 30.6.9.1 [futures.task.members] p.18:
</p>
<blockquote><p>
[A] successful call to [<tt>packaged_task::</tt>]<tt>operator()</tt> <em>synchronizes with</em> 
a call to any member function of a <tt>future</tt> or <tt>shared_future</tt> object that shares 
the shared state of <tt>*this</tt>.
</p></blockquote>
<p>
This requires that the call to <tt>operator()</tt> synchronizes with calls to <tt>future::wait_for</tt>, 
<tt>future::wait_until</tt>, <tt>shared_future::wait_for</tt>, and <tt>shared_future::wait_until</tt>, 
even when these functions return because of a timeout.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2143"></a>2143. <tt>ios_base::xalloc</tt> should be thread-safe</h3>
<p><b>Section:</b> 27.5.3 [ios.base] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2012-03-14 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#ios.base">issues</a> in [ios.base].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The static function <tt>ios_base::xalloc()</tt> could be called from multiple threads and is not covered by 
17.6.4.10 [res.on.objects] and 17.6.5.9 [res.on.data.races]. Adding a thread-safety requirement 
should not impose a significant burden on implementations, as the function can be easily implemented with 
hopefully lock-free atomics.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>In 27.5.3.5 [ios.base.storage] add a new paragraph after paragraph 1:</p>

<blockquote><pre>
static int xalloc();
</pre><blockquote>
<p>
-1- <i>Returns</i>: <tt>index ++</tt>.
<p/>
<ins>-?- <i>Remarks</i>: Concurrent access to this function by multiple threads shall not result in a data 
race (1.10 [intro.multithread]).</ins>
</p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2144"></a>2144. Missing <tt>noexcept</tt> specification in <tt>type_index</tt></h3>
<p><b>Section:</b> 20.13 [type.index] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-03-18 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#type.index">issues</a> in [type.index].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The class type <tt>type_index</tt> is a thin wrapper of <tt>type_info</tt> to
adapt it as a valid associative container element. Similar to <tt>type_info</tt>, 
all member functions have an effective <tt>noexcept(true)</tt> specification, with the 
exception of <tt>hash_code()</tt> and <tt>name()</tt>. The actual effects of these
functions is a direct call to <tt>type_info</tt>'s <tt>hash_code()</tt> and <tt>name</tt> 
function, but according to 18.7 [support.rtti] these are both <tt>noexcept</tt>
functions, so there is no reason for not declaring them as <tt>noexcept</tt>, too. In fact,
one of the suggested changes of the original proposing paper 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2530.html">N2530</a>
specifically was to ensure that <tt>type_info</tt> would get a <tt>hash_code()</tt>
function that guarantees not to throw exceptions (during that time the <tt>hash</tt>
requirements did not allow to exit with an exception). From this we can conclude that
<tt>type_index::hash_code()</tt> was intended to be nothrow.
<p/>
It seems both consistent and technically simply to require these functions to be <tt>noexcept</tt>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Modify the class <tt>type_index</tt> synopsis, 20.13.2 [type.index.overview] as indicated:</p>

<blockquote><pre>
namespace std {
  class type_index {
  public:
    type_index(const type_info&amp; rhs) noexcept;
    bool operator==(const type_index&amp; rhs) const noexcept;
    bool operator!=(const type_index&amp; rhs) const noexcept;
    bool operator&lt; (const type_index&amp; rhs) const noexcept;
    bool operator&lt;= (const type_index&amp; rhs) const noexcept;
    bool operator&gt; (const type_index&amp; rhs) const noexcept;
    bool operator&gt;= (const type_index&amp; rhs) const noexcept;
    size_t hash_code() const <ins>noexcept</ins>;
    const char* name() const <ins>noexcept</ins>;
  private:
    const type_info* target; <i>// exposition only</i>
    <i>// Note that the use of a pointer here, rather than a reference,</i>
    <i>// means that the default copy&#47;move constructor and assignment</i>
    <i>// operators will be provided and work as expected.</i>
  };
}
</pre></blockquote>
</li>
</ol>

<ol>
<li><p>Modify the prototype definitions in 20.13.3 [type.index.members] as indicated:</p>

<blockquote><pre>
size_t hash_code() const <ins>noexcept</ins>;
</pre><blockquote>
<p>
-8- <i>Returns</i>: <tt>target->hash_code()</tt>
</p>
</blockquote>
<pre>
const char* name() const <ins>noexcept</ins>;
</pre><blockquote>
<p>
-9- <i>Returns</i>: <tt>target->name()</tt>
</p>
</blockquote>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2145"></a>2145. <tt>error_category</tt> default constructor</h3>
<p><b>Section:</b> 19.5.1 [syserr.errcat] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2012-03-21 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#syserr.errcat">issues</a> in [syserr.errcat].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Should <tt>error_category</tt> have a default constructor?
<p/>
If you look at the synopsis in 19.5.1.1 [syserr.errcat.overview], it appears the answer is no. There 
is no default constructor declared and there is another constructor declared (which should inhibit a default 
constructor).
<p/>
However in paragraph 1 of the same section, descriptive text says:
</p>
<blockquote><p>
Classes may be derived from <tt>error_category</tt> to support categories of errors in addition to those 
defined in this International Standard.
</p></blockquote>
<p>
How shall classes derived from <tt>error_category</tt> construct their base?
<p/>
Jonathan Wakely: In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a> 
<tt>error_category</tt> was default-constructible. That is still the case in 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>, because no other 
constructor is declared. Then later <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422.htm">N2422</a> 
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422.htm#Issue6">issue 6</a>) declares 
the copy constructor as deleted, but doesn't add a default constructor, causing it to be no longer
default-constructible. That looks like an oversight to me, and I think there should be a public default 
constructor.
<p/>
Daniel: A default-constructor indeed should be provided to allow user-derived classes as described by the
standard. I suggest this one to be both <tt>noexcept</tt> and <tt>constexpr</tt>. The latter allows
user-derived non-abstract classes to take advantage of the special <em>constant initialization</em> rule
of 3.6.2 [basic.start.init] p2 b2 for objects with static (or thread) storage duration in namespace 
scope. Note that a <tt>constexpr</tt> constructor is feasible here, even though there exists a non-trivial
destructor and even though <tt>error_category</tt> is not a literal type (see <tt>std::mutex</tt> for a similar
design choice).
<p/>
In addition to that the proposed resolution fixes another minor glitch: According to 17.5.2.2 [functions.within.classes]
virtual destructors require a semantics description. 
<p/>
Alberto Ganesh Barbati: I would suggest to remove <tt>=default</tt> from the constructor instead. 
Please consider that defaulting a constructor or destructor may actually define them as deleted under certain 
conditions (see 12.1 [class.ctor]&#47;5 and 12.4 [class.dtor]&#47;5). Removing <tt>=default</tt> 
is easier than providing wording to ensures that such conditions do not occur.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Modify the class <tt>error_category</tt> synopsis, 19.5.1.1 [syserr.errcat.overview] as indicated:
<em>[Drafting note: According to the general 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf"><tt>noexcept</tt> library guidelines</a> 
destructors should not have any explicit exception specification. This destructor was overlooked during the paper
analysis &mdash; end note]</em>
</p>

<blockquote><pre>
namespace std {
  class error_category {
  public:
    <ins>constexpr error_category() noexcept;</ins>
    virtual ~error_category() <del>noexcept</del>;
    error_category(const error_category&amp;) = delete;
    error_category&amp; operator=(const error_category&amp;) = delete;
    virtual const char* name() const noexcept = 0;
    virtual error_condition default_error_condition(int ev) const noexcept;
    virtual bool equivalent(int code, const error_condition&amp; condition) const noexcept;
    virtual bool equivalent(const error_code&amp; code, int condition) const noexcept;
    virtual string message(int ev) const = 0;
    bool operator==(const error_category&amp; rhs) const noexcept;
    bool operator!=(const error_category&amp; rhs) const noexcept;
    bool operator&lt;(const error_category&amp; rhs) const noexcept;
  };
}
</pre></blockquote>
</li>

<li><p>Before 19.5.1.2 [syserr.errcat.virtuals] p1 insert a new prototype description as indicated:</p>

<blockquote><pre>
<ins>virtual ~error_category();</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Effects</i>: Destroys an object of class <tt>error_category</tt>.</ins>
</p>
</blockquote>
</blockquote>

</li>

<li><p>Before 19.5.1.3 [syserr.errcat.nonvirtuals] p1 insert a new prototype description as indicated:</p>

<blockquote><pre>
<ins>constexpr error_category() noexcept;</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Effects</i>: Constructs an object of class <tt>error_category</tt>.</ins>
</p>
</blockquote>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2146"></a>2146. Are reference types <tt>Copy</tt>&#47;<tt>Move-Constructible</tt>&#47;<tt>Assignable</tt> or <tt>Destructible</tt>?</h3>
<p><b>Section:</b> 17.6.3.1 [utility.arg.requirements] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2012-03-23 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to 17.6.3.1 [utility.arg.requirements] p1
</p>
<blockquote><p>
The template definitions in the C++ standard library refer to various named requirements whose details are set out in 
tables 1724. In these tables, <tt>T</tt> is an object or reference type to be supplied by a C++ program instantiating 
a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are values of type (possibly <tt>const</tt>) <tt>T</tt>; <tt>s</tt> 
and <tt>t</tt> are modifiable lvalues of type <tt>T</tt>; <tt>u</tt> denotes an identifier; <tt>rv</tt> is an rvalue of 
type <tt>T</tt>; and <tt>v</tt> is an lvalue of type (possibly <tt>const</tt>) <tt>T</tt> or an rvalue of type <tt>const T</tt>.
</p></blockquote>
<p>
Is it really intended that <tt>T</tt> may be a reference type? If so, what should <tt>a</tt>, <tt>b</tt>, <tt>c</tt>, 
<tt>s</tt>, <tt>t</tt>, <tt>u</tt>, <tt>rv</tt>, and <tt>v</tt> mean? For example, are "<tt>int &amp;</tt>" and 
"<tt>int &amp;&amp;</tt>" <tt>MoveConstructible</tt>?
<p/>
As far as I understand, we can explicitly specify template arguments for <tt>std::swap</tt> and <tt>std::for_each</tt>. 
Can we use reference types there?
</p>
<ol>
<li>
<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;utility&gt;

int main()
{
  int x = 1;
  int y = 2;
  std::swap&lt;<span style="color:#C80000;font-weight:bold">int &amp;&amp;</span>&gt;(x, y); // <em>undefined?</em>
  std::cout &lt;&lt; x &lt;&lt; " " &lt;&lt; y &lt;&lt; std::endl;
}
</pre></blockquote>
</li>
<li>
<blockquote><pre>
#include &lt;algorithm&gt;
#include &lt;iostream&gt;
#include &lt;iterator&gt;
#include &lt;utility&gt;

struct F
{
  void operator()(int n)
  {
    std::cout &lt;&lt; n &lt;&lt; std::endl;
    ++count;
  }
  int count;
} f;

int main()
{
  int arr[] = { 1, 2, 3 };
  auto&amp;&amp; result = std::for_each&lt;int *, <span style="color:#C80000;font-weight:bold">F &amp;&amp;</span>&gt;( // <em>undefined?</em>
    std::begin(arr),
    std::end(arr),
    std::move(f));
  std::cout &lt;&lt; "count: " &lt;&lt; result.count &lt;&lt; std::endl;
}
</pre></blockquote>
</li>
</ol>
<p>
Are these forms of usage well-defined?
<p/>
Let's also consider the following constructor of <tt>std::thread</tt>:
</p>
<blockquote><pre>
template &lt;class F, class ...Args&gt;
explicit thread(F&amp;&amp; f, Args&amp;&amp;... args);
</pre><blockquote>
<p>
<i>Requires</i>: <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall satisfy the <tt>MoveConstructible</tt> requirements.
</p>
</blockquote></blockquote>
<p>
When the first argument of this constructor is an lvalue (e.g. a name of a global function), template argument for <tt>F</tt> 
is deduced to be lvalue reference type. What should "<tt>MoveConstructible</tt>" mean with regard to an lvalue reference 
type? Maybe the wording should say that <tt>std::decay&lt;F&gt;::type</tt> and each <tt>std::decay&lt;Ti&gt;::type</tt> (where 
<tt>Ti</tt> is an arbitrary item in <tt>Args</tt>) shall satisfy the <tt>MoveConstructible</tt> requirements?
</p>



<p><b>Proposed resolution:</b></p>






<hr>
<h3><a name="2147"></a>2147. Unclear hint type in <tt>Allocator</tt>'s <tt>allocate</tt> function</h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-03-05 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to Table 28 &mdash; "Allocator requirements", the expression
</p>
<blockquote><pre>
a.allocate(n, u)
</pre></blockquote>
<p>
expects as second argument a value <tt>u</tt> that is described in Table 27 as:
</p>
<blockquote><p>
a value of type <tt>YY::const_pointer</tt> obtained by calling <tt>YY::allocate</tt>, or else <tt>nullptr</tt>.
</p></blockquote>
<p>
This description leaves it open, whether or whether not a value of type <tt>YY::const_void_pointer</tt> is
valid or not. The corresponding wording in C++03 is nearly the same, but in C++03 there did not exist the concept of
a general <tt>void_pointer</tt> for allocators. There is some evidence for support of void pointers because
the general <tt>allocator_traits</tt> template declares
</p>
<blockquote><pre>
static pointer allocate(Alloc&amp; a, size_type n, const_void_pointer hint);
</pre></blockquote>
<p>
and the corresponding function for <tt>std::allocator&lt;T&gt;</tt> is declared as: 
</p>
<blockquote><pre>
pointer allocate(size_type, allocator&lt;void&gt;::const_pointer hint = 0);
</pre></blockquote>
<p>
As an additional minor wording glitch (especially when comparing with the <tt>NullablePointer</tt> requirements imposed on
<tt>const_pointer</tt> and <tt>const_void_pointer</tt>), the wording seems to exclude lvalues of type
<tt>std::nullptr_t</tt>, which looks like an unwanted artifact to me.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change Table 27 &mdash; "Descriptive variable definitions" in 17.6.3.5 [allocator.requirements]:</p>

<table border="1">
<caption>Table 27 &mdash; Descriptive variable definitions</caption>
<tr>
<th>Variable</th>
<th>Definition</th>
</tr> 

<tr>
<td>
<tt>u</tt>
</td>
<td>
a value of type <del><tt>YY::const_pointer</tt> obtained by calling <tt>YY::allocate</tt>, or else 
<tt>nullptr</tt></del><ins><tt>XX::const_void_pointer</tt> obtained by conversion from a result 
value of <tt>YY::allocate</tt>, or else a value of type (possibly const) <tt>std::nullptr_t</tt></ins>.
</td>
</tr>

</table>

</li>
</ol>






<hr>
<h3><a name="2148"></a>2148. Hashing enums should be supported directly by <tt>std::hash</tt></h3>
<p><b>Section:</b> 20.8.12 [unord.hash] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2012-04-10 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3333.html">paper</a> 
proposes various hashing improvements. What it doesn't mention is hashing of
enums; enums are integral types, and users expect them to have built-in hashing
support, rather than having to convert enums to ints for uses with
unordered containers and other uses of hashes. Daniel Kr&uuml;gler explains in c++std-lib-32412
that this is not achievable with a SFINAEd hash specialization because it would require
a partial specialization with a type parameter and a non-type parameter with a
default argument, which is currently not allowed, and hence the fixes in N3333 should be
adopted instead.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2149"></a>2149. Concerns about 20.8/5</h3>
<p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Scott Meyers <b>Opened:</b> 2012-02-15 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#function.objects">active issues</a> in [function.objects].</p>
<p><b>View all other</b> <a href="lwg-index.html#function.objects">issues</a> in [function.objects].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
20.8 [function.objects] p5 says:
</p>
<blockquote><p>
To enable adaptors and other components to manipulate function objects that take one or two arguments
it is required that the function objects correspondingly provide typedefs <tt>argument_type</tt> and 
<tt>result_type</tt> for function objects that take one argument and <tt>first_argument_type</tt>, 
<tt>second_argument_type</tt>, and <tt>result_type</tt> for function objects that take two arguments.
</p></blockquote>
<p>
I have two concerns about this paragraph.  First, the wording appears to prescribe a requirement for all 
function objects in valid C++ programs, but it seems unlikely that that is the intent.  As such, the scope 
of the requirement is unclear.  For example, there is no mention of these typedefs in the specification for 
closures (5.1.2), and Daniel Kr&uuml;gler has explained in the thread at 
<a href="http://tinyurl.com/856plkn">http://tinyurl.com/856plkn</a> that conforming implementations can 
detect the difference between closures with and without these typedefs.  (Neither gcc 4.6 nor VC10 appear 
to define typedefs such as <tt>result_type</tt> for closure types. I have not tested other compilers.)
<p/>
Second, the requirement appears to be unimplementable in some cases, notably for function objects returned 
from <tt>std::bind</tt>, as Howard Hinnant explains in the thread at <a href="http://tinyurl.com/6q5bos4">http://tinyurl.com/6q5bos4</a>.
<p/>
From what I can tell, the standard already defines which adaptability typedefs must be provided by various 
kinds of function objects in the specifications for those objects.  Examples include the function objects 
specified in 20.8.3 [refwrap]-20.8.8 [negators]. I therefore suggest that 
20.8 [function.objects]&#47;5 simply be removed from the standard. I don't think it adds anything 
except opportunities for confusion.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<p>Remove 20.8 [function.objects] p5:</p>

<blockquote><p><del>
To enable adaptors and other components to manipulate function objects that take one or two arguments
it is required that the function objects correspondingly provide typedefs <tt>argument_type</tt> and 
<tt>result_type</tt> for function objects that take one argument and <tt>first_argument_type</tt>, 
<tt>second_argument_type</tt>, and <tt>result_type</tt> for function objects that take two arguments.
</del></p></blockquote>





<hr>
<h3><a name="2150"></a>2150. Unclear specification of <tt>find_end</tt></h3>
<p><b>Section:</b> 25.2.6 [alg.find.end] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2012-03-28 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
25.2.6 [alg.find.end] describes the behavior of find_end as returning:
</p>
<blockquote><p>
The last iterator <tt>i</tt> in the range <tt>[first1,last1 - (last2 - first2))</tt> such that for any 
nonnegative integer <tt>n &lt; (last2 - first2)</tt>, the following corresponding conditions hold: 
<tt>*(i + n) == *(first2 + n), pred(*(i + n), *(first2 + n)) != false</tt>.
</p></blockquote>
<p>
Does "for any" here mean "for every" or "there exists a"?  I think it means the former, but it could be 
interpreted either way.
<p/>
Daniel: The same problem exists for the following specifications from Clause 25 [algorithms]:
</p>
<ol>
<li>25.2.13 [alg.search] p2 and p6</li>
<li>25.3.10 [alg.reverse] p4</li>
<li>25.3.13 [alg.partitions] p5 and p9</li>
<li>25.4 [alg.sorting] p5</li>
<li>25.4.2 [alg.nth.element] p1</li>
<li>25.4.3.1 [lower.bound] p2</li>
<li>25.4.3.2 [upper.bound] p2</li>
<li>25.4.7 [alg.min.max] p21 and p23</li>
</ol>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li>
<p>Change 25.2.6 [alg.find.end] p2 as indicated:</p>

<blockquote><pre>
template&lt;class ForwardIterator1, class ForwardIterator2&gt;
ForwardIterator1 
find_end(ForwardIterator1 first1, ForwardIterator1 last1,
         ForwardIterator2 first2, ForwardIterator2 last2);
template&lt;class ForwardIterator1, class ForwardIterator2,
         class BinaryPredicate&gt;
ForwardIterator1
find_end(ForwardIterator1 first1, ForwardIterator1 last1,
         ForwardIterator2 first2, ForwardIterator2 last2,
         BinaryPredicate pred);
</pre><blockquote><p>
[&hellip;]
<p/>
-2- <i>Returns</i>: The last iterator <tt>i</tt> in the range <tt>[first1,last1 - (last2 - first2))</tt> such 
that for <del>any</del><ins>every</ins> nonnegative integer <tt>n &lt; (last2 - first2)</tt>, the following 
corresponding conditions hold: <tt>*(i + n) == *(first2 + n), pred(*(i + n), *(first2 + n)) != false</tt>.
Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is empty or if no such iterator is found.
</p></blockquote></blockquote>
</li>

<li>
<p>Change 25.2.13 [alg.search] p2 and p6 as indicated:</p>

<blockquote><pre>
template&lt;class ForwardIterator1, class ForwardIterator2&gt;
ForwardIterator1
search(ForwardIterator1 first1, ForwardIterator1 last1,
       ForwardIterator2 first2, ForwardIterator2 last2);
template&lt;class ForwardIterator1, class ForwardIterator2,
         class BinaryPredicate&gt;
ForwardIterator1
search(ForwardIterator1 first1, ForwardIterator1 last1,
       ForwardIterator2 first2, ForwardIterator2 last2,
       BinaryPredicate pred);
</pre><blockquote><p>
[&hellip;]
<p/>
-2- <i>Returns</i>: The first iterator <tt>i</tt> in the range <tt>[first1,last1 - (last2-first2))</tt> 
such that for <del>any</del><ins>every</ins> nonnegative integer <tt>n</tt> less than <tt>last2 - first2</tt> 
the following corresponding conditions hold: <tt>*(i + n) == *(first2 + n), pred(*(i + n), *(first2 + n)) != false</tt>. 
Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is empty, otherwise returns <tt>last1</tt> if no such iterator 
is found.
</p></blockquote></blockquote>
<p>
[&hellip;]
</p>
<blockquote><pre>
template&lt;class ForwardIterator, class Size, class T&gt;
ForwardIterator
search_n(ForwardIterator first, ForwardIterator last, Size count,
         const T&amp; value);
template&lt;class ForwardIterator, class Size, class T,
         class BinaryPredicate&gt;
ForwardIterator
search_n(ForwardIterator first, ForwardIterator last, Size count,
         const T&amp; value, BinaryPredicate pred);
</pre><blockquote><p>
[&hellip;]
<p/>
-6- <i>Returns</i>: The first iterator <tt>i</tt> in the range <tt>[first,last-count)</tt> such that 
for <del>any</del><ins>every</ins> non-negative integer <tt>n</tt> less than <tt>count</tt> the following 
corresponding conditions hold: <tt>*(i + n) == value, pred(*(i + n),value) != false</tt>. Returns <tt>last</tt> 
if no such iterator is found.
</p></blockquote></blockquote>
</li>

<li>
<p>Change 25.3.10 [alg.reverse] p4 as indicated:</p>

<blockquote><pre>
template&lt;class BidirectionalIterator, class OutputIterator&gt;
OutputIterator
reverse_copy(BidirectionalIterator first,
             BidirectionalIterator last, OutputIterator result);
</pre><blockquote><p>
[&hellip;]
<p/>
-4- <i>Effects</i>: Copies the range <tt>[first,last)</tt> to the range <tt>[result,result+(last-first))</tt> 
such that for <del>any</del><ins>every</ins> non-negative integer <tt>i &lt; (last - first)</tt> the following 
assignment takes place: <tt>*(result + (last - first) - i) = *(first + i)</tt>.
</p></blockquote></blockquote>
</li>

<li>
<p>Change 25.3.13 [alg.partitions] p5 and p9 as indicated:</p>

<blockquote><pre>
template&lt;class ForwardIterator, class Predicate&gt;
ForwardIterator
partition(ForwardIterator first,
          ForwardIterator last, Predicate pred);
</pre><blockquote><p>
[&hellip;]
<p/>
-5- <i>Returns</i>: An iterator <tt>i</tt> such that for <del>any</del><ins>every</ins> iterator <tt>j</tt> 
in the range <tt>[first,i) pred(*j) != false</tt>, and for <del>any</del><ins>every</ins> iterator <tt>k</tt> 
in the range <tt>[i,last), pred(*k) == false</tt>.
</p></blockquote></blockquote>
<p>
[&hellip;]
</p>
<blockquote><pre>
template&lt;class BidirectionalIterator, class Predicate&gt;
BidirectionalIterator
stable_partition(BidirectionalIterator first,
                 BidirectionalIterator last, Predicate pred);
</pre><blockquote><p>
[&hellip;]
<p/>
-9- <i>Returns</i>: An iterator <tt>i</tt> such that for <del>any</del><ins>every</ins> iterator <tt>j</tt> 
in the range <tt>[first,i), pred(*j) != false</tt>, and for <del>any</del><ins>every</ins> iterator <tt>k</tt> 
in the range <tt>[i,last), pred(*k) == false</tt>. The relative order of the elements in both groups is preserved.
</p></blockquote></blockquote>
</li>

<li>
<p>Change 25.4 [alg.sorting] p5 as indicated:</p>

<blockquote><p>
-5- A sequence is sorted with respect to a comparator <tt>comp</tt> if for <del>any</del><ins>every</ins> iterator 
<tt>i</tt> pointing to the sequence and <del>any</del><ins>every</ins> non-negative integer <tt>n</tt> such that 
<tt>i + n</tt> is a valid iterator pointing to an element of the sequence, <tt>comp(*(i + n), *i) == false</tt>.
</p></blockquote>
</li>

<li>
<p>Change 25.4.2 [alg.nth.element] p1 as indicated:</p>

<blockquote><pre>
template&lt;class RandomAccessIterator&gt;
void nth_element(RandomAccessIterator first, RandomAccessIterator nth,
                 RandomAccessIterator last);
template&lt;class RandomAccessIterator, class Compare&gt;
void nth_element(RandomAccessIterator first, RandomAccessIterator nth,
                 RandomAccessIterator last, Compare comp);
</pre><blockquote><p>
-1- After <tt>nth_element</tt> the element in the position pointed to by <tt>nth</tt> is the element that would 
be in that position if the whole range were sorted. Also for <del>any</del><ins>every</ins> iterator <tt>i</tt> 
in the range <tt>[first,nth)</tt> and <del>any</del><ins>every</ins> iterator <tt>j</tt> in the range 
<tt>[nth,last)</tt> it holds that: <tt>!(*i &gt; *j)</tt> or <tt>comp(*j, *i) == false</tt>. 
</p></blockquote></blockquote>
</li>

<li>
<p>Change 25.4.3.1 [lower.bound] p2 as indicated:</p>

<blockquote><pre>
template&lt;lass ForwardIterator, class T&gt;
ForwardIterator
lower_bound(ForwardIterator first, ForwardIterator last,
            const T&amp; value);
template&lt;class ForwardIterator, class T, class Compare&gt;
ForwardIterator
lower_bound(ForwardIterator first, ForwardIterator last,
            const T&amp; value, Compare comp);
</pre><blockquote><p>
[&hellip;]
<p/>
-2- <i>Returns</i>: The furthermost iterator <tt>i</tt> in the range <tt>[first,last]</tt> such that for 
<del>any</del><ins>every</ins> iterator <tt>j</tt> in the range <tt>[first,i)</tt> the following corresponding 
conditions hold: <tt>*j &lt; value</tt> or <tt>comp(*j, value) != false</tt>.
</p></blockquote></blockquote>
</li>

<li>
<p>Change 25.4.3.2 [upper.bound] p2 as indicated:</p>

<blockquote><pre>
template&lt;lass ForwardIterator, class T&gt;
ForwardIterator
upper_bound(ForwardIterator first, ForwardIterator last,
            const T&amp; value);
template&lt;class ForwardIterator, class T, class Compare&gt;
ForwardIterator
upper_bound(ForwardIterator first, ForwardIterator last,
            const T&amp; value, Compare comp);
</pre><blockquote><p>
[&hellip;]
<p/>
-2- <i>Returns</i>: The furthermost iterator <tt>i</tt> in the range <tt>[first,last]</tt> such that for 
<del>any</del><ins>every</ins> iterator <tt>j</tt> in the range <tt>[first,i)</tt> the following corresponding 
conditions hold: <tt>!(value &lt; *j)</tt> or <tt>comp(value, *j) == false</tt>.
</p></blockquote></blockquote>
</li>

<li>
<p>Change 25.4.7 [alg.min.max] p21 and p23 as indicated:</p>

<blockquote><pre>
template&lt;class ForwardIterator&gt;
ForwardIterator min_element(ForwardIterator first, ForwardIterator last);
template&lt;class ForwardIterator, class Compare&gt;
ForwardIterator min_element(ForwardIterator first, ForwardIterator last,
                            Compare comp);
</pre><blockquote><p>
-21- <i>Returns</i>: The first iterator <tt>i</tt> in the range <tt>[first,last)</tt> such that for 
<del>any</del><ins>every</ins> iterator <tt>j</tt> in the range <tt>[first,last)</tt> the following 
corresponding conditions hold: <tt>!(*j &lt; *i)</tt> or <tt>comp(*j, *i) == false</tt>. Returns 
<tt>last</tt> if <tt>first == last</tt>.
</p></blockquote></blockquote>
<p>
[&hellip;]
</p>
<blockquote><pre>
template&lt;class ForwardIterator&gt;
ForwardIterator max_element(ForwardIterator first, ForwardIterator last);
template&lt;class ForwardIterator, class Compare&gt;
ForwardIterator max_element(ForwardIterator first, ForwardIterator last,
                            Compare comp);
</pre><blockquote><p>
-23- <i>Returns</i>: The first iterator <tt>i</tt> in the range <tt>[first,last)</tt> such that for 
<del>any</del><ins>every</ins> iterator <tt>j</tt> in the range <tt>[first,last)</tt> the following 
corresponding conditions hold: <tt>!(*i &lt; *j)</tt> or <tt>comp(*i, *j) == false</tt>. Returns 
<tt>last</tt> if <tt>first == last</tt>.
</p></blockquote></blockquote>
</li>

</ol>






<hr>
<h3><a name="2151"></a>2151. <tt>basic_string&lt;&gt;::swap</tt> semantics ignore allocators</h3>
<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Robert Shearer <b>Opened:</b> 2012-04-13 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#string.require">active issues</a> in [string.require].</p>
<p><b>View all other</b> <a href="lwg-index.html#string.require">issues</a> in [string.require].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In C++11, <tt>basic_string</tt> is not described as a "container", and is not governed by the allocator-aware 
container semantics described in sub-clause 23.2 [container.requirements]; as a result, and 
requirements or contracts for the <tt>basic_string</tt> interface must be documented in Clause 
21 [strings].
<p/>
Sub-clause 21.4.6.8 [string::swap] defines the <tt>swap</tt> member function with no requirements, and
with guarantees to execute in constant time without throwing. Fulfilling such a contract is not reasonable 
in the presence of unequal non-propagating allocators.
<p/>
In contrast, 23.2.1 [container.requirements.general] p7 declares the behavior of member <tt>swap</tt> 
for containers with unequal non-propagating allocators to be undefined.
<p/>
Resolution proposal:
<p/>
Additional language from Clause 23 [containers] should probably be copied to Clause 
21 [strings]. I will refrain from an exactly recommendation, however, as I am raising further
issues related to the language in Clause 23 [containers].
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2152"></a>2152. Instances of standard container types are not swappable</h3>
<p><b>Section:</b> 17.6.3.2 [swappable.requirements], 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Robert Shearer <b>Opened:</b> 2012-04-13 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#swappable.requirements">active issues</a> in [swappable.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#swappable.requirements">issues</a> in [swappable.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Sub-clause 17.6.3.2 [swappable.requirements] defines two notions of swappability: a binary version defining
when two objects are <em>swappable with</em> one another, and a unary notion defining whether an object is 
<em>swappable</em> (without qualification), with the latter definition requiring that the object satisfy the 
former with respect to all values of the same type.
<p/>
Let <tt>T</tt> be a container type based on a non-propagating allocator whose instances do not necessarily 
compare equal. Then sub-clause 23.2.1 [container.requirements.general] p7 implies that no object <tt>t</tt> 
of type <tt>T</tt> is swappable (by the unary definition).
<p/>
Throughout the standard it is the unary definition of "swappable" that is listed as a requirement (with the 
exceptions of 20.2.2 [utility.swap] p4, 20.3.2 [pairs.pair] p31, 20.4.2.3 [tuple.swap] p2, 
25.3.3 [alg.swap] p2, and 25.3.3 [alg.swap] p6, which use the binary definition). This renders 
many of the mutating sequence algorithms of sub-clause 25.3 [alg.modifying.operations], for example, 
inapplicable to sequences of standard container types, even where every element of the sequence is swappable 
with every other.
<p/>
Note that this concern extends beyond standard containers to all future allocator-based types.
<p/>
Resolution proposal:
<p/>
I see two distinct straightforward solutions:
</p>
<ol style="list-style-type:lower-roman">
<li>Modify the requirements of algorithms from sub-clause 25.3 [alg.modifying.operations], and all other
places that reference the unary "swappable" definition, to instead use the binary "swappable with" definition 
(over a domain appropriate to the context). The unary definition of "swappable" could then be removed from the 
standard.
</li>
<li>Modify sub-clause 23.2.1 [container.requirements.general] such that objects of standard container types 
are "swappable" by the unary definition.
</li>
</ol>
<p>
I favor the latter solution, for reasons detailed in the following issue.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2153"></a>2153. Narrowing of the non-member <tt>swap</tt> contract</h3>
<p><b>Section:</b> 20.2.2 [utility.swap], 17.6.3.2 [swappable.requirements], 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Robert Shearer <b>Opened:</b> 2012-04-13 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Sub-clause 20.2.2 [utility.swap] defines a non-member 'swap' function with defined behavior for
all <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> types. It does not guarantee
constant-time complexity or <tt>noexcept</tt> in general, however this definition does
render all objects of <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> type swappable
(by the unary definition of sub-clause 17.6.3.2 [swappable.requirements]) in the absence of 
specializations or overloads.
<p/>
The overload of the non-member <tt>swap</tt> function defined in Table 96, however,
defines semantics incompatible with the generic non-member <tt>swap</tt> function,
since it is defined to call a member <tt>swap</tt> function whose semantics are
undefined for some values of <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> types.
<p/>
The obvious (perhaps naive) interpretation of sub-clause 17.6.3.2 [swappable.requirements] is as a guide to
the "right" semantics to provide for a non-member <tt>swap</tt> function (called in
the context defined by 17.6.3.2 [swappable.requirements] p3) in order to provide interoperable
user-defined types for generic programming. The standard container types don't follow these guidelines.
<p/>
More generally, the design in the standard represents a classic example of "contract narrowing". It 
is entirely reasonable for the contract of a particular <tt>swap</tt> overload to provide <em>more</em> 
guarantees, such as constant-time execution and <tt>noexcept</tt>, than are provided by the <tt>swap</tt> 
that is provided for any <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> types, but it is <em>not</em> 
reasonable for such an overload to fail to live up to the guarantees it provides for general types when 
it is applied to more specific types. Such an overload or specialization in generic programming is akin 
to an override of an inherited virtual function in OO programming: violating a superclass contract in a
subclass may be legal from the point of view of the language, but it is poor design and can easily lead 
to errors. While we cannot prevent user code from providing overloads that violate the more general 
<tt>swap</tt> contract, we can avoid doing so within the library itself.
<p/>
My proposed resolution is to draw a sharp distinction between member <tt>swap</tt> functions, which provide 
optimal performance but idiosyncratic contracts, and non-member <tt>swap</tt> functions, which should always 
fulfill at least the contract of 20.2.2 [utility.swap] and thus render objects swappable. The member 
<tt>swap</tt> for containers with non-propagating allocators, for example, would offer constant-time
guarantees and <tt>noexcept</tt> but would only offer defined behavior for values with allocators that compare 
equal; non-member <tt>swap</tt> would test allocator equality and then dispatch to either member <tt>swap</tt> or 
<tt>std::swap</tt> depending on the result, providing defined behavior for all values (and rendering the type
"swappable"), but offering neither the constant-time nor the <tt>noexcept</tt> guarantees.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2154"></a>2154. What exactly does compile-time complexity imply?</h3>
<p><b>Section:</b> 26.5.1.3 [rand.req.urng] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> John Salmon <b>Opened:</b> 2012-04-26 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The expressions <tt>G::min()</tt> and <tt>G::max()</tt> in Table 116 in 26.5.1.3 [rand.req.urng] are specified 
as having "compile-time" complexity.
<p/>
It is not clear what, exactly, this requirement implies.  If a URNG has a method:
</p>
<blockquote><pre>
static int min();
</pre></blockquote>
<p>
then is the method required to have a <tt>constexpr</tt> qualifier?  I believe the standard would benefit from 
clarification of this point.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2155"></a>2155. Macro <tt>__bool_true_false_are_defined</tt> should be removed</h3>
<p><b>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2012-04-30 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#support.runtime">active issues</a> in [support.runtime].</p>
<p><b>View all other</b> <a href="lwg-index.html#support.runtime">issues</a> in [support.runtime].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Since C99, the C standard describes a macro named  <tt>__bool_true_false_are_defined</tt>.
<p/>
In the process of harmonizing C++11 with C99, this name became part of the C++ standard.
<p/>
I propose that all mention of this name should be removed from the C and C++ standards.
<p/>
Here's the problem: The name was originally proposed as a transition tool, so that the headers for a 
project could contain lines like the following.
</p>
<blockquote><pre>
#if !defined(__bool_true_false_are_defined)
#define bool int /* or whatever */
#define true 1
#define false 0
#endif
</pre></blockquote>
<p>
Then when the project was compiled by a "new" compiler that implemented <tt>bool</tt> as defined by the 
evolving C++98 or C99 standards, those lines would be skipped; but when compiled by an "old" compiler that 
didn't yet provide <tt>bool</tt>, <tt>true</tt>, and <tt>false</tt>, then the <tt>#define</tt>'s would provide a
simulation that worked for most purposes.
<p/>
It turns out that there is an unfortunate ambiguity in the name.  One interpretation is as shown above, but 
a different reading says "bool, true, and false are #define'd", i.e. that the meaning of the macro is to
assert that these names are macros (not built-in) ... which is true in C, but not in C++.
<p/>
In C++11, the name appears in parentheses followed by a stray period, so
some editorial change is needed in any event:
<p/>
18.10 [support.runtime] para 1:
</p>
<blockquote><p>
Headers <tt>&lt;csetjmp&gt;</tt> (nonlocal jumps), <tt>&lt;csignal&gt;</tt> (signal handling), <tt>&lt;cstdalign&gt;</tt> 
(alignment), <tt>&lt;cstdarg&gt;</tt> (variable arguments), <tt>&lt;cstdbool&gt;</tt> (<tt>__bool_true_false_are_defined</tt>). 
<tt>&lt;cstdlib&gt;</tt> (runtime environment <tt>getenv()</tt>, <tt>system()</tt>), and <tt>&lt;ctime&gt;</tt> 
(system clock <tt>clock()</tt>, <tt>time()</tt>) provide further compatibility with C code.
</p></blockquote>
<p>
However, para 2 says
</p>
<blockquote><p>
"The contents of these headers are the same as the Standard C library headers <tt>&lt;setjmp.h&gt;</tt>, 
<tt>&lt;signal.h&gt;</tt>, <tt>&lt;stdalign.h&gt;</tt>, <tt>&lt;stdarg.h&gt;</tt>, <tt>&lt;stdbool.h&gt;</tt>, 
<tt>&lt;stdlib.h&gt;</tt>, and <tt>&lt;time.h&gt;</tt>, respectively, with the following 
changes:",
</p></blockquote>
<p>
and para 8 says 
</p>
<blockquote><p>
"The header <tt>&lt;cstdbool&gt;</tt> and the header <tt>&lt;stdbool.h&gt;</tt> shall 
not define macros named <tt>bool</tt>, <tt>true</tt>, or <tt>false</tt>."
</p></blockquote>
<p>
Thus para 8 doesn't exempt the C++ implementation from the arguably clear requirement of the C standard, to 
provide a macro named <tt>__bool_true_false_are_defined</tt> defined to be 1.
<p/>
Real implementations of the C++ library differ, so the user cannot count upon any consistency; furthermore, the 
usefulness of the transition tool has faded long ago.
<p/>
That's why my suggestion is that both C and C++ standards should eliminate any mention of 
<tt>__bool_true_false_are_defined</tt>.  In that case, the name belongs to implementers to provide, or not, as 
they choose.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2156"></a>2156. Unordered containers' <tt>reserve(n)</tt> reserves for <tt>n-1</tt> elements</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel James <b>Opened:</b> 2012-05-07 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
I think that unordered containers' <tt>reserve</tt> doesn't quite do what it should. I'd expect after calling 
<tt>x.reserve(n)</tt> to be able to insert <tt>n</tt> elements without invalidating iterators. But as 
the standard is written (I'm looking at n3376), I think the guarantee only holds for <tt>n-1</tt> elements.
<p/>
For a container with <tt>max_load_factor</tt> of <tt>1</tt>, <tt>reserve(n)</tt> is equivalent to
<tt>rehash(ceil(n/1))</tt>, ie. <tt>rehash(n)</tt>. <tt>rehash(n)</tt> requires that the bucket
count is <tt>&gt;= n</tt>, so it can be <tt>n</tt> (Table 103). The rule is that <tt>insert</tt>
shall not affect the validity of iterators if <tt>(N + n) &lt; z * B</tt> (23.2.5 [unord.req] p15). 
But for this case the two sides of the equation are equal, so <tt>insert</tt> can affect the validity of iterators.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2157"></a>2157. How does <tt>std::array&lt;T,0&gt;</tt> initialization work when <tt>T</tt> is not default-constructible?</h3>
<p><b>Section:</b> 23.3.2.8 [array.zero] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daryle Walker <b>Opened:</b> 2012-05-08 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#array.zero">issues</a> in [array.zero].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Objects of <tt>std::array&lt;T,N&gt;</tt> are supposed to be initialized with aggregate initialization (when 
not the destination of a copy or move). This clearly works when <tt>N</tt> is positive. What happens when <tt>N</tt> 
is zero?  To continue using an (inner) set of braces for initialization, a <tt>std::array&lt;T,0&gt;</tt> implementation 
must have an array member of at least one element, and let default initialization take care of those secret elements.  
This cannot work when <tt>T</tt> has a set of constructors and the default constructor is deleted from that set.
Solution: Add a new paragraph in 23.3.2.8 [array.zero]:
</p>
<blockquote><p>
The unspecified internal structure of array for this case shall allow initializations like:
</p>
<blockquote><pre>
array&lt;T, 0&gt; a = { };
</pre></blockquote>
<p>
and said initializations must be valid even when <tt>T</tt> is not default-constructible.
</p></blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<p>Add the following new paragraph between the current 23.3.2.8 [array.zero] p1 and p2:</p>

<blockquote><p>
-1- <tt>array</tt> shall provide support for the special case <tt>N == 0</tt>.
<p/>
<ins>-?- The unspecified internal structure of <tt>array</tt> for this case shall allow initializations like:</ins>
</p>
<blockquote><pre>
<ins>array&lt;T, 0&gt; a = { };</ins>
</pre></blockquote>
<p>
<ins>and said initializations must be valid even when <tt>T</tt> is not default-constructible.</ins>
<p/>
-2- In the case that <tt>N == 0</tt>, <tt>begin() == end() ==</tt> unique value. The return value of 
<tt>data()</tt> is unspecified.
<p/>
-3- The effect of calling <tt>front()</tt> or <tt>back()</tt> for a zero-sized array is undefined.
<p/>
-4- Member function <tt>swap()</tt> shall have a <em>noexcept-specification</em> which is equivalent to 
<tt>noexcept(true)</tt>.
</p></blockquote>





<hr>
<h3><a name="2158"></a>2158. Conditional copy&#47;move in <tt>std::vector</tt></h3>
<p><b>Section:</b> 23.3.6.3 [vector.capacity] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2012-05-08 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#vector.capacity">active issues</a> in [vector.capacity].</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
There are various operations on <tt>std::vector</tt> that can cause elements of the vector to be 
moved from one location to another. A move operation can use either rvalue or const lvalue as 
argument; the choice depends on the value of <tt>!is_nothrow_move_constructible&lt;T&gt;::value &amp;&amp;
is_copy_constructible&lt;T&gt;::value</tt>, where <tt>T</tt> is the element type. Thus, some operations 
on <tt>std::vector</tt> (e.g. 'resize' with single parameter, 'reserve', 'emplace_back') should have 
conditional requirements. For example, let's consider the requirement for 'reserve' in N3376 &ndash; 
23.3.6.3 [vector.capacity]&#47;2:
</p>
<blockquote><p>
<i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
</p></blockquote>
<p>
This requirement is not sufficient if an implementation is free to select copy constructor when 
<tt>!is_nothrow_move_constructible&lt;T&gt;::value &amp;&amp; is_copy_constructible&lt;T&gt;::value</tt> 
evaluates to true. Unfortunately, <tt>is_copy_constructible</tt> cannot reliably determine whether 
<tt>T</tt> is really copy-constructible. A class may contain public non-deleted copy constructor whose 
definition does not exist or cannot be instantiated successfully (e.g., 
<tt>std::vector&lt;std::unique_ptr&lt;int&gt;&gt;</tt> has copy constructor, but this type is not 
copy-constructible). Thus, the actual requirements should be:
</p>
<ul>
<li><p>
if <tt>!is_nothrow_move_constructible&lt;T&gt;::value &amp;&amp; is_copy_constructible&lt;T&gt;::value</tt> 
then <tt>T</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>;
</p></li>
<li><p>
otherwise <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
</p></li>
</ul>
<p>
Maybe it would be useful to introduce a new name for such conditional requirement (in addition to 
"<tt>CopyInsertable</tt>" and "<tt>MoveInsertable</tt>").
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2159"></a>2159. <tt>atomic_flag</tt> initialization</h3>
<p><b>Section:</b> 29.7 [atomics.flag] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2012-05-24 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#atomics.flag">active issues</a> in [atomics.flag].</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.flag">issues</a> in [atomics.flag].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
29.7 [atomics.flag]&#47;4 describes the <tt>ATOMIC_FLAG_INIT</tt>, but it's not quite clear about a 
couple of points:
</p>
<ol>
<li><p>
it's said that <tt>ATOMIC_FLAG_INIT</tt> "can be used to initialize an object of type <tt>atomic_flag</tt>" 
and the following example:
</p>
<blockquote><pre>
std::atomic_flag guard = ATOMIC_FLAG_INIT;
</pre></blockquote>
<p>
is presented. It's not clear whether the macro can also be used in the other initialization contexts:
</p>
<blockquote><pre>
std::atomic_flag guard ATOMIC_FLAG_INIT; 
std::atomic_flag guard {ATOMIC_FLAG_INIT};

struct A { std::atomic_flag flag; A(); };
A::A() : flag (ATOMIC_FLAG_INIT); 
A::A() : flag {ATOMIC_FLAG_INIT};
</pre></blockquote>
<p>
Please also note that examples are non-normative, according to the ISO directives, meaning that the wording 
presents no normative way to use the macro.
</p>
</li>

<li><p>
it's said that "It is unspecified whether an uninitialized <tt>atomic_flag</tt> object has an initial state 
of set or clear.". I believe the use of "uninitialized" is inappropriate. First of all, if an object is 
uninitialized it is obvious that we cannot assert anything about its state. Secondly, it doesn't address the 
following cases:
</p>
<blockquote><pre>
std::atomic_flag a; <i>// object is "initialized" by trivial default constructor</i>
std::atomic_flag a {}; <i>// object is value-initialized</i>
static std::atomic_flag a; <i>// object is zero-initialized</i>
</pre></blockquote>
<p>
strictly speaking a trivial constructor "initializes" the object, although it doesn't actually initialize the 
sub-objects.
</p></li>

<li><p>it's said that "For a static-duration object, that initialization shall be static.". Considering 
the following example:</p>
<blockquote><pre>
struct A
{
  A(); <i>// user-provided, not constexpr</i>

  std::atomic_flag flag = ATOMIC_FLAG_INIT;
  <i>// possibly other non-static data members</i>
};

static A a;
</pre></blockquote>
<p>
The object <tt>a.flag</tt> (as a sub-object of the object <tt>a</tt>) has static-duration, yet the initialization 
has to be dynamic because <tt>A::A</tt> is not <tt>constexpr</tt>.
</p>

</li>
</ol>
<p>
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<p>Change 29.7 [atomics.flag]&#47;4 as follows:</p>

<blockquote><p>
The macro <tt>ATOMIC_FLAG_INIT</tt> shall be defined in such a way that it can be used to initialize an object of
type <tt>atomic_flag</tt> to the clear state.  <ins>The macro can be used in the form:</ins>
</p>
<blockquote><pre>
<ins>atomic_flag guard = ATOMIC_FLAG_INIT;</ins>
</pre></blockquote>
<p>
<ins>It's unspecified whether the macro can be used in other initialization contexts.</ins> For a <ins>complete</ins>
static-duration object, that initialization shall be static. <del>It is unspecified whether an uninitialized</del> 
<ins>Unless initialized with <tt>ATOMIC_FLAG_INIT</tt>, it is unspecified whether an</ins> <tt>atomic_flag</tt> 
object has an initial state of set or clear. <del><i>[ Example:</i></del>
</p>
<blockquote><pre>
<del>atomic_flag guard = ATOMIC_FLAG_INIT;</del>
</pre></blockquote>
<p>
<del>&mdash; <i>end example ]</i></del>
</p>
</blockquote>






<hr>
<h3><a name="2160"></a>2160. Unintended destruction ordering-specification of <tt>resize</tt></h3>
<p><b>Section:</b> 23.3.6.3 [vector.capacity] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-06-07 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#vector.capacity">active issues</a> in [vector.capacity].</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
As part of resolving LWG issue <a href="lwg-defects.html#2033">2033</a> a wording change was done for <tt>resize()</tt> to 
respect the problem mentioned in the question:
</p>
<blockquote><p>
Does a call to 'void resize(size_type sz)' of <tt>std::vector</tt> require the element type to be 
<tt>MoveAssignable</tt> because the call <tt>erase(begin() + sz, end())</tt> mentioned in the Effects 
paragraph would require the element type to be <tt>MoveAssignable</tt>?
</p></blockquote>
<p>
The wording change was to replace in 23.3.3.3 [deque.capacity] and 23.3.6.3 [vector.capacity]:
</p>
<blockquote><p>
-1- <i>Effects</i>: If <tt>sz &lt;= size()</tt>, equivalent to <tt>erase(begin() + sz, end())</tt>; [&hellip;]
</p></blockquote>
<p>
by:
</p>
<blockquote><p>
-1- <i>Effects</i>: If <tt>sz &lt;= size()</tt>, equivalent to calling <tt>pop_back() size() - sz</tt> times. [&hellip;]
</p></blockquote>
<p>
The overlooked side-effect of this wording change is that this implies a destruction order
of the removed elements to be in reverse order of construction, but the previous version
did not impose any specific destruction order due to the way how the semantics of <tt>erase</tt>
is specified in Table 100.
<p/>
Given the program:
</p>
<blockquote><pre>
#include &lt;vector&gt;
#include &lt;iostream&gt;

struct Probe {
  int value;
  Probe() : value(0) {}
  Probe(int value) : value(value) {}
  ~Probe() { std::cout &lt;&lt; "~Probe() of " &lt;&lt; value &lt;&lt; std::endl; }
};

int main() {
  std::vector&lt;Probe&gt; v;
  v.push_back(Probe(1));
  v.push_back(Probe(2));
  v.push_back(Probe(3));
  std::cout &lt;&lt; "---" &lt;&lt; std::endl;
  <span style="color:#C80000;font-weight:bold">v.resize(0)</span>;
}
</pre></blockquote>
<p>
the last three lines of the output for every compiler I tested was:
</p>
<blockquote><pre>
~Probe() of 1
~Probe() of 2
~Probe() of 3
</pre></blockquote>
<p>
but a conforming implementation would now need to change this order to
</p>
<blockquote><pre>
~Probe() of 3
~Probe() of 2
~Probe() of 1
</pre></blockquote>
<p>
This possible stringent interpretation makes sense, because one can argue that sequence containers 
(or at least <tt>std::vector</tt>) should have the same required destruction order of it's elements,
as elements of a C array or controlled by memory deallocated with an array <tt>delete</tt> have.
I also learned that libc++ does indeed implement <tt>std::vector::resize</tt> in a way that the
second output form is observed.
<p/>
While I agree that required reverse-destruction would better mimic the natural behaviour of
<tt>std::vector</tt> this was not required in C++03 and this request may be too strong. My current 
suggestion would be to restore the effects of the previous wording <em>in regard to the destruction order</em>, 
because otherwise several currently existing implementations would be broken just because of this
additional requirement.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2161"></a>2161. <tt>const</tt> equivalence of <tt>std::map</tt></h3>
<p><b>Section:</b> 23.4 [associative], 23.5 [unord] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Bjarne Stroustrup <b>Opened:</b> 2012-06-18 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#associative">active issues</a> in [associative].</p>
<p><b>View all other</b> <a href="lwg-index.html#associative">issues</a> in [associative].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
As described in the reflector discussion c++std-core-21860 consider the following example:
</p>
<blockquote><pre>
map&lt;const int,int&lt; mci{};
map&lt;int,int&lt; mi = mci; // ??
mci[1] = 2;
mi[1] = 2;
</pre></blockquote>
<p>
Should it be required that the marked initialization is well-formed? As a possible solution
this could be realized by an alias template:
</p>
<blockquote><pre>
template &lt;class K, class T&gt;
struct OriginalMap { [&hellip;] };

template &lt;class K, class T&gt;
using ImprovedMap = OriginalMap&lt;const K, T&gt;;
</pre></blockquote>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2162"></a>2162. <tt>allocator_traits::max_size</tt> missing <tt>noexcept</tt></h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements], 20.6.8.2 [allocator.traits.members], 20.6.8 [allocator.traits] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2012-07-03 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
N3376 describes in 20.6.8.2 [allocator.traits.members]/7
</p>
<blockquote><pre>
static size_type max_size(Alloc&amp; a);
</pre>
<p>
<i>Returns</i>: <tt>a.max_size()</tt> if that expression is well-formed; otherwise, <tt>numeric_limits&lt;size_type&gt;::max()</tt>.
</p>
</blockquote>
<p>
The <tt>max_size</tt> function is supposed to call one of two functions that are both <tt>noexcept</tt>. 
To make this intermediate function useful for containers, it should preserve the <tt>noexcept</tt> attribute.
<p/>
Proposed changes:
<p/>
In 20.6.8 [allocator.traits] and 20.6.8.2 [allocator.traits.members]/7, change the function signature to
</p>
<blockquote><pre>
static size_type max_size(Alloc&amp; a) noexcept;
</pre></blockquote>

<p><i>[2012-08-05 Daniel comments]</i></p>

<p>
On the first sight this does not seem like a defect of the specification, because the Allocator requirements in 
17.6.3.5 [allocator.requirements] (Table 28) do not impose a no-throw requirement onto <tt>max_size()</tt>; 
the table just describes the fall-back implementation for <tt>max_size()</tt> if a given allocator does 
not provide such a function.
<p/>
<tt>std::allocator</tt> as a special model of this concept and is allowed to increase the exception-guarantees 
for <tt>max_size()</tt>, but this does not imply a corresponding rules for other allocators.
<p/>
Furthermore, <tt>max_size()</tt> of Containers is <em>not</em> specified in terms of 
<tt>Allocator::max_size()</tt>, so again this is not a real contradiction.
<p/>
Nonetheless I think that the following stronger decision should be considered:
</p>
<ol>
<li><p>
Require that for all Allocators (as specified in 17.6.3.5 [allocator.requirements]) <tt>max_size()</tt> 
never throws an exception. This would it make much more useful to call this function in situations where no 
exception should leave the context.
</p></li>
<li><p>
Require that for all Allocators (as specified in 17.6.3.5 [allocator.requirements]) <tt>max_size()</tt>
can be called on const allocator object. Together with the previous item this would allow an implementation 
of a container's <tt>max_size()</tt> function to delegate to the allocator's <tt>max_size()</tt> function.
</p></li>
</ol>
<p>
In regard to the second statement it should be mentioned that there are two current specification
deviations from that in the draft:
</p>
<ol>
<li><p>
The synopsis of 20.6.8 [allocator.traits] uses a const allocator argument as part of the signature
of the <tt>max_size</tt> function.
</p></li>

<li><p>
Both the synopsis of 20.12.1 [allocator.adaptor.syn] and the member specification in
20.12.4 [allocator.adaptor.members] p8 declare <tt>scoped_allocator_adaptor::max_size</tt>
as const member function, but this function delegates to 
</p>
<blockquote><pre>
allocator_traits&lt;OuterAlloc&gt;::max_size(outer_allocator())
</pre></blockquote>
<p>
where <tt>outer_allocator()</tt> resolves to the member function overload returning a
<tt>const outer_allocator_type&amp;</tt>.
</p>
</li>
</ol>

<p>
The question arises whether these current defects actually point to a defect in the Allocator
requirements and should be fixed there.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2163"></a>2163. <tt>nth_element</tt> requires inconsistent post-conditions</h3>
<p><b>Section:</b> 25.4.2 [alg.nth.element] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Peter Sommerlad <b>Opened:</b> 2012-07-06 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The specification of nth_element refers to <tt>operator&lt;</tt> whereas all sorting without a compare function is based on 
<tt>operator&lt;</tt>. While it is true that for all regular types both operators should be defined accordingly, all other 
sorting algorithms only rely on existence of <tt>operator&lt;</tt>. So I guess the paragraph p1
</p>
<blockquote><p>
After <tt>nth_element</tt> the element in the position pointed to by <tt>nth</tt> is the element that would be in that
position if the whole range were sorted. Also for any iterator <tt>i</tt> in the range <tt>[first,nth)</tt> and any
iterator <tt>j</tt> in the range <tt>[nth,last)</tt> it holds that: <tt>!(*i &gt; *j)</tt> or <tt>comp(*j, *i) == false</tt>.
</p></blockquote>
<p>
should read
</p>
<blockquote><p>
After <tt>nth_element</tt> the element in the position pointed to by <tt>nth</tt> is the element that would be in that
position if the whole range were sorted. Also for any iterator <tt>i</tt> in the range <tt>[first,nth)</tt> and any
iterator <tt>j</tt> in the range <tt>[nth,last)</tt> it holds that: <tt>!(*j &lt; *i)</tt> or <tt>comp(*j, *i) == false</tt>.
</p></blockquote>
<p>
Note only "<tt>!(*i &gt; *j)</tt>" was changed to "<tt>!(*j &lt; *i)</tt>" and it would be more symmetric with 
<tt>comp(*j, *i)</tt> as well.
<p/>
In theory this might be a semantic change to the spec, but I believe the mistake is unintended.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change 25.4.2 [alg.nth.element] p1 as indicated:</p>

<blockquote><pre>
template&lt;class RandomAccessIterator&gt;
void nth_element(RandomAccessIterator first, RandomAccessIterator nth,
                 RandomAccessIterator last);
template&lt;class RandomAccessIterator, class Compare&gt;
void nth_element(RandomAccessIterator first, RandomAccessIterator nth,
                 RandomAccessIterator last, Compare comp);
</pre><blockquote>
<p>
-1- After <tt>nth_element</tt> the element in the position pointed to by <tt>nth</tt> is the element that would be in that
position if the whole range were sorted. Also for any iterator <tt>i</tt> in the range <tt>[first,nth)</tt> and any
iterator <tt>j</tt> in the range <tt>[nth,last)</tt> it holds that: <tt><del>!(*i &gt; *j)</del><ins>!(*j &lt; *i)</ins></tt> 
or <tt>comp(*j, *i) == false</tt>.
</p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2164"></a>2164. What are the semantics of <tt>vector.emplace(vector.begin(), vector.back())</tt>?</h3>
<p><b>Section:</b> 23.3.6.5 [vector.modifiers], 23.2 [container.requirements] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2012-07-07 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Nikolay Ivchenkov recently brought the following example on the
<a href="https://groups.google.com/a/isocpp.org/d/topic/std-discussion/dhy23mDFXj4/discussion">std-discussion</a> 
newsgroup, asking whether the following program well-defined:
</p>
<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;vector&gt;

int main()
{
  std::vector&lt;int&gt; v;
  v.reserve(4);
  v = { 1, 2, 3 };
  v.emplace(v.begin(), v.back());
  for (int x : v)
    std::cout &lt;&lt; x &lt;&lt; std::endl;
}
</pre></blockquote>
<p>
Nikolay Ivchenkov:
<p/>
I think that an implementation of <tt>vector</tt>'s 'emplace' should initialize an intermediate object with 
<tt>v.back()</tt> before any shifts take place, then perform all necessary shifts and finally replace the 
value pointed to by <tt>v.begin()</tt> with the value of the intermediate object. So, I would expect the 
following output:
</p>
<blockquote><pre>
3
1
2
3
</pre></blockquote>
<p>
GNU C++ 4.7.1 and GNU C++ 4.8.0 produce other results:
</p>
<blockquote><pre>
2
1
2
3
</pre></blockquote>
<p>
Howard Hinnant:
<p/>
I believe Nikolay is correct that vector should initialize an intermediate object with <tt>v.back()</tt> 
before any shifts take place. As Nikolay pointed out in another email, this appears to be the only way to 
satisfy the strong exception guarantee when an exception is not thrown by <tt>T</tt>'s copy constructor, 
move constructor, copy assignment operator, or move assignment operator as specified by 
23.3.6.5 [vector.modifiers]/p1. I.e. if the emplace construction throws, the vector must remain unaltered.
<p/>
That leads to an implementation that tolerates objects bound to the function parameter pack of the <tt>emplace</tt> 
member function may be elements or sub-objects of elements of the container.
<p/>
My position is that the standard is correct as written, but needs a clarification in this area. Self-referencing 
<tt>emplace</tt> should be legal and give the result Nikolay expects. The proposed resolution of LWG <a href="lwg-closed.html#760">760</a> 
is not correct.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2165"></a>2165. <tt>std::atomic&lt;X&gt;</tt> requires <tt>X</tt> to be nothrow default constructible</h3>
<p><b>Section:</b> 29.5 [atomics.types.generic], 29.6 [atomics.types.operations] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-07-19 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
As raised in c++std-lib-32781, this fails to compile even though the default constructor is not used:
</p>
<blockquote><pre>
#include &lt;atomic&gt;

struct X {
  X() noexcept(false) {}
  X(int) { }
};

std::atomic&lt;X&gt; x(3);
</pre></blockquote>
<p>This is because <tt>atomic&lt;T&gt;</tt>'s default constructor is declared to be non-throwing and 
is explicitly-defaulted on its first declaration:
</p>
<blockquote><pre>
atomic() noexcept = default;
</pre></blockquote>
<p>
This is ill-formed if the implicitly-declared default constructor would not be non-throwing.
<p/>
Possible solutions:
</p>
<ol>
<li>
Add nothrow default constructible to requirements for template argument of the generic <tt>atomic&lt;T&gt;</tt>
</li>
<li>
Remove <tt>atomic&lt;T&gt;::atomic()</tt> from the overload set if <tt>T</tt> is not nothrow default constructible.
</li>
<li>
Remove <tt>noexcept</tt> from <tt>atomic&lt;T&gt;::atomic()</tt>, allowing it to be
deduced (but the default constructor is intended to be always noexcept)
</li>
<li>
Do not default <tt>atomic&lt;T&gt;::atomic()</tt> on its first declaration (but makes the default constructor 
user-provided and so prevents <tt>atomic&lt;T&gt;</tt> being trivial)
</li>
<li>
A core change to allow the mismatched exception specification if the default constructor isn't used 
(see c++std-core-21990)
</li>
</ol>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2166"></a>2166. Heap property underspecified?</h3>
<p><b>Section:</b> 25.4.6 [alg.heap.operations] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Peter Sommerlad <b>Opened:</b> 2012-07-09 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.heap.operations">issues</a> in [alg.heap.operations].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Another similar issue to the <tt>operator&lt;</tt> vs greater in <tt>nth_element</tt> but not as direct occurs 
in 25.4.6 [alg.heap.operations]:
</p>
<blockquote><p>
-1- A <em>heap</em> is a particular organization of elements in a range between two random access iterators 
<tt>[a,b)</tt>. Its two key properties are:
</p>
<ol>
<li>There is no element greater than <tt>*a</tt> in the range and
</li>
<li><tt>*a</tt> may be removed by <tt>pop_heap()</tt>, or a new element added by <tt>push_heap()</tt>, in 
O(log(<tt>N</tt>)) time.
</li>
</ol>
</blockquote>
<p>
As noted by Richard Smith, it seems that the first bullet should read:
</p>
<blockquote><p>
<tt>*a</tt> is not less than any element in the range
</p></blockquote>
<p>
Even better the heap condition could be stated here directly, instead of leaving it unspecified, i.e.,
</p>
<blockquote><p>
Each element at <tt>(a+2*i+1)</tt> and <tt>(a+2*i+2)</tt> is less than the element at <tt>(a+i)</tt>, 
if those elements exist, for <tt>i&gt;=0</tt>.
</p></blockquote>
<p>
But may be that was may be intentional to allow other heap organizations?
<p/>
See also follow-up discussion of c++std-lib-32780.
<p/>

</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2167"></a>2167. Copy assignment requirements of Containers</h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Dean Michael Berris <b>Opened:</b> 2012-07-13 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Table 96 defines the general requirement for copy assignment (row 23, page 704) as:
</p>

<table border="1">
<caption>Table 96 &mdash; Container requirements</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr> 

<tr>
<td>
<tt>r = a</tt>
</td>
<td>
<tt>X&amp;</tt>
</td>
<td>
<tt></tt>
</td>
<td>
post: <tt>r == a.</tt>
</td>
<td>
linear
</td>
</tr>

</table>

<p>
However there is no requirement that <tt>T</tt> is <tt>CopyInsertable</tt> into <tt>X</tt>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change Table 96 &mdash; "Container requirements" in 23.2.1 [container.requirements.general]:</p>

<table border="1">
<caption>Table 96 &mdash; Container requirements</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr> 

<tr>
<td>
<tt>r = a</tt>
</td>
<td>
<tt>X&amp;</tt>
</td>
<td>
<tt></tt>
</td>
<td>
<ins><i>Requires</i>: <tt>T</tt> is <tt>CopyInsertable</tt> into <tt>X</tt>.</ins><br/>
post: <tt>r == a.</tt>
</td>
<td>
linear
</td>
</tr>

</table>

</li>
</ol>







<hr>
<h3><a name="2168"></a>2168. Inconsistent specification of <tt>uniform_real_distribution</tt> constructor</h3>
<p><b>Section:</b> 26.5.8.2.2 [rand.dist.uni.real] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2012-07-14 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
uniform_real says in 26.5.8.2.2 [rand.dist.uni.real] p1:
</p>
<blockquote><p>
A <tt>uniform_real_distribution</tt> random number distribution produces random numbers <tt>x</tt>, <tt>a &le; x &lt; b</tt>,
</p></blockquote>
<p>
but also that (26.5.8.2.2 [rand.dist.uni.real] p2):
</p>
<blockquote><pre>
explicit uniform_real_distribution(RealType a = 0.0, RealType b = 1.0);
</pre><blockquote><p>
-2- <i>Requires</i>: <tt>a &le; b</tt> and <tt>b - a &le; numeric_limits&lt;RealType&gt;::max()</tt>.
</p>
</blockquote></blockquote>
<p>
If you construct a <tt>uniform_real_distribution&lt;RealType&gt;(a, b)</tt> where there are no representable 
numbers between 'a' and 'b' (using <tt>RealType</tt>'s representation) then you cannot satisfy 
26.5.8.2.2 [rand.dist.uni.real].
<p/>
An obvious example is when <tt>a == b</tt>.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2169"></a>2169. Missing <tt>reset()</tt> requirements in <tt>unique_ptr</tt> specialization</h3>
<p><b>Section:</b> 20.7.1.3.3 [unique.ptr.runtime.modifiers] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2012-07-16 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#unique.ptr.runtime.modifiers">issues</a> in [unique.ptr.runtime.modifiers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In 20.7.1.3.3 [unique.ptr.runtime.modifiers]/p1-2 of N3376, the description of <tt>reset()</tt> in the 
array specialization of <tt>unique_ptr</tt> partially duplicates the description of the base template method 
(as specified in 20.7.1.2.5 [unique.ptr.single.modifiers]/p3-5), but lacks some significant requirements. 
Specifically, the text introduced in LWG <a href="lwg-defects.html#998">998</a>, and item 13 of LWG <a href="lwg-defects.html#762">762</a>, is present 
only in the base template, not the specialization.
<p/>
This gives the appearance that these requirements specifically do not apply to the specialization, which I 
don't believe is correct or intended: the issue of <tt>reset()</tt> operation order addressed by LWG <a href="lwg-defects.html#998">998</a> 
applies just as much to the derived template as to the base template, and the derived template has just as 
much need to rely on <tt>get_deleter()(get())</tt> being well-defined, well-formed, and not throwing exceptions 
(arguably some of those properties follow from the fact that <tt>T</tt> is required to be a complete type, but 
not all).
<p/>
Assuming the derived template's <tt>reset()</tt> semantics are intended to be identical to the base template's, 
there is no need to explicitly specify the semantics of <tt>reset(pointer p)</tt> at all (since 
20.7.1.3 [unique.ptr.runtime]/3 specifies "Descriptions are provided below only for member functions that 
have behavior different from the primary template."), and <tt>reset(nullptr_t p)</tt> can be specified by 
reference to the 'pointer' overload. This is more concise, and eliminates any ambiguity about intentional vs. 
accidental discrepancies.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<p>Change 20.7.1.3.3 [unique.ptr.runtime.modifiers] as indicated:</p>

<blockquote><pre>
<del>void reset(pointer p = pointer()) noexcept;</del>
void reset(nullptr_t p) noexcept;
</pre><blockquote>
<p>
-1- <i>Effects</i>: <del>If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt></del>
<ins>Equivalent to <tt>reset(pointer())</tt></ins>.
<p/>
<del>-2- <i>Postcondition</i>: <tt>get() == p</tt>.</del>
</p>
</blockquote></blockquote>






<hr>
<h3><a name="2170"></a>2170. Aggregates cannot be <tt>DefaultConstructible</tt></h3>
<p><b>Section:</b> 17.6.3.1 [utility.arg.requirements] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-07-19 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The lack of the definition of the <tt>DefaultConstructible</tt> requirements in C++03 was fixed 
by LWG <a href="lwg-defects.html#724">724</a> at a time where the core rules of list-initialization were slightly
different than today, at that time value-initialization (shortly) was the primary rule for
class types, i.e. just before applying <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1301">CWG 1301</a>, 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1324">CWG 1324</a>, and 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1368">CWG 1368</a>.
<p/>
The order in 8.5.4 [dcl.init.list] p3 was changed to respect aggregate initialization, but that
had the side-effect that formally aggregate types cannot satisfy the <tt>DefaultConstructible</tt>
requirements anymore, because we require that
</p>
<blockquote><pre>
T u{};
</pre></blockquote>
<p>
<em>value-initializes</em> the object <tt>u</tt>.
<p/>
Of-course exclusion of aggregates was not intended, therefore I suggest to extend the requirements
in Table 19 (17.6.3.1 [utility.arg.requirements]) for empty aggregate-initialization as well.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<p>Change Table 19 in 17.6.3.1 [utility.arg.requirements] as indicated:</p>

<table border="1">
<caption>Table 19 &mdash; <tt>DefaultConstructible</tt> requirements [defaultconstructible]</caption>

<tr>
<th>Expression</th>
<th>Post-condition</th>
</tr> 

<tr>
<td>
<tt>T t;</tt>
</td>
<td>
object <tt>t</tt> is default-initialized
</td>
</tr>

<tr>
<td>
<tt>T u{};</tt>
</td>
<td>
object <tt>u</tt> is value-initialized <ins>or aggregate-initialized</ins>
</td>
</tr>

<tr>
<td>
<tt>T()</tt><br/>
<tt>T{}</tt>
</td>
<td>
a temporary object of type <tt>T</tt> is value-initialized <ins>or aggregate-initialized</ins>
</td>
</tr>

</table>






<hr>
<h3><a name="2171"></a>2171. "swappable" undefined for swapping lvalue and rvalue</h3>
<p><b>Section:</b> 17.6.3.2 [swappable.requirements] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Robert Shearer <b>Opened:</b> 2012-07-24 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#swappable.requirements">active issues</a> in [swappable.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#swappable.requirements">issues</a> in [swappable.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Paragraph 17.6.3.2 [swappable.requirements] p4 states:
</p>
<blockquote><p>
An rvalue or lvalue <tt>t</tt> is <em>swappable</em> if and only if <tt>t</tt> is swappable with any rvalue or lvalue, 
respectively, of type <tt>T</tt>.
</p></blockquote>
<p>
This paragraph seems to establish two disjoint definitions of "swappable" &mdash; one for lvalues and one 
for rvalues &mdash; with neither definition including the case of swapping an rvalue with an lvalue.
<p/>
Resolution proposal:
<p/>
Delete the word "respectively".
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<p>Change 17.6.3.2 [swappable.requirements] p4 as indicated:</p>

<blockquote><p>
An rvalue or lvalue <tt>t</tt> is <em>swappable</em> if and only if <tt>t</tt> is swappable with any rvalue or 
lvalue <del>, respectively,</del> of type <tt>T</tt>.
</p></blockquote>






<hr>
<h3><a name="2172"></a>2172. Does <tt>atomic_compare_exchange_*</tt> accept <tt>v == nullptr</tt> arguments?</h3>
<p><b>Section:</b> 20.7.2.5 [util.smartptr.shared.atomic] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2012-07-28 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.atomic">issues</a> in [util.smartptr.shared.atomic].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Looking at 20.7.2.5 [util.smartptr.shared.atomic]/p31
</p>
<blockquote><pre>
template&lt;class T&gt;
  bool
  atomic_compare_exchange_strong_explicit(shared_ptr&lt;T&gt;* p,
                                          shared_ptr&lt;T&gt;* v,
                                          shared_ptr&lt;T&gt; w,
                                          memory_order success, memory_order failure);
</pre><blockquote><p>
-31- <i>Requires</i>: <tt>p</tt> shall not be null.
</p></blockquote></blockquote>
<p>
What about <tt>v</tt>?  Can it be null?  And if so, what happens?
<p/>
This looks closely related to C++11 issue LWG <a href="lwg-defects.html#1030">1030</a>, where we gave every signature in this section a:
</p>
<blockquote><p>
<i>Requires</i>: <tt>p</tt> shall not be null.
</p></blockquote>
<p>
It looks like a simple oversight to me that we did not add for the <tt>atomic_compare_exchange_*</tt>:
</p>
<blockquote><p>
<i>Requires</i>: <tt>p</tt> shall not be null <ins>and <tt>v</tt> shall not be null</ins>.
</p></blockquote>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<p>Change 20.7.2.5 [util.smartptr.shared.atomic] as indicated:</p>

<blockquote><pre>
template&lt;class T&gt;
  bool atomic_compare_exchange_weak(
    shared_ptr&lt;T&gt;* p, shared_ptr&lt;T&gt;* v, shared_ptr&lt;T&gt; w);
</pre><blockquote><p>
-27- <i>Requires</i>: <tt>p</tt> shall not be null <ins>and <tt>v</tt> shall not be null</ins>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class T&gt;
  bool atomic_compare_exchange_weak_explicit(
    shared_ptr&lt;T&gt;* p, shared_ptr&lt;T&gt;* v, shared_ptr&lt;T&gt; w,
    memory_order success, memory_order failure);
template&lt;class T&gt;
  bool atomic_compare_exchange_strong_explicit(
    shared_ptr&lt;T&gt;* p, shared_ptr&lt;T&gt;* v, shared_ptr&lt;T&gt; w,
    memory_order success, memory_order failure);
</pre><blockquote><p>
-31- <i>Requires</i>: <tt>p</tt> shall not be null <ins>and <tt>v</tt> shall not be null</ins>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>






<hr>
<h3><a name="2173"></a>2173. The meaning of operator + in the description of the algorithms</h3>
<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nikolay Ivchenkov <b>Opened:</b> 2012-08-01 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#algorithms">issues</a> in [algorithms].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to 25.1 [algorithms.general]/12,
</p>
<blockquote><p>
In the description of the algorithms operators <tt>+</tt> and <tt>-</tt> are used for some of the iterator categories 
for which they do not have to be defined. In these cases the semantics of <tt>a+n</tt> is the same as that of
</p>
<blockquote><pre>
X tmp = a;
advance(tmp, n);
return tmp;
</pre></blockquote>
</blockquote>
<p>
There are several places where such operator <tt>+</tt> is applied to an output iterator &mdash; for example, see the 
description of <tt>std::copy</tt>:
</p>
<blockquote><pre>
template&lt;class InputIterator, class OutputIterator&gt;
OutputIterator copy(InputIterator first, InputIterator last,
                    OutputIterator result);
</pre>
<blockquote><p>
-1- <i>Effects</i>: Copies elements in the range <tt>[first,last)</tt> into the range <tt>[result,result + (last -
first))</tt> starting from <tt>first</tt> and proceeding to <tt>last</tt>. For each non-negative integer 
<tt>n &lt; (last - first)</tt>, performs <tt>*(result + n) = *(first + n)</tt>.
</p></blockquote></blockquote>
<p>
<tt>std::advance</tt> is not supposed to be applicable to output iterators, so we need a different method of description.
<p/>
See also message <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=32908">c++std-lib-32908</a>.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2174"></a>2174. <tt>wstring_convert::converted()</tt> should be <tt>noexcept</tt></h3>
<p><b>Section:</b> 22.3.3.2.2 [conversions.string] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-08-02 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#conversions.string">active issues</a> in [conversions.string].</p>
<p><b>View all other</b> <a href="lwg-index.html#conversions.string">issues</a> in [conversions.string].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
There is no reason <tt>wstring_convert::converted()</tt> shouldn't be <tt>noexcept</tt>.
<p/>
It might be possible for <tt>wstring_convert::state()</tt> and <tt>wbuffer_convert::state()</tt> 
to be <tt>noexcept</tt> too, depending on the requirements on <tt>mbstate_t</tt>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Edit in the class template <tt>wstring_convert</tt> synopsis 22.3.3.2.2 [conversions.string] p2:</p>

<blockquote><pre>
size_t converted() const <ins>noexcept</ins>;
</pre></blockquote>
</li>

<li><p>Edit the signature before 22.3.3.2.2 [conversions.string] p6:</p>

<blockquote><pre>
size_t converted() const <ins>noexcept</ins>;
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="2175"></a>2175. <tt>wstring_convert</tt> and <tt>wbuffer_convert</tt> validity</h3>
<p><b>Section:</b> 22.3.3.2.2 [conversions.string], 22.3.3.2.3 [conversions.buffer] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-08-02 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#conversions.string">active issues</a> in [conversions.string].</p>
<p><b>View all other</b> <a href="lwg-index.html#conversions.string">issues</a> in [conversions.string].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
See discussion following <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=32710">c++std-lib-32710</a>.
<p/>
It's not specified what happens if <tt>wstring_convert</tt> and <tt>wbuffer_convert</tt> objects are constructed 
with null <tt>Codecvt</tt> pointers.
<p/>
Should the constructors have preconditions that the pointers are not null?  If not, are conversions expected to 
fail, or is it undefined to attempt conversions if the pointers are null?
<p/>
There are no observer functions to check whether objects were constructed with valid <tt>Codecvt</tt> pointers. 
If the types are made movable such observers would be necessary even if the constructors require non-null 
pointers (see also LWG <a href="lwg-active.html#2176">2176</a>).
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Insert a new paragraph before 22.3.3.2.2 [conversions.string] paragraph 16:</p>

<blockquote><pre>
wstring_convert(Codecvt *pcvt = new Codecvt);
wstring_convert(Codecvt *pcvt, state_type state);
wstring_convert(const byte_string&amp; byte_err,
  const wide_string&amp; wide_err = wide_string());
</pre>
<blockquote>
<p>
<ins>-?- <i>Requires</i>: For the first and second constructors <tt>pcvt != nullptr</tt>.</ins>
<p/>
-16- <i>Effects</i>: The first constructor shall store <tt>pcvt</tt> in <tt>cvtptr</tt> and default values in 
<tt>cvtstate</tt>, <tt>byte_err_string</tt>, and <tt>wide_err_string</tt>. The second constructor shall 
store <tt>pcvt</tt> in <tt>cvtptr</tt>, <tt>state</tt> in <tt>cvtstate</tt>, and default values in 
<tt>byte_err_string</tt> and <tt>wide_err_string</tt>; moreover the stored state shall be retained between 
calls to <tt>from_bytes</tt> and <tt>to_bytes</tt>. The third constructor shall store <tt>new Codecvt</tt> 
in <tt>cvtptr</tt>, <tt>state_type()</tt> in cvtstate, <tt>byte_err</tt> in <tt>byte_err_string</tt>, 
and <tt>wide_err</tt> in <tt>wide_err_string</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Insert a new paragraph before 22.3.3.2.3 [conversions.buffer] paragraph 10:</p>

<blockquote><pre>
wbuffer_convert(std::streambuf *bytebuf = 0,
  Codecvt *pcvt = new Codecvt, state_type state = state_type());
</pre><blockquote>
<p>
<ins>-?- <i>Requires</i>: <tt>pcvt != nullptr</tt>.</ins>
<p/>
-10- <i>Effects</i>: The constructor constructs a stream buffer object, initializes <tt>bufptr</tt> to <tt>bytebuf</tt>, 
initializes <tt>cvtptr</tt> to <tt>pcvt</tt>, and initializes <tt>cvtstate</tt> to <tt>state</tt>.
</p>
</blockquote></blockquote>

</li>

</ol>





<hr>
<h3><a name="2176"></a>2176. Special members for <tt>wstring_convert</tt> and <tt>wbuffer_convert</tt></h3>
<p><b>Section:</b> 22.3.3.2.2 [conversions.string], 22.3.3.2.3 [conversions.buffer] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-08-02 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#conversions.string">active issues</a> in [conversions.string].</p>
<p><b>View all other</b> <a href="lwg-index.html#conversions.string">issues</a> in [conversions.string].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
See discussion following <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=32699">c++std-lib-32699</a>.
<p/>
The constructors for <tt>wstring_convert</tt> and <tt>wbuffer_convert</tt> should be explicit, to avoid 
implicit conversions which take ownership of a <tt>Codecvt</tt> pointer and delete it unexpectedly.
<p/>
Secondly, 22.3.3.2.3 [conversions.buffer] p11 describes a destructor which is not declared in the class 
synopsis in p2.
<p/>
Finally, and most importantly, the definitions in 22.3.3.2.2 [conversions.string] and 
22.3.3.2.3 [conversions.buffer] imply implicitly-defined copy constructors and assignment operators, which 
would do shallow copies of the owned <tt>Codecvt</tt> objects and result in undefined behaviour in the 
destructors.
<p/>
<tt>Codecvt</tt> is not required to be <tt>CopyConstructible</tt>, so deep copies are not possible.  
The <tt>wstring_convert</tt> and <tt>wstring_buffer</tt> types could be made move-only, but the proposed 
resolution below doesn't do so because of the lack of preconditions regarding null <tt>Codecvt</tt> pointers
and the absence of observer functions that would allow users to check preconditions (see also LWG <a href="lwg-active.html#2175">2175</a>).
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Edit the class template <tt>wstring_convert</tt> synopsis in 22.3.3.2.2 [conversions.string] p2:</p>

<blockquote><pre>
<ins>explicit</ins> wstring_convert(Codecvt *pcvt = new Codecvt);
wstring_convert(Codecvt *pcvt, state_type state);
<ins>explicit</ins> wstring_convert(const byte_string&amp; byte_err,
                         const wide_string&amp; wide_err = wide_string());
~wstring_convert();
<ins>
wstring_convert(const wstring_convert&amp;) = delete;
wstring_convert&amp; operator=(const wstring_convert&amp;) = delete;
</ins>				 
</pre></blockquote>
</li>

<li><p>Edit the signatures before 22.3.3.2.2 [conversions.string] p16:</p>

<blockquote><pre>
<ins>explicit</ins> wstring_convert(Codecvt *pcvt = new Codecvt);
wstring_convert(Codecvt *pcvt, state_type state);
<ins>explicit</ins> wstring_convert(const byte_string&amp; byte_err,
    const wide_string&amp; wide_err = wide_string());
</pre></blockquote>
</li>

<li><p>Edit the class template <tt>wbuffer_convert</tt> synopsis in 22.3.3.2.3 [conversions.buffer] p2:</p>

<blockquote><pre>
<ins>explicit</ins> wbuffer_convert(std::streambuf *bytebuf = 0,
                         Codecvt *pcvt = new Codecvt,
                         state_type state = state_type());
<ins>
~wbuffer_convert();

wbuffer_convert(const wbuffer_convert&amp;) = delete;
wbuffer_convert&amp; operator=(const wbuffer_convert&amp;) = delete;
</ins>						 
</pre></blockquote>
</li>

<li><p>Edit the signature before 22.3.3.2.3 [conversions.buffer] p10:</p>

<blockquote><pre>
<ins>explicit</ins> wbuffer_convert(std::streambuf *bytebuf = 0,
    Codecvt *pcvt = new Codecvt, state_type state = state_type());
</pre></blockquote>
</li>

</ol>





<hr>
<h3><a name="2177"></a>2177. Requirements on <tt>Copy&#47;MoveInsertable</tt></h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Lo&iuml;c Joly <b>Opened:</b> 2012-08-10 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
See also discussion following <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=32883">c++std-lib-32883</a>
and <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=32897">c++std-lib-32897</a>.
<p/>
The requirements on <tt>CopyInsertable</tt> and <tt>MoveInsertable</tt> are either incomplete, or complete but hard to 
figure out.
<p/>
From e-mail <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=32897">c++std-lib-32897</a>:
<p/>
Pablo Halpern:
<p/>
I agree that we need semantic requirements for all of the <tt>*Insertable</tt> concepts analogous to the requirements 
we have on similar concepts.
<p/>
Howard Hinnant:
<p/>
I've come to believe that the standard is actually correct as written in this area. But it is <em>really</em> hard 
to read. I would have no objection whatsoever to clarifications to <tt>CopyInsertable</tt> as you suggest (such as the 
post-conditions on <tt>v</tt>). And I do agree with you that the correct approach to the clarifications is to 
confirm that <tt>CopyInsertable</tt> implies <tt>MoveInsertable</tt>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Edit 23.2.1 [container.requirements.general] p13 as indicated:</p>

<blockquote><p>
-13- [&hellip;] Given a container type <tt>X</tt> having an <tt>allocator_type</tt> identical to <tt>A</tt> and 
a <tt>value_type</tt> identical to <tt>T</tt> and given an lvalue <tt>m</tt> of type <tt>A</tt>, a pointer <tt>p</tt> 
of type <tt>T*</tt>, an expression <tt>v</tt> of type (possibly <tt>const</tt>) <tt>T</tt>, and an rvalue <tt>rv</tt> 
of type <tt>T</tt>, the following terms are defined. If <tt>X</tt> is not allocator-aware, the terms below are
defined as if <tt>A</tt> were <tt>std::allocator&lt;T&gt;</tt> &mdash; no allocator object needs to be created and 
user specializations of <tt>std::allocator&lt;T&gt;</tt> are not instantiated:
</p>
<ul>
<li><p><tt>T</tt> is <em><tt>DefaultInsertable</tt> into <tt>X</tt></em> means that the following expression is 
well-formed:</p>
<blockquote><pre>
allocator_traits&lt;A&gt;::construct(m, p)<del>;</del>
</pre></blockquote>
</li>

<li><p>An element of <tt>X</tt> is <em>default-inserted</em> if it is initialized by evaluation of the expression</p>
<blockquote><pre>
allocator_traits&lt;A&gt;::construct(m, p)<del>;</del>
</pre></blockquote>
<p>
where <tt>p</tt> is the address of the uninitialized storage for the element allocated within <tt>X</tt>.
</p>
</li>

<li><p><tt>T</tt> is <em><tt><del>Copy</del><ins>Move</ins>Insertable</tt> into <tt>X</tt></em> means that 
the following expression is well-formed:</p>
<blockquote><pre>
allocator_traits&lt;A&gt;::construct(m, p, <ins>r</ins>v)<del>;</del>
</pre></blockquote>
<p>
<ins>and when evaluated the following postconditions hold: The value of <tt>*p</tt> is equivalent to the value of 
<tt>rv</tt> before the evaluation. [<i>Note</i>: <tt>rv</tt> remains a valid object. Its state is unspecified &mdash; 
<i>end note</i>]</ins>
</p>
</li>

<li><p><tt>T</tt> is <em><tt><del>Move</del><ins>Copy</ins>Insertable</tt> into <tt>X</tt></em> means 
that<ins>, in addition to satisfying the <tt>MoveInsertable</tt> requirements,</ins> the following expression is 
well-formed:</p>
<blockquote><pre>
allocator_traits&lt;A&gt;::construct(m, p, <del>r</del>v)<del>;</del>
</pre></blockquote>
<p>
<ins>and when evaluated the following postconditions hold: The value of <tt>v</tt> is unchanged and is equivalent 
to <tt>*p</tt>.</ins>
</p>
</li>

<li><p><tt>T</tt> is <em><tt>EmplaceConstructible</tt> into <tt>X</tt> from <tt>args</tt></em>, for zero or more arguments 
<tt>args</tt>, means that the following expression is well-formed:</p>
<blockquote><pre>
allocator_traits&lt;A&gt;::construct(m, p, args)<del>;</del>
</pre></blockquote>
</li>

<li><p><tt>T</tt> is <em><tt>Erasable</tt> from <tt>X</tt></em> means that the following expression is well-formed:</p>
<blockquote><pre>
allocator_traits&lt;A&gt;::destroy(m, p)<del>;</del>
</pre></blockquote>
</li>

</ul>
<p>
[<i>Note</i>: A container calls <tt>allocator_traits&lt;A&gt;::construct(m, p, args)</tt> to construct an element 
at <tt>p</tt> using <tt>args</tt>. The default construct in <tt>std::allocator</tt> will call 
<tt>::new((void*)p) T(args)</tt>, but specialized allocators may choose a different definition. &mdash; <i>end note</i>]
</p>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2178"></a>2178. <tt>Allocator</tt> requirement changes not mentioned Annex C</h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements], C.2 [diff.library] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2012-08-14 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Given that a number of things were removed from the allocator requirements (<tt>reference</tt>, <tt>const_reference</tt>, 
<tt>address()</tt> in 17.6.3.5 [allocator.requirements]), it seems that these incompatible changes should be 
mentioned in Annex C.2 [diff.library], more specifically in [diff.cpp03].
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2179"></a>2179. <tt>enable_shared_from_this</tt> and construction from raw pointers</h3>
<p><b>Section:</b> 20.7.2.4 [util.smartptr.enab], 20.7.2.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-08-16 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
On reflector message <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=32927">c++std-lib-32927</a>, 
Matt Austern asked whether the following example should be well-defined or not
</p>
<blockquote><pre>
struct X : public enable_shared_from_this&lt;X&gt; { };
auto xraw = new X;
shared_ptr&lt;X&gt; xp1(xraw);
shared_ptr&lt;X&gt; xp2(xraw);
</pre></blockquote>
<p>
pointing out that 20.7.2.2.1 [util.smartptr.shared.const] does not seem to allow it, since
<tt>xp1</tt> and <tt>xp2</tt> aren't allowed to share ownership, because each of them is required to have 
<tt>use_count() == 1</tt>. Despite this wording it might be reasonable (and technical possible)
to implement that request.
<p/>
On the other hand, there is the non-normative note in 20.7.2.4 [util.smartptr.enab] p11 (already part of TR1):
</p>
<blockquote><p>
The <tt>shared_ptr</tt> constructors that <span style="color:#C80000;font-weight:bold">create unique pointers</span> 
can detect the presence of an <tt>enable_shared_from_this</tt> base and assign the newly created <tt>shared_ptr</tt> 
to its <tt>__weak_this member</tt>.
</p></blockquote>
<p>
Now according to the specification in 20.7.2.2.1 [util.smartptr.shared.const] p3-7:
</p>
<blockquote><pre>
template&lt;class Y&gt; explicit shared_ptr(Y* p);
</pre></blockquote>
<p>
the notion of <em>creating unique pointers</em> can be read to be included by this note, because the post-condition
of this constructor is <tt>unique() == true</tt>. Evidence for this interpretation seems to be weak, though.
<p/>
Howard Hinnant presented the counter argument, that actually the following is an "anti-idiom" and
it seems questionable to teach it to be well-defined in any case:
</p>
<blockquote><pre>
auto xraw = new X;
shared_ptr&lt;X&gt; xp1(xraw);
shared_ptr&lt;X&gt; xp2(xraw);
</pre></blockquote>
<p>
He also pointed out that the current post-conditions of the affected <tt>shared_ptr</tt> constructor
would need to be reworded.
<p/>
It needs to be decided, which direction to follow. If this idiom seems too much broken to be supported,
the note could be improved. If it should be supported, the constructors in
20.7.2.2.1 [util.smartptr.shared.const] need a careful analysis to ensure that post-conditions
are correct.
<p/>
Several library implementations currently do not support this example, instead they typically
cause a crash. Matt points out that there are currently no explicit requirements imposed on
<tt>shared_ptr</tt> objects to own the same underlying object without sharing the ownership. It
might be useful to add such a requirement.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2180"></a>2180. Exceptions from <tt>std::seed_seq</tt> operations</h3>
<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-08-18 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
26.5.7.1 [rand.util.seedseq] p1 says upfront:
</p>
<blockquote><p>
No function described in this section 26.5.7.1 [rand.util.seedseq] throws an exception.
</p></blockquote>
<p>
This constraint seems non-implementable to me when looking especially at the members
</p>
<blockquote><pre>
template&lt;class T&gt;
seed_seq(initializer_list&lt;T&gt; il);

template&lt;class InputIterator&gt;
seed_seq(InputIterator begin, InputIterator end);
</pre></blockquote>
<p>
which have the effect of invoking <tt>v.push_back()</tt> for the exposition-only member of
type <tt>std::vector</tt> (or its equivalent) over all elements of the provided range, so
out-of-memory exceptions are always possible and the <tt>seed_seq</tt> object doesn't seem
to be constructible this way.
<p/>
In addition to the potential lack-of-resources problem, the operations of <tt>InputIterator</tt>
might also throw exceptions.
<p/>
Aside to that it should me mentioned, that a default constructor of <tt>vector&lt;uint_least32_t&gt;</tt> 
in theory can also throw exceptions, even though this seems less of a problem to me in this context, because 
such an implementation could easily use a different internal container in <tt>seed_seq</tt> that can hold 
this no-throw exception guarantee.
<p/>
Secondly, a slightly different problem category related to exceptions occurs for the member templates
</p>
<blockquote><pre>
template&lt;class RandomAccessIterator&gt;
void generate(RandomAccessIterator begin, RandomAccessIterator end);

template&lt;class OutputIterator&gt;
void param(OutputIterator dest) const;
</pre></blockquote>
<p>
where the actual operations performed by the implementation would never need to throw, but since they invoke
operations of a user-provided customization point, the overall operation, like for example
</p>
<blockquote><pre>
copy(v.begin(), v.end(), dest);
</pre></blockquote>
<p>
could also throw exceptions. In this particular example we can just think of a <tt>std::back_insert_iterator</tt>
applied to a container that needs to allocate its elements used as the type for <tt>OutputIterator</tt>.
<p/>
Even though Clause 26 [numerics] has mostly stronger exception constraints than other parts of the
library the here discussed are overrestrictive, especially since no operation of <tt>std::seed_seq</tt> 
except the template <tt>generate</tt> is actually needed within the library implementation, as mentioned in the 
discussion of LWG <a href="lwg-active.html#2124">2124</a>.
<p/>
I suggest to remove the general no-exception constraints for operations of <tt>std::seed_seq</tt> except for
member <tt>size()</tt> and the default constructor and to provide specific wording for <tt>generate()</tt> and
<tt>param()</tt> to ensure that the algorithm itself is a nothrow operation, which is especially for
<tt>generate()</tt> important, because the templates specified in 26.5.3 [rand.eng] and 
26.5.4 [rand.adapt] also depend on this property indirectly, which is further discussed in LWG 
<a href="lwg-active.html#2181">2181</a>.
<p/>
<u>Howard</u>:
<p/>
I suggest to use a different form for the exception specification, something similar to 
20.8.9.1.2 [func.bind.bind] p4:
</p>
<blockquote><p>
<i>Throws</i>: Nothing unless an operation on <tt>RandomAccessIterator</tt> throws an exception.
</p></blockquote>
<p>
<u>Daniel</u>:
<p/>
The currently suggested "what and when" form seems a bit more specific and harmonizes with the form used for
function template <tt>generate_canonical</tt> from 26.5.7.2 [rand.util.canonical].
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Edit 26.5.7.1 [rand.util.seedseq] p1 as indicated:</p>

<blockquote>
<p>
<del>-1- No function described in this section 26.5.7.1 [rand.util.seedseq] throws an exception.</del>
</p>
</blockquote>
</li>

<li><p>Edit 26.5.7.1 [rand.util.seedseq] around p2 as indicated:</p>

<blockquote><pre>
seed_seq();
</pre><blockquote>
<p>
-2- <i>Effects</i>: Constructs a <tt>seed_seq</tt> object as if by default-constructing its member <tt>v</tt>.
<p/>
<ins>-?- <i>Throws</i>: Nothing.</ins>
</p>
</blockquote></blockquote>
</li>

<li><p>Edit 26.5.7.1 [rand.util.seedseq] around p7 as indicated:</p>

<blockquote><pre>
template&lt;class RandomAccessIterator&gt;
  void generate(RandomAccessIterator begin, RandomAccessIterator end);
</pre><blockquote>
<p>
-7- <i>Requires</i>: <tt>RandomAccessIterator</tt> shall meet the requirements of a mutable random access iterator
(Table 111) type. Moreover, <tt>iterator_traits&lt;class RandomAccessIterator&gt;::value_type</tt> shall denote
an unsigned integer type capable of accommodating 32-bit quantities.
<p/>
-8- <i>Effects</i>: Does nothing if <tt>begin == end</tt>. Otherwise, with <tt>s = v.size()</tt> and 
<tt>n = end - begin</tt>, fills the supplied range <tt>[begin, end)</tt> according to the following algorithm [&hellip;]
<p/>
<ins>-?- <i>Throws</i>: What and when <tt>RandomAccessIterator</tt> operations of <tt>begin</tt> and <tt>end</tt> throw.</ins>
</p>
</blockquote></blockquote>
</li>

<li><p>Edit 26.5.7.1 [rand.util.seedseq] around p9 as indicated:</p>

<blockquote><pre>
size_t size() const;
</pre><blockquote>
<p>
-9- <i>Returns</i>: The number of 32-bit units that would be returned by a call to <tt>param()</tt>.
<p/>
<ins>-??- <i>Throws</i>: Nothing.</ins>
<p/>
-10- <i>Complexity</i>: constant time.
</p>
</blockquote></blockquote>
</li>

<li><p>Edit 26.5.7.1 [rand.util.seedseq] around p11 as indicated:</p>

<blockquote><pre>
template&lt;class OutputIterator&gt;
  void param(OutputIterator dest) const;
</pre><blockquote>
<p>
-11- <i>Requires</i>: <tt>OutputIterator</tt> shall satisfy the requirements of an output iterator (Table 108) type. 
Moreover, the expression <tt>*dest = rt</tt> shall be valid for a value <tt>rt</tt> of type <tt>result_type</tt>.
<p/>
-12- <i>Effects</i>: Copies the sequence of prepared 32-bit units to the given destination, as if by executing the
following statement:
</p>
<blockquote><pre>
copy(v.begin(), v.end(), dest);
</pre></blockquote>
<p>
<ins>-??- <i>Throws</i>: What and when <tt>OutputIterator</tt> operations of <tt>dest</tt> throw.</ins>
</p>
</blockquote></blockquote>
</li>

</ol>






<hr>
<h3><a name="2181"></a>2181. Exceptions from <em>seed sequence</em> operations</h3>
<p><b>Section:</b> 26.5.1.2 [rand.req.seedseq], 26.5.3 [rand.eng], 26.5.4 [rand.adapt] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-08-18 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#rand.req.seedseq">active issues</a> in [rand.req.seedseq].</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.req.seedseq">issues</a> in [rand.req.seedseq].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
LWG issue <a href="lwg-active.html#2180">2180</a> points out some deficiences in regard to the specification of the library-provided
type <tt>std::seed_seq</tt> regarding exceptions, but there is another specification problem 
in regard to general types satisfying the <em>seed sequence</em> constraints (named <tt>SSeq</tt>) as described in 
26.5.1.2 [rand.req.seedseq].
<p/>
26.5.3 [rand.eng] p3 and 26.5.4.1 [rand.adapt.general] p3 say upfront:
</p>
<blockquote><p>
Except where specified otherwise, no function described in this section 
26.5.3 [rand.eng]/26.5.4 [rand.adapt] throws an exception.
</p></blockquote>
<p>
This constraint causes problems, because the described templates in these sub-clauses depend on operations of 
<tt>SSeq::generate()</tt> which is a function template, that depends both on operations provided by the 
implementor of <tt>SSeq</tt> (e.g. of <tt>std::seed_seq</tt>), and those of the random access iterator type 
provided by the caller. With class template <tt>linear_congruential_engine</tt> we have just one example for a user 
of <tt>SSeq::generate()</tt> via:
</p>
<blockquote><pre>
template&lt;class Sseq&gt; 
linear_congruential_engine&lt;&gt;::linear_congruential_engine(Sseq&amp; q);

template&lt;class Sseq&gt; 
void linear_congruential_engine&lt;&gt;::seed(Sseq&amp; q);
</pre></blockquote>
<p>
None of these operations has an exclusion rule for exceptions.
<p/>
As described in <a href="lwg-active.html#2180">2180</a> the wording for <tt>std::seed_seq</tt> should and can be fixed to ensure that 
operations of <tt>seed_seq::generate()</tt> won't throw except from operations of the provided iterator range, 
but there is no corresponding "safety belt" for user-provided <tt>SSeq</tt> types, since 26.5.1.2 [rand.req.seedseq]
does not impose no-throw requirements onto operations of <em>seed sequences</em>.
</p>

<ol style="list-style-type:upper-roman">

<li><p>
A quite radical step to fix this problem would be to impose general no-throw requirements on the expression
<tt>q.generate(rb,re)</tt> from Table 115, but this is not as simple as it looks initially, because this
function again depends on general types that are mutable random access iterators. Typically, we do not
impose no-throw requirements on iterator operations and this would restrict general seed sequences where
exceptions are not a problem. Furthermore, we do not impose comparable constraints for other expressions,
like that of the expression <tt>g()</tt> in Table 116 for good reasons, e.g. <tt>random_device::operator()</tt>
explicitly states when it throws exceptions.
</p></li>

<li><p>
A less radical variant of the previous suggestion would be to add a normative requirement on the expression
<tt>q.generate(rb,re)</tt> from Table 115 that says: "Throws nothing if operations of <tt>rb</tt> and <tt>re</tt> 
do not throw exceptions". Nevertheless we typically do not describe <em>conditional</em> Throws elements in proper
requirement sets elsewhere (Container requirements excluded, they just describe the containers from Clause 23)
and this may exclude resonable implementations of seed sequences that could throw exceptions under rare
situations. 
</p></li>

<li><p>
The iterator arguments provided to <tt>SSeq::generate()</tt> for operations in templates of 26.5.3 [rand.eng] and 
26.5.4 [rand.adapt] are under control of implementations, so we could impose stricter exceptions requirements
on <tt>SSeq::generate()</tt> for <tt>SSeq</tt> types that are used to instantiate member templates in 26.5.3 [rand.eng] 
and 26.5.4 [rand.adapt] solely.
</p></li>

<li><p>
We simply add extra wording to the introductive parts of 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]
that specify that operations of the engine (adaptor) templates that depend on a template parameter <tt>SSeq</tt>
throw no exception unless <tt>SSeq::generate()</tt> throws an exception.
</p></li>
</ol>

<p>
Given these options I would suggest to apply the variant described in the fourth bullet.
<p/>
The proposed resolution attempts to reduce a lot of the redundancies of requirements in the introductory paragraphs of 
26.5.3 [rand.eng] and 26.5.4 [rand.adapt] by introducing a new intermediate sub-clause 
"Engine and engine adaptor class templates" following sub-clause 26.5.2 [rand.synopsis]. This approach also
solves the problem that currently 26.5.3 [rand.eng] also describes requirements that apply for
26.5.4 [rand.adapt] (Constrained templates involving the <tt>Sseq</tt> parameters).
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Add a new sub-clause titled "Engine and engine adaptor class templates" following sub-clause 
26.5.2 [rand.synopsis] (but at the same level) and add one further sub-clause "General" as
child of the new sub-clause as follows:
<p/>
<ins>Engine and engine adaptor class templates [rand.engadapt]</ins>
<p/>
<ins>General [rand.engadapt.general]</ins>
</p>
<blockquote><p>
<ins>-?- Throughout this sub-clause general requirements and conventions are described that apply to every class 
template specified in sub-clause 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]. Phrases of the 
form "in those sub-clauses" shall be interpreted as equivalent to "in sub-clauses 26.5.3 [rand.eng] and 
26.5.4 [rand.adapt]".
</ins>
<p/>
<ins>-?- Except where specified otherwise, the complexity of each function specified in those sub-clauses is constant.</ins>
<p/>
<ins>-?- Except where specified otherwise, no function described in those sub-clauses throws an exception.</ins>
<p/>
<ins>-?- Every function described in those sub-clauses that has a function parameter <tt>q</tt> of type
<tt>SSeq&amp;</tt> for a template type parameter named <tt>SSeq</tt> that is different from type <tt>std::seed_seq</tt> 
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
<p/>
<ins>-?- Descriptions are provided in those sub-clauses only for engine operations that are not described in 
26.5.1.4 [rand.req.eng], for adaptor operations that are not described in 26.5.1.5 [rand.req.adapt],
or for operations where there is additional semantic information. In particular, declarations for copy constructors,
for copy assignment operators, for streaming operators, and for equality and inequality operators
are not shown in the synopses.</ins>
<p/>
<ins>-?- Each template specified in those sub-clauses requires one or more relationships, involving the value(s) of
its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if
any such required relationship fails to hold.</ins>
<p/>
<ins>-?- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in those 
sub-clauses:</ins>
</p>
<ul>
<li><p>
<ins>if the constructor</ins>
</p>
<blockquote><pre>
<ins>template &lt;class Sseq&gt; explicit X(Sseq&amp; q);</ins>
</pre></blockquote>
<p>
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this constructor shall not
participate in overload resolution;</ins>
</p>
</li>

<li><p>
<ins>if the member function</ins>
</p>
<blockquote><pre>
<ins>template &lt;class Sseq&gt; void seed(Sseq&amp; q);</ins>
</pre></blockquote>
<p>
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this function shall not
participate in overload resolution;</ins>
</p>
</li>
</ul>
<p>
<ins>The extent to which an implementation determines that a type cannot be a seed sequence is unspecified,
except that as a minimum a type shall not qualify as a seed sequence if it is implicitly convertible to
<tt>X::result_type</tt>.</ins>
</p>
</blockquote>

</li>

<li><p>Edit the contents of sub-clause 26.5.3 [rand.eng] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section 26.5.3 [rand.eng] satisfies the 
requirements of a random number engine (26.5.1.4 [rand.req.eng]) type <ins>and the general implementation 
requirements specified in sub-clause [rand.engadapt.general]</ins>.
<p/>
<del>-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.3 [rand.eng] 
is constant.</del>
<p/>
<del>-3- Except where specified otherwise, no function described in this section 26.5.3 [rand.eng] throws an exception.</del>
<p/>
<del>-4- Descriptions are provided in this section 26.5.3 [rand.eng] only for engine operations that are not 
described in 26.5.1.4 [rand.req.eng] [&hellip;]</del>
<p/>
<del>-5- Each template specified in this section 26.5.3 [rand.eng] requires one or more relationships, 
involving the value(s) of its non-type template parameter(s), to hold. [&hellip;]</del>
<p/>
<del>-6- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in this subclause
(26.5.3 [rand.eng]) and in sub-clause 26.5.3 [rand.eng]: [&hellip;]</del>
</p></blockquote>

</li>

<li><p>Edit the contents of sub-clause 26.5.4.1 [rand.adapt.general] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section <del>26.5.3 [rand.eng]</del><ins>26.5.4 [rand.adapt]</ins> satisfies the 
requirements of a random number engine adaptor (26.5.1.5 [rand.req.adapt]) type <ins>and the general 
implementation requirements specified in sub-clause [rand.engadapt.general]</ins>.
<p/>
<del>-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.4 [rand.adapt] 
is constant.</del>
<p/>
<del>-3- Except where specified otherwise, no function described in this section 26.5.4 [rand.adapt] throws an exception.</del>
<p/>
<del>-4- Descriptions are provided in this section 26.5.4 [rand.adapt] only for engine operations that are not 
described in 26.5.1.5 [rand.req.adapt] [&hellip;]</del>
<p/>
<del>-5- Each template specified in this section 26.5.4 [rand.adapt] requires one or more relationships, involving 
the value(s) of its non-type template parameter(s), to hold. [&hellip;]</del>
</p></blockquote>

</li>

</ol>





<hr>
<h3><a name="2182"></a>2182. <tt>Container::[const_]reference</tt> types are misleadingly specified</h3>
<p><b>Section:</b> 26.5.1.2 [rand.req.seedseq] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-08-20 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#rand.req.seedseq">active issues</a> in [rand.req.seedseq].</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.req.seedseq">issues</a> in [rand.req.seedseq].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to Table 96 (Container requirements) the return type of <tt>X::reference</tt> and
<tt>X::const_reference</tt> is "lvalue of <tt>T</tt>" and "<tt>const</tt> lvalue of <tt>T</tt>",
respectively. This does not make much sense, because an lvalue is an expression category, not a type.
It could also refer to an expression that has a type, but this doesn't make sense either in this
context, because obviously <tt>X::[const_]reference</tt> are intended to refer to types. 
<p/>
Given the fact that <tt>vector&lt;bool&gt;</tt> has no real reference type for <tt>X::[const_]reference</tt> 
and this definition presumably is intended to cover such situations as well, one might think that the wording is
just a sloppy form of "type that represents a [const] lvalue of T". But this is also problematic,
because basically all proxy reference expressions are rvalues.
<p/>
It is unclear what the intention is. A straightward way of fixing this wording could make
<tt>X::[const_]reference</tt> identical to <tt>[const] T&amp;</tt>. This holds for all Library containers
except for <tt>vector&lt;bool&gt;</tt>.
<p/>
Another way of solving this definition problem would be to impose a requirement that holds for both
references and reference-like proxies. Both <tt>X::reference</tt> and <tt>X::const_reference</tt>
would need to be convertible to <tt>const T&amp;</tt>. Additionally <tt>X::reference</tt> would need to
support for a mutable container an assignment expression of the form 
<tt>declval&lt;X::reference&gt;() = declval&lt;T&gt;()</tt> (this presentation intentionally does not require 
<tt>declval&lt;X::reference<span style="color:#C80000;font-weight:bold">&amp;</span>&gt;() = declval&lt;T&gt;()</tt>).
<p/>
Further, the Table 96 does not impose any relations between <tt>X::reference</tt> and <tt>X::const_reference</tt>.
It seems that at least <tt>X::reference</tt> needs to be convertible to <tt>X::const_reference</tt>.
<p/>
A related question is whether <tt>X::reference</tt> is supposed to be a mutable reference-like type,
irrespective of whether the container is an immutable container or not. The way, type <tt>match_results</tt>
defines <tt>reference</tt> identical to <tt>const_reference</tt> indicates one specific interpretation.
Note that this can be a different decision as that for <tt>iterator</tt> and <tt>const_iterator</tt>,
e.g. for sets the type <tt>X::reference</tt> still is a mutable reference, even though <tt>iterator</tt>
is described as constant iterator.
<p/>
The proposed resolution is incomplete in regard to the last question.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change Table 96 &mdash; "Container requirements" as indicated:</p>

<table border="1">
<caption>Table p6 &mdash; Container requirements</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational<br/>Semantics</th>
<th>Assertion/note<br/>pre-/post-condition</th>
<th>Complexity</th>
</tr> 

<tr>
<td>
<tt>X::reference</tt>
</td>
<td>
<del>lvalue of</del><ins>type that behaves like a reference to</ins> <tt>T</tt>
</td>
<td>
&nbsp;
</td>
<td>
<ins>convertible to <tt>X::const_reference</tt><br/>
and to <tt>const T&amp;</tt></ins>
</td>
<td>
compile time
</td>
</tr>

<tr>
<td>
<tt>X::const_reference</tt>
</td>
<td>
<del>const lvalue of</del><ins>type that behaves like a reference to <tt>const</tt></ins> <tt>T</tt>
</td>
<td>
&nbsp;
</td>
<td>
<ins>convertible to <tt>const T&amp;</tt></ins>
</td>
<td>
compile time
</td>
</tr>

</table>

</li>
</ol>





<hr>
<h3><a name="2183"></a>2183. Muddled allocator requirements for <tt>match_results</tt> constructors</h3>
<p><b>Section:</b> 28.10.1 [re.results.const], 28.10.6 [re.results.all] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-08-29 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.results.const">active issues</a> in [re.results.const].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.results.const">issues</a> in [re.results.const].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
28.10.1 [re.results.const] p1 says:
</p>
<blockquote><p>
In all <tt>match_results</tt> constructors, a copy of the <tt>Allocator</tt> argument shall be used for any memory 
allocation performed by the constructor or member functions during the lifetime of the object.
</p></blockquote>
<p>
There are three constructors:
</p>
<blockquote><pre>
match_results(const Allocator&amp; = Allocator());
match_results(const match_results&amp; m);
match_results(match_results&amp;&amp; m) noexcept;
</pre></blockquote>
<p>
The second and third constructors do no have an <tt>Allocator</tt> argument, so despite the "all <tt>match_results</tt> 
constructors", it is not possible to use "the <tt>Allocator</tt> argument" for the second and third constructors.
<p/>
The requirements for those two constructors also does not give any guidance. The second constructor has no language 
about allocators, and the third states that the stored <tt>Allocator</tt> value is move constructed from 
<tt>m.get_allocator()</tt>, but doesn't require using that allocator to allocate memory.
<p/>
The same basic problem recurs in 28.10.6 [re.results.all], which gives the required return value for 
<tt>get_allocator()</tt>:
</p>
<blockquote><p>
<i>Returns</i>: A copy of the <tt>Allocator</tt> that was passed to the object's constructor or, if that allocator 
has been replaced, a copy of the most recent replacement.
</p></blockquote>
<p>
Again, the second and third constructors do not take an <tt>Allocator</tt>, so there is nothing that meets this 
requirement when those constructors are used.
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2184"></a>2184. Muddled allocator requirements for <tt>match_results</tt> assignments</h3>
<p><b>Section:</b> 28.10.1 [re.results.const], 28.10.6 [re.results.all] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-08-29 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.results.const">active issues</a> in [re.results.const].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.results.const">issues</a> in [re.results.const].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The effects of the two assignment operators are specified in Table 141. Table 141 makes no mention of allocators, 
so, presumably, they don't touch the target object's allocator. That's okay, but it leaves the question: 
<tt>match_results::get_allocator()</tt> is supposed to return "A copy of the Allocator that was passed to the 
object's constructor or, if that allocator has been replaced, a copy of the most recent replacement"; if assignment 
doesn't replace the allocator, how can the allocator be replaced?
</p>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="2185"></a>2185. Missing throws clause for <tt>future/shared_future::wait_for/wait_until</tt></h3>
<p><b>Section:</b> 30.6.6 [futures.unique_future], 30.6.7 [futures.shared_future] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Vicente J. Botet Escriba <b>Opened:</b> 2012-09-20 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The functions <tt>future::wait_for</tt>, <tt>future::wait_until</tt>, <tt>shared_future::wait_for</tt>, and 
<tt>shared_future::wait_for</tt> can throw any timeout-related exceptions. It would be better if the wording 
could be more explicit. This is in line with the changes proposed in LWG <a href="lwg-active.html#2093">2093</a>'s <em>Throws</em> element 
of <tt>condition_variable::wait</tt> with predicate.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change 30.6.6 [futures.unique_future] as indicated:</p>
<blockquote><pre>
template &lt;class Rep, class Period&gt;
future_status wait_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time) const;
</pre><blockquote><p>
-21- <i>Effects</i>: none if the shared state contains a deferred function (30.6.8 [futures.async]), otherwise 
blocks until the shared state is ready or until the relative timeout (30.2.4 [thread.req.timing]) specified by 
<tt>rel_time</tt> has expired.
<p/>
-22- <i>Returns</i>: [&hellip;]
<p/>
<ins>-??- <i>Throws</i>: timeout-related exceptions (30.2.4 [thread.req.timing]).</ins>
</p>
</blockquote><pre>
template &lt;class Clock, class Duration&gt;
future_status wait_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time) const;
</pre><blockquote><p>
-23- <i>Effects</i>: none if the shared state contains a deferred function (30.6.8 [futures.async]), otherwise 
blocks until the shared state is ready or until the absolute timeout (30.2.4 [thread.req.timing]) specified by 
<tt>abs_time</tt> has expired.
<p/>
-24- <i>Returns</i>: [&hellip;]
<p/>
<ins>-??- <i>Throws</i>: timeout-related exceptions (30.2.4 [thread.req.timing]).</ins>
</p>
</blockquote></blockquote>
</li>

<li><p>Change 30.6.7 [futures.shared_future] as indicated:</p>
<blockquote><pre>
template &lt;class Rep, class Period&gt;
future_status wait_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time) const;
</pre><blockquote><p>
-23- <i>Effects</i>: none if the shared state contains a deferred function (30.6.8 [futures.async]), otherwise 
blocks until the shared state is ready or until the relative timeout (30.2.4 [thread.req.timing]) specified by 
<tt>rel_time</tt> has expired.
<p/>
-24- <i>Returns</i>: [&hellip;]
<p/>
<ins>-??- <i>Throws</i>: timeout-related exceptions (30.2.4 [thread.req.timing]).</ins>
</p>
</blockquote><pre>
template &lt;class Clock, class Duration&gt;
future_status wait_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time) const;
</pre><blockquote><p>
-25- <i>Effects</i>: none if the shared state contains a deferred function (30.6.8 [futures.async]), otherwise 
blocks until the shared state is ready or until the absolute timeout (30.2.4 [thread.req.timing]) specified by 
<tt>abs_time</tt> has expired.
<p/>
-26- <i>Returns</i>: [&hellip;]
<p/>
<ins>-??- <i>Throws</i>: timeout-related exceptions (30.2.4 [thread.req.timing]).</ins>
</p>
</blockquote></blockquote>
</li>

</ol>






<hr>
<h3><a name="2186"></a>2186. Incomplete action on <tt>async/launch::deferred</tt></h3>
<p><b>Section:</b> 30.6.8 [futures.async] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Vicente J. Botet Escriba <b>Opened:</b> 2012-09-20 <b>Last modified:</b> 2012-09-24</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.async">active issues</a> in [futures.async].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.async">issues</a> in [futures.async].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The description of the effects of <tt>async</tt> when the launch policy is <tt>launch::deferred</tt> doesn't 
state what is done with the result of the deferred function invocation and the possible exceptions as it is done 
for the asynchronous function when the policy is <tt>launch::async</tt>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change 30.6.8 [futures.async] p3 bullet 2 as indicated:</p>
<blockquote><pre>
template &lt;class F, class... Args&gt;
future&lt;typename result_of&lt;typename decay&lt;F&gt;::type(typename decay&lt;Args>::type...)&gt;::type&gt;
async(F&amp;&amp; f, Args&amp;&amp;... args);
template &lt;class F, class... Args&gt;
future&lt;typename result_of&lt;typename decay&lt;F&gt;::type(typename decay&lt;Args&gt;::type...)&gt;::type&gt;
async(launch policy, F&amp;&amp; f, Args&amp;&amp;... args);
</pre><blockquote><p>
-2- <i>Requires</i>: [&hellip;]
<p/>
-3- <i>Effects:</i>: The first function behaves the same as a call to the second function with a <tt>policy</tt> argument of
<tt>launch::async | launch::deferred</tt> and the same arguments for <tt>F</tt> and <tt>Args</tt>. [&hellip;] The further 
behavior of the second function depends on the <tt>policy</tt> argument as follows (if more than one of these conditions
applies, the implementation may choose any of the corresponding policies):
</p>
<ul>
<li><p>if <tt>policy &amp; launch::async</tt> is non-zero [&hellip;]</p></li>
<li><p>if <tt>policy &amp; launch::deferred</tt> is non-zero &mdash; Stores <tt><i>DECAY_COPY</i>(std::forward&lt;F&gt;(f))</tt> 
and <tt><i>DECAY_COPY</i>(std::forward&lt;Args>(args))...</tt> in the shared state. These copies of <tt>f</tt> and <tt>args</tt>
constitute a <em>deferred function</em>. Invocation of the deferred function evaluates <tt><i>INVOKE</i>(std::move(g), std::move(xyz))</tt> 
where <tt>g</tt> is the stored value of <tt><i>DECAY_COPY</i>(std::forward&lt;F>(f))</tt> and <tt>xyz</tt> is
the stored copy of <tt><i>DECAY_COPY</i>(std::forward&lt;Args>(args))...</tt>. <ins>Any return value is stored as the 
result in the shared state. Any exception propagated from the execution of the deferred function is stored as the 
exceptional result in the shared state.</ins> The shared state is not made ready until the function has completed. 
The first call to a non-timed waiting function (30.6.4 [futures.state]) on an asynchronous return object referring 
to this shared state shall invoke the deferred function in the thread that called the waiting function. Once evaluation 
of <tt><i>INVOKE</i>(std::move(g), std::move(xyz))</tt> begins, the function is no longer considered deferred. 
[<i>Note</i>: If this policy is specified together with other policies, such as when using a policy value of 
<tt>launch::async | launch::deferred</tt>, implementations should defer invocation or the selection of the <tt>policy</tt> 
when no more concurrency can be effectively exploited. &mdash; <i>end note</i>]
</p></li>
</ul>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2187"></a>2187. <tt>vector&lt;bool&gt;</tt> is missing <tt>emplace</tt> and <tt>emplace_back</tt> member functions</h3>
<p><b>Section:</b> 23.3.7 [vector.bool] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
It should have them so that it more closely matches the <tt>vector&lt;T&gt;</tt> interface, as this helps when 
writing generic code.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change the class template <tt>vector&lt;bool&gt;</tt> synopsis, 23.3.7 [vector.bool] p1, as indicated:</p>
<blockquote><pre>
namespace std {
  template &lt;class Allocator&gt; class vector&lt;bool, Allocator&gt; {
  public:
    [&hellip;]
    <i>// modifiers:</i>
    <ins>template &lt;class... Args&gt; void emplace_back(Args&amp;&amp;... args);</ins>
    void push_back(const bool&amp; x);
    void pop_back();
    <ins>template &lt;class... Args&gt; iterator emplace(const_iterator position, Args&amp;&amp;... args);</ins>
    iterator insert(const_iterator position, const bool&amp; x);
    [&hellip;]
  };
}
</pre></blockquote>
</li>
</ol>






<hr>
<h3><a name="2188"></a>2188. Reverse iterator does not fully support targets that overload <tt>operator&amp;</tt></h3>
<p><b>Section:</b> 24.5.1.3.5 [reverse.iter.opref] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-09-23 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all other</b> <a href="lwg-index.html#reverse.iter.opref">issues</a> in [reverse.iter.opref].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The specification for <tt>reverse_iterator::operator-></tt>
returns the address of the object yielded by dereferencing
with <tt>operatator*</tt>, but does not have the usual
wording about returning the true address of the object.  As
<tt>reverse_iterator</tt> requires the adapted iterator have
at least the bidirectional iterator category, we know that
the returned reference is a true reference, and not a proxy,
hence we can use <tt>std::addressof</tt> on the reference
to get the right answer.
</p>
<p>
This will most likely show itself as an issue with a <tt>list</tt>
or <tt>vector</tt> of a type with such an overloaded operator,
where algorithms are likely to work with a forward iteration, but
not with reverse iteration.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Revise 24.5.1.3.5 [reverse.iter.opref] p1, as indicated:
</p>
<p>
<i>Returns:</i> <ins>The true address of the object returned by </ins>
<tt><del>&(</del>operator*()<del>)</del></tt>.
</p>





<hr>
<h3><a name="2189"></a>2189. Throwing <tt>swap</tt> breaks unordered containers' state</h3>
<p><b>Section:</b> 23.2.5.1 [unord.req.except] <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-09-23 <b>Last modified:</b> 2012-09-24</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The hash functor and key-comparison functor of unordered containers are allowed to throw on <tt>swap</tt>.
</p>
<p>
23.2.5.1 [unord.req.except]p3 "For unordered associative containers, no <tt>swap</tt> function throws
an exception unless that exception is thrown by the swap of the container's Hash or Pred object (if any)."
</p>
<p>
In such a case we must offer the basic exception safety guarantee, where both objects are left in valid
but unspecified states, and no resources are leaked.  This yields a corrupt, un-usable container if the
first <tt>swap</tt> succeeds, but the second fails by throwing, as the functors form a matched pair.
</p>
<p>
So our basic scenario is first, swap the allocators if the allocators propagate on swap, according to
<tt>allocator_traits</tt>.  Next we swap the pointers to our internal hash table data structures, so that
they match the allocators that allocated them.  (Typically, this operation cannot throw).  Now our containers
are back in a safely destructible state if an exception follows.
</p>
<p>
Next, let's say we swap the hash functor, and that throws.  We have a corrupt data structure, in that the
buckets are not correctly indexed by the correct functors, lookups will give unpredicatable results etc.
We can safely restore a usable state by forcibly clearing each container - which does not leak resources
and leaves us with two (empty but) usable containers.
</p>
<p>
Now let us assume that the hasher swap succeeds.  Next we swap the equality comparator functor, and this
too could throw. The important point to bear in mind is that these two functors form an important pairing
- two objects that compare equal by the equality functor must also hash to the same value.  If we swap
one without the other, we most likely leave the container in an unusable state, even if we clear out all
elements.
</p>
<p>
1. A colleague pointed out that the solution for this is to dynamically allocate the two functors, and then
we need only swap pointers, which is not a throwing operation.  And if we don't want to allocate on default
construction (a common QoI request), we might consider moving to a dynamically allocated functors whenever
<tt>swap</tt> is called, or on first insertion.  Of course, allocating memory in <tt>swap</tt> is a whole
new can of worms, but this does not really sound like the design we had intended.
</p>

<p>
2. The simplest option is to say that we do not support hasher or equality functors that throw on ADL
<tt>swap</tt>.  Note that the requirement is simply to not throw, rather than to be explicitly
marked as <tt>noexcept</tt>.  Throwing functors are allowed, so long as we never use values that
would actually manifest a throw when used in an unordered container.
</p>

<p>
Pablo went on to give me several more options, to be sure we have a full set to consider:
</p>
<p>
3. Disallow one or the other functor from throwing.  In that case, the 
possibly-throwing functor must be swapped first, then the other functor, 
the allocator, and the data pointer(s) afterwards (in any order -- there 
was a TC that allocator assignment and swap may not throw if the 
corresponding propagation trait is true.). Of course, the question 
becomes: which functor is allowed to throw and which one is not?
</p>
<p>
4. Require that any successful functor <tt>swap</tt> be reliably reversible.  
This is very inventive.  I know of no other place in the standard where 
such a requirement is stated, though I have occasionally wanted such a 
guarantee.
</p>
<p>
5. Allow a failed swap to leave the containers in a state where future 
insertions may fail for reasons other than is currently allowed.  
Specifically, if the hash and equality functors are out of sync, all 
insertions will fail.  Presumably some "incompletely swapped" exception 
would be thrown.  This is "slightly" inventive, although people have been 
discussing "radioactive" states for a while.
</p>



<p><b>Proposed resolution:</b></p>






</body>
</html>
