<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    C++ CD1 Comment Status
   </TITLE>
</HEAD>
<BODY>
<TABLE align="right" cellspacing="0" cellpadding="0">
<TR>
<TD align="right">Document number:</TD>
<TD>&#160;PL22.16/10-0019 = WG21 N3029</TD>
</TR>
<TR>
<TD align="right">Date:</TD>
<TD>&#160;2010-02-16</TD>
</TR>
<TR>
<TD align="right" valign="top">Reply to:</TD>
<TD>
      &#160;William M. Miller<BR>
      &#160;Edison Design Group, Inc.<BR>
      &#160;<A href="mailto://wmm@edg.com">wmm@edg.com</A><BR><BR>
      &#160;Beman Dawes<BR>
      &#160;<A href="mailto://bdawes@acm.org">bdawes@acm.org</A></TD>
</TR>
</TABLE><BR><BR><BR><BR><BR><BR><BR><BR><BR><CENTER>
<H1>
     C++ CD1 Comment Status
    </H1>
<H2>Rev. 4</H2>
</CENTER>
<P>
    This document summarizes the progress of WG21 in
    addressing National Body comments on Committee Draft document N2800. In
    total, 591 comments
    were received. To date,
    268
    have been accepted or tentatively accepted as proposed,
    137
    have been accepted or tentatively accepted with modifications,
    118
    have been rejected, and
    59
    remain to be addressed. The detailed breakdown:
   </P>
<UL><UL>
<TABLE>
<THEAD>
<TR><TH></TH><TH>Unresolved</TH><TH>Accepted</TH><TH>Modified</TH><TH>Rejected</TH><TH>Total</TH></TR>
</THEAD>
<TBODY>
<TR>
<TD><B>CWG</B></TD>
<TD align="center">11</TD>
<TD align="center">89</TD>
<TD align="center">27</TD>
<TD align="center">49</TD>
<TD align="center">176</TD>
</TR>
<TR>
<TD><B>LWG</B></TD>
<TD align="center">26</TD>
<TD align="center">33</TD>
<TD align="center">88</TD>
<TD align="center">48</TD>
<TD align="center">203</TD>
</TR>
<TR>
<TD><B>editor</B></TD>
<TD align="center">22</TD>
<TD align="center">146</TD>
<TD align="center">22</TD>
<TD align="center">21</TD>
<TD align="center">212</TD>
</TR>
</TBODY>
</TABLE>
</UL></UL>
<P>
    This document consists of three tables.  <A href="#TOC">The
    first</A> is a table of contents, listing each issue by National
    Body and comment number and giving its current status.  <A href="#OPEN">The second</A> is a list of all as-yet unresolved
    comments, sorted by the responsible party. <A href="#RR">The
    third</A> is a comprehensive listing of all the comments received
    in the same order and with roughly the same organization as in
    document N2837; the &#8220;Disposition&#8221; field gives the
    response, as well as any explanatory comments provided by the
    responsible party. (The internal formatting of the text of the
    national body comments will be improved in future revisions of
    this document.)
   </P>
<HR><A NAME="TOC"></A><H3><U>SORTED LISTING OF COMMENTS:</U></H3>
<P>In the following table, the &#8220;Date&#8221; field represents
    the date on which the Committee affirmed the listed
    disposition.</P>
<TABLE border="1" cellspacing="0" cellpadding="4" frame="box">
<THEAD>
<TR>
<TH>ID</TH>
<TH>Responsible</TH>
<TH>Disposition</TH>
<TH>Date</TH>
<TH>Issue</TH>
<TH>Document</TH>
</TR>
</THEAD>
<TBODY>
<TR>
<TD><A HREF="
          #CA1">CA 1</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA2">CA 2</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#N/A">N/A</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH1">CH 1</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#794">794</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH2">CH 2</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE1">DE 1</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE2">DE 2</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1153">1153</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE3">DE 3</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#735">735</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE4">DE 4</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#693">693</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE5">DE 5</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#731">731</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE6">DE 6</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2845.html">
          N2845</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE7">DE 7</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE8">DE 8</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE9">DE 9</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#720">720</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
          N2927</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE10">DE 10</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#731">731</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE11">DE 11</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE12">DE 12</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-12&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#731">731</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE13">DE 13</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#732">732</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
          N2927</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE14">DE 14</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#730">730</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE15">DE 15</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE16">DE 16</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#902">902</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE17">DE 17</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1078">1078</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE18">DE 18</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1097,1098 ">1097,1098 </A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE20">DE 20</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE21">DE 21</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#817">817</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE22">DE 22</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1023">1023</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE23">DE 23</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#699">699</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE24">DE 24</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#922">922</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE25">DE 25</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#831">831</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI1">FI 1</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#939">939</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.html">
          N2928</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI2">FI 2</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI3">FI 3</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI4">FI 4</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI5">FI 5</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI6">FI 6</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI7">FI 7</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR1">FR 1</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR2">FR 2</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1156">1156</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR3">FR 3</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR4">FR 4</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR5">FR 5</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#690">690</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR6">FR 6</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR7">FR 7</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR8">FR 8</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR9">FR 9</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR10">FR 10</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#788">788</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR11">FR 11</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR12">FR 12</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR13">FR 13</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR14">FR 14</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR15">FR 15</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR16">FR 16</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#481">481</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR17">FR 17</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#791">791</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR18">FR 18</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR19">FR 19</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR20">FR 20</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR21">FR 21</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR22">FR 22</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR23">FR 23</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR24">FR 24</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR25">FR 25</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR26">FR 26</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR27">FR 27</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR28">FR 28</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR29">FR 29</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#823">823</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR30">FR 30</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR31">FR 31</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR32">FR 32</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#902">902</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR33">FR 33</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR34">FR 34</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR35">FR 35</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1154">1154</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR36">FR 36</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR37">FR 37</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR38">FR 38</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1155">1155</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR39">FR 39</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP1">JP 1</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP2">JP 2</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP3">JP 3</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP4">JP 4</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP5">JP 5</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#790">790</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP6">JP 6</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP7">JP 7</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP8">JP 8</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#743">743</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP9">JP 9</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP10">JP 10</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP11">JP 11</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP12">JP 12</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#699">699</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP13">JP 13</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP14">JP 14</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#812">812</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP15">JP 15</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP16">JP 16</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP17">JP 17</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP18">JP 18</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP19">JP 19</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP20">JP 20</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#825">825</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP21">JP 21</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP22">JP 22</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP23">JP 23</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1003">1003</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP24">JP 24</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP25">JP 25</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP26">JP 26</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1005">1005</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP27">JP 27</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1066">1066</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP28">JP 28</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP29">JP 29</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1007">1007</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP30">JP 30</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1132">1132</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP31">JP 31</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1008">1008</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP32">JP 32</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP33">JP 33</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1016">1016</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP34">JP 34</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP35">JP 35</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP36">JP 36</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP37">JP 37</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP38">JP 38</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#817">817</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP39">JP 39</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1024">1024</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP40">JP 40</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP41">JP 41</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP42">JP 42</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP43">JP 43</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP44">JP 44</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1030">1030</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP45">JP 45</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1032">1032</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP46">JP 46</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1081">1081</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP47">JP 47</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP48">JP 48</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1081">1081</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP49">JP 49</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1082">1082</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP50">JP 50</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#991">991</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP51">JP 51</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP52">JP 52</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1083">1083</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP53">JP 53</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1083">1083</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP54">JP 54</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP55">JP 55</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP56">JP 56</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP57">JP 57</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP58">JP 58</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP59">JP 59</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP60">JP 60</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP61">JP 61</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP62">JP 62</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP63">JP 63</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#874">874</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
          N2836</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP64">JP 64</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1243">1243</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP65">JP 65</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1094">1094</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP66">JP 66</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1094">1094</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP67">JP 67</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1141">1141</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP68">JP 68</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1141">1141</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP69">JP 69</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1141">1141</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP71">JP 71</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP72">JP 72</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1141">1141</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP73">JP 73</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1150">1150</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP74">JP 74</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1014">1014</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP75">JP 75</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP76">JP 76</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1089">1089</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP77">JP 77</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP78">JP 78</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP79">JP 79</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP80">JP 80</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP81">JP 81</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK1">UK 1</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK2">UK 2</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK3">UK 3</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#783">783</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK4">UK 4</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK5">UK 5</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK6">UK 6</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#784">784</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK7">UK 7</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#785">785</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK8">UK 8</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#785">785</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK9">UK 9</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#787">787</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK10">UK 10</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK11">UK 11</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#789">789</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK12">UK 12</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#787">787</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK13">UK 13</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#832">832</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK14">UK 14</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK15">UK 15</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK16">UK 16</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK17">UK 17</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK18">UK 18</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK19">UK 19</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK20">UK 20</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK21">UK 21</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK22">UK 22</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#633">633</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK23">UK 23</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#758">758</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK24">UK 24</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK25">UK 25</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK26">UK 26</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#570">570</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK27">UK 27</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK28">UK 28</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK29">UK 29</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK30">UK 30</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#791">791</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK31">UK 31</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK32">UK 32</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK33">UK 33</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK34">UK 34</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK35">UK 35</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK36">UK 36</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK37">UK 37</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK38">UK 38</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK39">UK 39</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#759">759</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
          N2927</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK40">UK 40</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#796">796</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
          N2927</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK41">UK 41</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2845.html">
          N2845</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK42">UK 42</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#797">797</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK43">UK 43</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2845.html">
          N2845</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK44">UK 44</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK45">UK 45</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#795">795</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK46">UK 46</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2845.html">
          N2845</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK47">UK 47</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK48">UK 48</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK49">UK 49</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#699">699</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK50">UK 50</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#806">806</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK51">UK 51</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#807">807</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK52">UK 52</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK53">UK 53</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#798">798</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK54">UK 54</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK55">UK 55</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#799">799</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK56">UK 56</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK57">UK 57</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#800">800</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK58">UK 58</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#801">801</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK59">UK 59</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK60">UK 60</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK61">UK 61</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK62">UK 62</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK63">UK 63</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK64">UK 64</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK65">UK 65</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK66">UK 66</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK67">UK 67</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK68">UK 68</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK69">UK 69</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#802">802</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK70">UK 70</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#803">803</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK71">UK 71</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#804">804</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK72">UK 72</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#805">805</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/N2932.pdf">
          N2932</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK73">UK 73</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK74">UK 74</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK75">UK 75</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK76">UK 76</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK77">UK 77</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK78">UK 78</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1001">1001</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2930.html">
          N2930</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK79">UK 79</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2930.html">
          N2930</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK80">UK 80</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK81">UK 81</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK82">UK 82</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK83">UK 83</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#808">808</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK84">UK 84</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK85">UK 85</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#940">940</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK86">UK 86</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#809">809</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK87">UK 87</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#810">810</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK89">UK 89</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#811">811</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK90">UK 90</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK91">UK 91</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK92">UK 92</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK93">UK 93</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK94">UK 94</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK95">UK 95</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#746">746</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK96">UK 96</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#628">628</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK97">UK 97</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK98">UK 98</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1055">1055</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK99">UK 99</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK100">UK 100</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK101">UK 101</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#813">813</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK102">UK 102</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK103">UK 103</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#815">815</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/N2933.htm">
          N2933</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK104">UK 104</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK105">UK 105</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK106">UK 106</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK107">UK 107</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK108">UK 108</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#816">816</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK109">UK 109</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK110">UK 110</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK111">UK 111</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK112">UK 112</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK113">UK 113</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK114">UK 114</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK115">UK 115</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#820">820</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK116">UK 116</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#821">821</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK117">UK 117</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#822">822</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK118">UK 118</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK119">UK 119</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#791">791</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK120">UK 120</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK121">UK 121</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK122">UK 122</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK123">UK 123</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK124">UK 124</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK125">UK 125</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK126">UK 126</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK127">UK 127</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK128">UK 128</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK129">UK 129</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#826">826</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK130">UK 130</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#828">828</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK131">UK 131</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">
          N2844</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK132">UK 132</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK133">UK 133</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK134">UK 134</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK135">UK 135</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#829">829</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK136">UK 136</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#830">830</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK137">UK 137</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK138">UK 138</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK139">UK 139</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK140">UK 140</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK141">UK 141</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK142">UK 142</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK143">UK 143</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK144">UK 144</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK145">UK 145</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK146">UK 146</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK147">UK 147</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK148">UK 148</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK149">UK 149</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK150">UK 150</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK151">UK 151</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK152">UK 152</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1064">1064</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK153">UK 153</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK154">UK 154</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK155">UK 155</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK156">UK 156</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK157">UK 157</A></TD>
<TD>editor</TD>
<TD>m,odified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK158">UK 158</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK159">UK 159</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK160">UK 160</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK161">UK 161</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK162">UK 162</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK163">UK 163</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#997">997</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK164">UK 164</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK165">UK 165</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1156">1156</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK166">UK 166</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK167">UK 167</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK168">UK 168</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1065">1065</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK169">UK 169</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#992">992</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK170">UK 170</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1002">1002</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK171">UK 171</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK172">UK 172</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1264">1264</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK173">UK 173</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK174">UK 174</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK175">UK 175</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1157">1157</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK176">UK 176</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK177">UK 177</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK178">UK 178</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK179">UK 179</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1004">1004</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK180">UK 180</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK181">UK 181</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK182">UK 182</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK184">UK 184</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK185">UK 185</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK186">UK 186</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK187">UK 187</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1144">1144</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK188">UK 188</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#993">993</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK189">UK 189</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1066">1066</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK190">UK 190</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1006">1006</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK191">UK 191</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK192">UK 192</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#805">805</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/N2932.pdf">
          N2932</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK193">UK 193</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#994">994</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK194">UK 194</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK195">UK 195</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK196">UK 196</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK197">UK 197</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK198">UK 198</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK199">UK 199</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1015">1015</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK200">UK 200</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK201">UK 201</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK202">UK 202</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK203">UK 203</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK204">UK 204</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1020">1020</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK205">UK 205</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1019">1019</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK206">UK 206</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#975">975</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK207">UK 207</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK208">UK 208</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#978">978</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK209">UK 209</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1026">1026</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK210">UK 210</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1029">1029</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK211">UK 211</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1021">1021</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK212">UK 212</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK213">UK 213</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1027">1027</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK214">UK 214</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1028">1028</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK215">UK 215</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK216">UK 216</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1081">1081</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK217">UK 217</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK218">UK 218</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1170">1170</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK219">UK 219</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK220">UK 220</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#825">825</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK221">UK 221</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK222">UK 222</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1034">1034</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK223">UK 223</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
          N2840</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK224">UK 224</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
          N2840</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK225">UK 225</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK226">UK 226</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1035">1035</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK227">UK 227</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK228">UK 228</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK229">UK 229</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK230">UK 230</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK231">UK 231</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1036">1036</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK232">UK 232</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1037">1037</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK233">UK 233</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1038">1038</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK234">UK 234</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1039">1039</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK235">UK 235</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK236">UK 236</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK237">UK 237</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK238">UK 238</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1040">1040</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK239">UK 239</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1041">1041</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK240">UK 240</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK241">UK 241</A></TD>
<TD>LWG</TD>
<TD>duplicate&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
          N2840</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK242">UK 242</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK243">UK 243</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK244">UK 244</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1042">1042</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK245">UK 245</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK246">UK 246</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1091">1091</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK247">UK 247</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK248">UK 248</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK249">UK 249</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK250">UK 250</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1084">1084</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK251">UK 251</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1009">1009</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK252">UK 252</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK253">UK 253</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK254">UK 254</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK255">UK 255</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK256">UK 256</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK257">UK 257</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK258">UK 258</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1085">1085</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK259">UK 259</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK260">UK 260</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK261">UK 261</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK262">UK 262</A></TD>
<TD>LWG</TD>
<TD>modifed&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK263">UK 263</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1010">1010</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK264">UK 264</A></TD>
<TD>LWG</TD>
<TD>modifed&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK265">UK 265</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1079">1079</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK266">UK 266</A></TD>
<TD>LWG</TD>
<TD>modifed&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK267">UK 267</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK268">UK 268</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK269">UK 269</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK270">UK 270</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#940">940</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK271">UK 271</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1011">1011</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK272">UK 272</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK274">UK 274</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK275">UK 275</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK276">UK 276</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK277">UK 277</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1012">1012</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK278">UK 278</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK279">UK 279</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1051">1051</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK280">UK 280</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK281">UK 281</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1052">1052</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK282">UK 282</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#901">901</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK283">UK 283</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK284">UK 284</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1086">1086</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK285">UK 285</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK286">UK 286</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK287">UK 287</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#788">788</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK288">UK 288</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK289">UK 289</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK290">UK 290</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK291">UK 291</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK292">UK 292</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK293">UK 293</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK294">UK 294</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK295">UK 295</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1053">1053</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK296">UK 296</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK297">UK 297</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK298">UK 298</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK299">UK 299</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK300">UK 300</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK301">UK 301</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1087">1087</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK302">UK 302</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK303">UK 303</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK304">UK 304</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK305">UK 305</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1013">1013</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK306">UK 306</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#N/A">N/A</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
          N2836</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK307">UK 307</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK308">UK 308</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1141">1141</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK309">UK 309</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1142">1142</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK310">UK 310</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1142">1142</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK311">UK 311</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1143">1143</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK312">UK 312</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1145">1145</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK313">UK 313</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#926">926</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK314">UK 314</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK315">UK 315</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK316">UK 316</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#723">723</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK317">UK 317</A></TD>
<TD>LWG</TD>
<TD>modifed&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1014">1014</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK318">UK 318</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK319">UK 319</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#909">909</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK320">UK 320</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK321">UK 321</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK322">UK 322</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1158">1158</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK323">UK 323</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#929">929</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK324">UK 324</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#889">889</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK325">UK 325</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1044">1044</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK326">UK 326</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1045">1045</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK327">UK 327</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1159">1159</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK328">UK 328</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1159">1159</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK329">UK 329</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1046">1046</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK330">UK 330</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK331">UK 331</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1160">1160</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK332">UK 332</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK333">UK 333</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK334">UK 334</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1047">1047</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK335">UK 335</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1048">1048</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK336">UK 336</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1161">1161</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK337">UK 337</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1162">1162</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK338">UK 338</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1163">1163</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK339">UK 339</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1049">1049</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK340">UK 340</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1050">1050</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK341">UK 341</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1164">1164</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK342">UK 342</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1088">1088</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK343">UK 343</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1165">1165</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK344">UK 344</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US1">US 1</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US2">US 2</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#N/A">N/A</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US3">US 3</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US4">US 4</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US5">US 5</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US6">US 6</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US7">US 7</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US8">US 8</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US9">US 9</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US10">US 10</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US11">US 11</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US12">US 12</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US13">US 13</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US14">US 14</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
          N2841</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US15">US 15</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US16">US 16</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#785">785</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US17">US 17</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#786">786</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US18">US 18</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US19">US 19</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US20">US 20</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US21">US 21</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US22">US 22</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US23">US 23</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US24">US 24</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#792">792</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US25">US 25</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US26">US 26</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#793">793</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US27">US 27</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US28">US 28</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US29">US 29</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#762">762</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
          N2927</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US30">US 30</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#762">762</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
          N2927</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US31">US 31</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#752">752</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
          N2927</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US32">US 32</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US33">US 33</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#680">680</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
          N2927</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US34">US 34</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US35">US 35</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US36">US 36</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-10-24&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#717">717</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US37">US 37</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US38">US 38</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US39">US 39</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US40">US 40</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#814">814</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US41">US 41</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#939">939</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.html">
          N2928</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US42">US 42</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#817">817</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US43">US 43</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US44">US 44</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US45">US 45</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#818">818</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US46">US 46</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">
          N2844</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US49">US 49</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US50">US 50</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#819">819</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US51">US 51</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US52">US 52</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US53">US 53</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#824">824</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US54">US 54</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US55">US 55</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US56">US 56</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US57">US 57</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US58">US 58</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US59">US 59</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US60">US 60</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-07-18&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#827">827</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US61">US 61</A></TD>
<TD>LWG</TD>
<TD>duplicate&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#N/A">N/A</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US62">US 62</A></TD>
<TD>LWG</TD>
<TD>duplicate&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#N/A">N/A</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US63">US 63</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1151">1151</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US64">US 64</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US65">US 65</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1075">1075</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US66">US 66</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1017">1017</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US67">US 67</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US68">US 68</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US69">US 69</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US70">US 70</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1018">1018</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US71">US 71</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US72">US 72</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#817">817</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US73">US 73</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#750">750</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2845.html">
          N2845</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US74.1">US 74.1</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1075">1075</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US74.2">US 74.2</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US75">US 75</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
          N2840</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US77">US 77</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1166">1166</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US78">US 78</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1031">1031</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US79">US 79</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#932">932</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US80">US 80</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US81">US 81</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#934">934</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US82">US 82</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US83">US 83</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US84">US 84</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1140">1140</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US85">US 85</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1141">1141</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US86">US 86</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1142">1142</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US87">US 87</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1143">1143</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US88">US 88</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1146">1146</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US89">US 89</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US90">US 90</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#908, 1147">908, 1147</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US91">US 91</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1043">1043</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">
          N2925</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US92">US 92</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US93">US 93</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US94">US 94</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US95">US 95</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US96">US 96</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US97">US 97</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2009-03-06&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2802.html">
          N2802</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US98">US 98</A></TD>
<TD>LWG</TD>
<TD>duplicate&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
</TBODY>
</TABLE>
<HR><A NAME="OPEN"></A><H3><U>UNRESOLVED COMMENTS:</U></H3>
<P>
    The following table lists the comments for which no resolution has
    yet been proposed.
   </P>
<TABLE border="1" cellspacing="0" cellpadding="4" frame="box">
<THEAD>
<TR>
<TH>ID</TH>
<TH>Responsible</TH>
<TH>Issue</TH>
</TR>
</THEAD>
<TBODY>
<TR>
<TD><A HREF="
          #UK3">UK 3</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#783">783</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK6">UK 6</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#784">784</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK11">UK 11</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#789">789</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK12">UK 12</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#787">787</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK23">UK 23</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#758">758</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK42">UK 42</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#797">797</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK53">UK 53</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#798">798</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK101">UK 101</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#813">813</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK136">UK 136</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#830">830</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US40">US 40</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#814">814</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US45">US 45</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#818">818</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR3">FR 3</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR4">FR 4</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR6">FR 6</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR39">FR 39</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK148">UK 148</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK150">UK 150</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK160">UK 160</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK184">UK 184</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK198">UK 198</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK285">UK 285</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK286">UK 286</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK288">UK 288</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK289">UK 289</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK292">UK 292</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK293">UK 293</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK321">UK 321</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK332">UK 332</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US4">US 4</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US5">US 5</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US49">US 49</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US69">US 69</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US89">US 89</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE2">DE 2</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1153">1153</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE18">DE 18</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1097,1098 ">1097,1098 </A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR2">FR 2</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1156">1156</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FR35">FR 35</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1154">1154</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP31">JP 31</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1008">1008</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP38">JP 38</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#817">817</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP65">JP 65</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1094">1094</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP66">JP 66</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1094">1094</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP76">JP 76</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1089">1089</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP77">JP 77</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK165">UK 165</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1156">1156</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK172">UK 172</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1264">1264</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK175">UK 175</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1157">1157</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK187">UK 187</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1144">1144</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK218">UK 218</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1170">1170</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK222">UK 222</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1034">1034</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK265">UK 265</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1079">1079</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK270">UK 270</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#940">940</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK271">UK 271</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1011">1011</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK281">UK 281</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1052">1052</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK314">UK 314</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK322">UK 322</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1158">1158</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK327">UK 327</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1159">1159</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #UK328">UK 328</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1159">1159</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US63">US 63</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1151">1151</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US72">US 72</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#817">817</A>&#160;
       </TD>
</TR>
</TBODY>
</TABLE>
<HR><A name="RR"></A><H2><U>ALL COMMENTS</U></H2>
<TABLE border="1" cellspacing="0" cellpadding="4" frame="box">
<THEAD>
<TR>
<TH width="4%" align="center">ID</TH>
<TH width="6%" align="center">Ref</TH>
<TH width="30%" align="center">Comment</TH>
<TH width="30%" align="center">Proposed Resolution</TH>
<TH width="6%" align="center">Owner</TH>
<TH width="4%" align="center">Issue</TH>
<TH width="20%" align="center">Disposition</TH>
</TR>
</THEAD>
<TBODY>
<TR>
<TD valign="top"><A NAME="FR1">FR 1</A></TD>
<TD valign="top">
General Comment
&#160;
  </TD>
<TD valign="top">
        Interactions between several
        new features appear obscure, and very few examples are
        offered to guide understanding of the formal text on
        interaction between these new additions.
        We worry about the complexity
        of the programming model so created.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Need more information from NB, including a suggested resolution, in order
to respond effectively to this comment.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US1">US 1</A></TD>
<TD valign="top">
1-16
&#160;
  </TD>
<TD valign="top">
        The
        active issues identified in WG21 N2803, C++ Standard Core
        Language Active Issues, must be addressed and appropriate
        action taken.
        <BR>
        <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html">
        http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html</a>
&#160;
  </TD>
<TD valign="top">
        Appropriate action would include making changes to the CD,
        identifying an issue as not requiring a change to the CD,
        or deferring the issue to a later point in time.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA1">CA 1</A></TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">
        There are quite a number of defects for the current CD
        recorded in SC22/WG21-N2803 and N2806
&#160;
  </TD>
<TD valign="top">
        Consider these comments and update ISO/IEC CD 14882
        accordingly
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE1">DE 1</A></TD>
<TD valign="top">
1 through 16
&#160;
  </TD>
<TD valign="top">
        DE-1 Consider addressing a significant part of the
        unresolved core language issues presented in WG21 document
        N2791 "C++ Standard Core Language Active Issues, Revision
        59", available at
        http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
        .
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH2">CH 2</A></TD>
<TD valign="top">
all
&#160;
  </TD>
<TD valign="top">
        The issues on the issues lists shall be addressed before
        the standard becomes final.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US3">US 3</A></TD>
<TD valign="top">
all
&#160;
  </TD>
<TD valign="top">
        Latin abbreviations are presented incorrectly.
&#160;
  </TD>
<TD valign="top">
        Italicize all
        Latin abbreviations, append commas after each occurrence of
        <i>i.e</i>. and <i>e.g.</i>, and remove extraneous space
        after each such abbreviation.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The "Chicago Manual of Style" says that i.e. and e.g. are never
italicized and always followed by a comma, so that's how they now
appear.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR3">FR 3</A></TD>
<TD valign="top">
1 [intro.scope]

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        C++ is split at the end of line.
&#160;
  </TD>
<TD valign="top">
        
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US4">US 4</A></TD>
<TD valign="top">
1.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        There is a bad line break in
        "C++".
&#160;
  </TD>
<TD valign="top">
        
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK1">UK 1</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/214">
     [214]
    </A></TD>
<TD valign="top">
1.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        List of additional facilities over C has
        been extended with this standard, so should be mentioned in
        the introductory material.
&#160;
  </TD>
<TD valign="top">
        Add the following to the list in 1.1p2:
        atomic operations concurrency alignment control
        user-defined literals attributes
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This list is highlights, not all differences. Okay as is.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR4">FR 4</A></TD>
<TD valign="top">
1.2 [intro.refs]

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        Is the lack of reference to ISO/CEI 9899/AC3:2007
        voluntary?
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK2">UK 2</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/215">
     [215]
    </A></TD>
<TD valign="top">
1.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        <span lang="en-US">We recommend taking the latest update to
        each listed standard, yet the C standard is quite
        deliberately held back to the 1990 version without
        comment.+</span>
&#160;
  </TD>
<TD valign="top">
        ... not sure ...
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
1.2 (Normative references) cites 9899:1999, 9899:1999/Corl.1:2001, and
9899:1999/Cor.2:2004, which collectively constitute C99.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK3">UK 3</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/217">
     [217]
    </A></TD>
<TD valign="top">
1.3.1
&#160;
  </TD>
<TD valign="top">
        The definition of an argument does not seem
        to cover many assumed use cases, and we believe that is not
        intentional.
&#160;
  </TD>
<TD valign="top">
        Revise the
        definition of argument to answer question such as: Are
        lambda-captures arguments? Are type names in a throw-spec
        arguments? 'Argument' to casts, typeid, alignof, alignas,
        decltype and sizeof? why in x[arg] : arg is not an
        agrument, but the value forwarded to operator[]() is ? Does
        not apply to operators as call-points not bounded by
        parenthises ? Similar for copy initialization and
        conversion? what are Deduced template 'arguments'? what are
        'default arguments'? can attributes have arguments? what
        about concepts, requires clauses and concept_map
        instantiations? What about user-defined literals where
        parens are not used?
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#783">783</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK4">UK 4</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/216">
     [216]
    </A></TD>
<TD valign="top">
1.3.3
&#160;
  </TD>
<TD valign="top">
        This definition is essentially worthless,
        as it says nothing about what distinguished a diagnostic
        message from other output messages provided by the
        implementation
&#160;
  </TD>
<TD valign="top">
        ... add
        something about the diagnostic message being a message
        issues by the implementation when translating a program
        that violates the rules of the standard. ...
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Characterizing the output of a translator is essentially
a quality-of-implementation issue and beyond the scope of the Standard.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR5">FR 5</A></TD>
<TD valign="top">
1.3.4
        [defns.
        dynamic.type]
&#160;
  </TD>
<TD valign="top">
        "The dynamic type of an rvalue expression is its static
        type." Is this true with rvalue references?
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#690">690</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US5">US 5</A></TD>
<TD valign="top">
1.3.5
&#160;
  </TD>
<TD valign="top">
        The wording is unclear as to whether it is the input or
        the implementation "that is not a well-formed program".
&#160;
  </TD>
<TD valign="top">
        Reword to clarify that it is the input that is here
        considered not well-formed.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR6">FR 6</A></TD>
<TD valign="top">
1.3.6
        [defns.
        impl.defined]
&#160;
  </TD>
<TD valign="top">
        There is a page break between the title and the
        paragraph.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR7">FR 7</A></TD>
<TD valign="top">
1.3.13
        [defns.
        undefined]
&#160;
  </TD>
<TD valign="top">
        [intro.execution]/5 explicitly allows non causal
        undefined behaviour,
&#160;
  </TD>
<TD valign="top">
        Adding it to the note outlying possible undefined
        behaviours.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This is covered by the first alternative in the note, "ignoring the
situation completely with unpredictable results".
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US6">US 6</A></TD>
<TD valign="top">
1.3.14
&#160;
  </TD>
<TD valign="top">
        Unspecified behavior does not clearly state whether or not
        undefined behavior is permitted. (The standard says that
        "usually, the range of possible behaviors is delineated",
        but what happens if the range is not delineated? Is a
        crash, or worse, allowed?) 
&#160;
  </TD>
<TD valign="top">
        Clearly state whether or not
        Unspecified behavior includes undefined behavior.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The cited text is in a note and thus non-normative.  The acceptable
range for unspecified behavior is a quality-of-implementation issue.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR8">FR 8</A></TD>
<TD valign="top">
1.4
        [intro.
        compliance]

    &#182;
    
8
&#160;
  </TD>
<TD valign="top">
        The paragraph as its stands seems to require that
        violations of the ODR (which make a program ill-formed) are
        required to be diagnosed if the program also uses an
        extension which defines some cases of ODR.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Yes, that seems to be the intention. That's the mechanism for
extensions: issue a diagnostic and then do the extension.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK5">UK 5</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/1">
     [1]
    </A></TD>
<TD valign="top">
1.5
&#160;
  </TD>
<TD valign="top">
        Missing checklist of implementation defined
        behaviour (see ISO/IEC TR 10176, 4.1.1p6)
&#160;
  </TD>
<TD valign="top">
        Provide a new annex with the missing
        checklist
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK6">UK 6</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/2">
     [2]
    </A></TD>
<TD valign="top">
1.5
&#160;
  </TD>
<TD valign="top">
        Missing annex describing potential
        incompatibility to previous edition of the standard (see
        ISO/IEC TR 10176, 4.1.1p9)
&#160;
  </TD>
<TD valign="top">
        Provide a new annex with the missing
        documentation. See n2733(08-0243) for a starting point
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#784">784</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US7">US 7</A></TD>
<TD valign="top">
1.5

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        There is no mention of Clause 17.
&#160;
  </TD>
<TD valign="top">
        Include Clause 17 among the list of Clauses that specify
        the Standard Library.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US8">US 8</A></TD>
<TD valign="top">
1.5

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The paragraph
        omits to mention concepts and concept maps among its list
        of entities defined in the Standard Library. 
&#160;
  </TD>
<TD valign="top">
        Mention concepts and concept maps among the list of
        entities.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US9">US 9</A></TD>
<TD valign="top">
1.6

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The
        syntax description does not account for lines that wrap.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US10">US 10</A></TD>
<TD valign="top">
1.7

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        The term thread is used before
        defined.
&#160;
  </TD>
<TD valign="top">
        <font color="#000000">R</font>eference 1.10 [intro.multithread].
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US11">US 11</A></TD>
<TD valign="top">
1.7

    &#182;
    
&#182; 3 last sent.
&#160;
  </TD>
<TD valign="top">
        The phrase &#8220;threads of execution&#8221; should be
        accompanied by a reference to [intro.multithread].
&#160;
  </TD>
<TD valign="top">
        Insert the recommended reference.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US12">US 12</A></TD>
<TD valign="top">
1.7

    &#182;
    
&#182; 3 first sent.
&#160;
  </TD>
<TD valign="top">
        A memory location is not an object as the sentence
        claims.
&#160;
  </TD>
<TD valign="top">
        Clarify that a memory location &#8220;holds&#8221; an
        object rather than that it &#8220;is&#8221; an object.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
This is the definition of the term &#8220;memory location&#8221; for
reference in the following text. The current wording is appropriate for
that usage; the formatting will be changed to indicate that the term is
being defined.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US13">US 13</A></TD>
<TD valign="top">
1.7

    &#182;
    
&#182; 3 last sent.
&#160;
  </TD>
<TD valign="top">
        It is unclear what is meant by memory locations that are
        "separate": are they distinct? non-overlapping? how much
        "separation" is needed?
&#160;
  </TD>
<TD valign="top">
        Provide either a better definition of
        &#8220;separate&#8221; or reword (this and subsequent
        paragraphs) to avoid this term.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The current text is clear enough: &#8220;separate&#8221; in the sense
of &#8220;distinct&#8221; is common usage elsewhere in the Standard.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US14">US 14</A></TD>
<TD valign="top">
1.7

    &#182;
    
&#182; 4
&#160;
  </TD>
<TD valign="top">
        The phrase "no matter what the sizes of the intervening
        bit-fields happen to be" contradicts the claim of
        separation "by a zero-length bit-field declaration".
&#160;
  </TD>
<TD valign="top">
        Delete the &#8220;no matter&#8230;&#8221; phrase, or
        resolve the contradiction in a different way.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US15">US 15</A></TD>
<TD valign="top">
1.7

    &#182;
    
&#182; 5
&#160;
  </TD>
<TD valign="top">
        A struct does not &#8220;contain&#8221; memory
        locations.
&#160;
  </TD>
<TD valign="top">
        Reword so that a struct is &#8220;held in&#8221; one or
        more memory locations.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The phrasing is consistent with the definition of &#8220;memory
location&#8221; given in paragraph 3.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US16">US 16</A></TD>
<TD valign="top">
1.9
&#160;
  </TD>
<TD valign="top">
        The discussion of observable behavior in 1.9 is not
        consistent with the addition of threads to the language.
        Volatile reads and writes and other observable actions no
        longer occur in a single "sequence&#8221;.
&#160;
  </TD>
<TD valign="top">
        Remove/replace various occurrences of "sequence" in 1.9.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#785">785</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK8">UK 8</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/222">
     [222]
    </A></TD>
<TD valign="top">
1.9

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
        With parallel execution there is no longer
        the idea of a single execution sequence for a program.
        Instead, a program may be considered a set of exectution
        sequences.
&#160;
  </TD>
<TD valign="top">
        Update first sentance as: A conforming
        implementation executing a well-formed program shall
        produce the same observable behavior as one of the possible
        SETS OF execution sequences of the corresponding instance
        of the abstract machine CONFORMING TO THE MEMORY MODEL
        (1.10) with the same program and the same input.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#785">785</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK7">UK 7</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/218">
     [218]
    </A></TD>
<TD valign="top">
1.9

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        Does the term 'sequence' imply all
        reads/writes through volatile memory much be serialized,
        and cannot occur in parallel on truly parallel hardware?
        Allow for multiple concurrent sequences where each sequence
        is constrained by this observable behaviour rule, and
        multiple sequences are constrained by the memory model and
        happens-before relationships defined in 1.10
&#160;
  </TD>
<TD valign="top">
        Replace 'sequence' with 'sequences'.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#785">785</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR9">FR 9</A></TD>
<TD valign="top">
1.9
        [intro.execution]

    &#182;
    
16
&#160;
  </TD>
<TD valign="top">
        This example use int *v while the other examples seems
        to use notation like int* v.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US17">US 17</A></TD>
<TD valign="top">
1.10

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        This definition of
        &#8220;thread&#8221; is poor, and assumes the user already
        knows what multi-threaded means (probably true!). In
        particular, it does not deal adequately with the concept
        that all threads share the same address space.
&#160;
  </TD>
<TD valign="top">
        Replace first
        sentence of para 1 as follows:
<BLOCKQUOTE>
        Under a hosted
        implementation, a C++ program can have more than one thread
        of execution (a.k.a. thread) running concurrently. Each
        thread is a single flow of control within a program.
        Anything whose address may be determined by a thread,
        including but not limited to static objects, storage
        obtained via new or by any dynamic allocator, directly
        addressable storage obtained through implementation-defined
        functions, and automatic variables, are accessible to all
        threads in the same program.
</BLOCKQUOTE>
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#786">786</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK9">UK 9</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/133">
     [133]
    </A></TD>
<TD valign="top">
2.1

    &#182;
    
2, 4
&#160;
  </TD>
<TD valign="top">
        Undefined behaviour is a drastic way to
        silently ignore minor issues. The cases in this paragraph
        could be easily defined. In this case opt for conditionally
        supported behaviour, which mandates a diagnostic if the
        compiler is not prepared to handle the syntax consistently.
&#160;
  </TD>
<TD valign="top">
        Replace
        undefined behaviour with conditionally supported behavior.
        Conditional behaviour may be implementation defined,
        although suggest there is a reasonable default in each
        case. For creating a universal-character name, splice text
        to create a universal-character. In the case of a file
        ending without a newline, treat as if the newline was
        implictly added, with an empty line to follow if the last
        character was a back-slash.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#787">787</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The undefined behavior with respect to creation of universal character
names is intended to facilitate a variety of implementation techniques
for supporting extended characters by making it impossible in a well-defined
program to determine which technique was actually used.  There was no
consensus to change that approach at this time.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK10">UK 10</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/134">
     [134]
    </A></TD>
<TD valign="top">
2.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Implementation
        defined seems unnecessarily burdensome for negligible gain.
        I am yet to see code that depended on whether non-empty
        sequences of whitespace were concatenated. Better left
        unspecified.
&#160;
  </TD>
<TD valign="top">
        How the compiler treats non-empty sequences
        of whitespace should be left unspecified, rather than
        implementation-defined.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR10">FR 10</A></TD>
<TD valign="top">
2.1 [lex.phases]/5
        and
        2.2 [lex.charset]/3
&#160;
  </TD>
<TD valign="top">
        [defns.multibyte] "the
        extended character set."
        <BR><BR>[lex.charset]/3 cited below
        implies that there is an extended character set per locale.
        <BR><BR>[lex.phases]/5 "Each [...]
        universal-character-name [...] is converted to the
        corresponding member of the execution character set"
        <BR><BR>[lex.charset]/3 "The values
        of the members of the execution character sets are
        implementation defined, and any additional members are
        locale-specific."
        <BR><BR>Together they seem to imply
        that what is locale-specific is if a value is valid or not
        for the current locale, not the representation of a given
        universal character.
        <BR><BR>This is not the behaviour of
        at least some compilers I've access to which are allowing
        different codes for the same abstract character in
        different locale. During phase 5, they are using an
        implementation defined char set.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#788">788</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK11">UK 11</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/135">
     [135]
    </A></TD>
<TD valign="top">
2.3
&#160;
  </TD>
<TD valign="top">
        Trigraphs are a complicated solution to an
        old problem, that cause more problems than they solve in
        the modern environment. Unexpected trigraphs in string
        literals and occasionally in comments can be very confusing
        for the non-expert.
&#160;
  </TD>
<TD valign="top">
        Deprecate the whole of 2.3 and move it to
        appendix D.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#789">789</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK12">UK 12</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/137">
     [137]
    </A></TD>
<TD valign="top">
2.4, 2.8

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        This undefined
        behaviour in token concatenation is worrying and we believe
        hard to justify. An implementation should either support
        this in a defined way, or issue a diagnosic. Documenting
        existing practice should not break existing
        implementations, although unconditionally requiring a
        diagnostic would lead to more portable programs.
&#160;
  </TD>
<TD valign="top">
        Replace undefined behaviour with
        conditionally supported behaviour with implementation
        defined semantics.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#787">787</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US18">US 18</A></TD>
<TD valign="top">
2.4

    &#182;
    
&#182; 2
&#160;
  </TD>
<TD valign="top">
        The paragraph begins with an empty line.
&#160;
  </TD>
<TD valign="top">
        Delete the empty line.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR11">FR 11</A></TD>
<TD valign="top">
2.4
[lex.pptokens]

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        There are spurious empty lines.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR12">FR 12</A></TD>
<TD valign="top">
2.5 [lex.digraph]
and 2.11
[lex.key]/2
&#160;
  </TD>
<TD valign="top">
        The alternative representations are reserved as such
        even in attribute. Is that what is wanted?
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI2">FI 2</A></TD>
<TD valign="top">
2.5

    &#182;
    
Table 2
&#160;
  </TD>
<TD valign="top">
        Add eq, for spelling out == in order to distinguish it
        from the assignment operator.
&#160;
  </TD>
<TD valign="top">
        See eq-keyword.doc, eq-keyword.ppt
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Adding a new keyword would break existing code that uses <TT>eq</TT> as
an identifier.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK13">UK 13</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/138">
     [138]
    </A></TD>
<TD valign="top">
2.9

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        This text is confusing in isolation, as it
        implies pp-numbers do not have a value in translation phase
        4 when evaluating #if preprocessor expressions.
&#160;
  </TD>
<TD valign="top">
        Add a note with a cross-refernce to 16.1
        that a pp-number may briefly acquire a value during
        translation phase 4 while evaluating #if expressions.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#832">832</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK14">UK 14</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/395">
     [395]
    </A></TD>
<TD valign="top">
2.11

    &#182;
    
table 3
&#160;
  </TD>
<TD valign="top">
        The table is
        nearly sorted, but not quite. It was sorted in previous
        versions of the standard.
&#160;
  </TD>
<TD valign="top">
        Sort the table.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP1">JP 1</A></TD>
<TD valign="top">
2.11

    &#182;
    
Table 3
&#160;
  </TD>
<TD valign="top">
        Keywords in the table are listed disorderly. Also, a
        part of a frame of the table is not drawn.
&#160;
  </TD>
<TD valign="top">
        Sort it in alphabetical order.
        Complete the table frame.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US19">US 19</A></TD>
<TD valign="top">
2.13.1

    &#182;
    
Table 5,
rows &#8220;l or
L&#8221; and &#8220;ll or
        LL&#8221;
&#160;
  </TD>
<TD valign="top">
        The final entry in the last column (&#8220;unsigned long
        int&#8221;) is incorrect.
&#160;
  </TD>
<TD valign="top">
        Replace the incorrect entries by &#8220;unsigned long
        long int&#8221;.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US20">US 20</A></TD>
<TD valign="top">
2.13.1,
        2.13.3
&#160;
  </TD>
<TD valign="top">
        Long strings of digits in
        literals are a continuing problem in the production and
        maintenance of programs.
&#160;
  </TD>
<TD valign="top">
        Adopt the 1983 technology of Ada and use underscores to
        separate digits. <font color="#000080" size="2" style="font-size: 11pt"><u><a href="http://www.google.com/url?sa=D&amp;q=http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2007%2Fn2281.html" target="_blank">http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2281.html</a></u></font>
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This was already considered and rejected.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK15">UK 15</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/139">
     [139]
    </A></TD>
<TD valign="top">
2.13.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        Inconsistency between definition of a
        multicharacter literal and a wide character literal
        containing multiple c-chars.
&#160;
  </TD>
<TD valign="top">
        Define the term
        multicharacter wide literal for a wchar_t literal
        containing multiple elements, and specify its type is
        integer (or wider)
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The current specification is well-defined, and there was no consensus
for changing it.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK16">UK 16</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/140">
     [140]
    </A></TD>
<TD valign="top">
2.13.2

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Not immediately clear why the question mark
        needs escaping. A note would help.
&#160;
  </TD>
<TD valign="top">
        Add a note
        explaining that the ? character may need escaping to avoid
        accidentally creating a trigraph.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP2">JP 2</A></TD>
<TD valign="top">
2.13.4

    &#182;
    
        1<sup>st</sup> <font size="2" style="font-size: 11pt">para, 2<sup>nd</sup> line</font>
&#160;
  </TD>
<TD valign="top">
        Typo, R"..." should be
        R"[...]"
&#160;
  </TD>
<TD valign="top">
        Correct typo.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP3">JP 3</A></TD>
<TD valign="top">
2.13.4

    &#182;
    
2<sup>nd</sup> paragraph
&#160;
  </TD>
<TD valign="top">
        We think that the explanation of d-char-sequence is not
        enough.
&#160;
  </TD>
<TD valign="top">
        Add
        the following.
        <OL>
          <LI>
            Add the
            following to the explanation of d-char-sequence, more
            easily to understand.
        <BR><BR>...prefix is a
        raw string literal.
        The
        d-char-sequence is used as delimiter.
        The terminating
        d-char-sequence of ...</LI><BR>
          <LI>
            Add the
            following note that there are square brackets in
            r-char-sequence.
        <BR><BR>[<I>Note:</I>
        <PRE>
  char foo[] =
  R"<i>delimiter</i>[[a-z] specifies a range
  which matches any lowercase letter
  from "a" to "z".]<i>delimiter</i>";
</PRE>
the expression
statement behaves exactly the same as
<PRE>
  char foo[] = "[a-z] specifies a range
  which matches any lowercase letter
  from \"a\" to \"z\".";
</PRE>
&#8212;<I>end note</I>]</LI></OL>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP4">JP 4</A></TD>
<TD valign="top">
2.13.4

    &#182;
    
3<sup>rd</sup> <font size="2" style="font-size: 11pt">para, 
        1st line of
        example</font>
&#160;
  </TD>
<TD valign="top">
        Typo. Lack of a necessary backslash in the first line of
        the example as follows:
        <BR>
        <PRE>
  const char *p = R"[a
  b
  c]";
        </PRE>
        should be
        <BR>
        <PRE>
  const char *p = R"[a\
  b
  c]";
</PRE>
&#160;
  </TD>
<TD valign="top">
        Correct typo.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US21">US 21</A></TD>
<TD valign="top">
2.13.4

    &#182;
    
&#182; 3
&#160;
  </TD>
<TD valign="top">
        The paragraph, marked as a Note, contains an embedded
        example not marked as such.
&#160;
  </TD>
<TD valign="top">
        Denote the code (and perhaps also its commentary) as an
        Example.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Marking things as Note or Example distinguishes them from normative
text. Examples in Notes do not need to be marked.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US22">US 22</A></TD>
<TD valign="top">
2.13.4

    &#182;
    
&#182; 3
&#160;
  </TD>
<TD valign="top">
        The code does not have the effect predicted by its
        accompanying narrative.
&#160;
  </TD>
<TD valign="top">
        Append a backslash to the first line of the code.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP5">JP 5</A></TD>
<TD valign="top">
2.13.4

    &#182;
    
        11<sup>th</sup> <font size="2" style="font-size: 11pt">para, Table 7</font>
&#160;
  </TD>
<TD valign="top">
        It is not explicit how to combine raw-string and
        non-raw-string.
&#160;
  </TD>
<TD valign="top">
        Add rules containing raw-string in the table 7.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#790">790</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR13">FR 13</A></TD>
<TD valign="top">
2.13.4
        [lex.string]

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Shouldn't the assert be
        <PRE>
  assert(std::strcmp(p, "a\nb\nc") == 0);
</PRE>
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The assert is correct but the preceding raw string is wrong. See
<A href="#JP4">JP 4</A>.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK17">UK 17</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/141">
     [141]
    </A></TD>
<TD valign="top">
2.13.4

    &#182;
    
10
&#160;
  </TD>
<TD valign="top">
        It would be
        preferred for attempts to modify string literals to be
        diagnosable errors. This is not possible due to the
        deprecated implicit conversion to pointer to
        null-terminated character sequence of non-const characters.
        If this deprecated conversion were remove (see other
        comments) then string literals are always accessed through
        const types, and the compiler can enforce the no
        modification rule. The only exception would be using
        const_cast to cast away constness, but this is already
        covered under the const_cast rules so needs no further
        detail here.
&#160;
  </TD>
<TD valign="top">
        (asssuming deprecated conversion to
        non-const array is removed or can be turned off) Strike the
        sentence on undefined behaviour.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The specification covers all attempts to modify the contents of a
string literal, including via a pointer to the string when it is not
apparent that a string literal is the target. This is consistent with
the general treatment of const objects.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK18">UK 18</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/142">
     [142]
    </A></TD>
<TD valign="top">
2.13.4
&#160;
  </TD>
<TD valign="top">
        The addition of
        static_assert (7p4) to the language raises the need to
        concatenate string representations of integral constant
        expressions (typically from a sizeof or alignof expression)
        with narrow string literals to provide an informative error
        message. There is no need to support arbitrary constant
        expressions and especially not floating point values or
        formatting flags. Likewise, the need is purely to support
        static_assert so only narrow string literal support is
        required, although generalizing to other literal types
        would be useful.
&#160;
  </TD>
<TD valign="top">
        Define a syntax to support string-ization
        of integral constant expressions in a form eligible for
        string literal concatenation, 2.13.4p6. Suggested syntax:
        I" integral-constant-expression ". There is no raw variant,
        although it could combine with type specifier in the same
        way that the R prefix does, supporting u8I, uI, UI and LI.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus to adopt this new functionality at this
point in the standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK19">UK 19</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/143">
     [143]
    </A></TD>
<TD valign="top">
2.13.4
&#160;
  </TD>
<TD valign="top">
        The grammar for string literal is becoming
        unwieldy and could easily be refactored into the type
        optional specifier and the string contents.
&#160;
  </TD>
<TD valign="top">
        Refactor
        string-literal grammar as: (note - current Drupal view
        loses formatting which is vital to clearly read the
        grammar) string-literal: string-literal-type-specifierOPT
        string-literal-body string-literal-type-specifier: one of
        u8 u U L string-literal-body: " s-char-sequenceOPT " R
        raw-string
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
The resolution for core language issue 790 effectively implements the suggested
change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR14">FR 14</A></TD>
<TD valign="top">
3 [basic]

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
        "In general it is necessary to determine whether a name
        denotes one of these entities before parsing the program
        that contains it."
&#160;
  </TD>
<TD valign="top">
        Would prefer
        <BR><BR>"... before continuing to
        parse the program that contains it."
        <BR><BR>or even
        <BR><BR>"... to complete the parsing
        of the program that contains it."
        <BR><BR>as some names denotes entities declared after the first
        occurrence.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR15">FR 15</A></TD>
<TD valign="top">
3 [basic]

    &#182;
    
8
&#160;
  </TD>
<TD valign="top">
        /operator-function-id/,
        /conversion-function-id/, /template-id/ are followed by a
        space and then a "s" while usually such production names
        aren't followed by a space when put in plural (see
        /identifier/).
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK20">UK 20</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/209">
     [209]
    </A></TD>
<TD valign="top">
3
&#160;
  </TD>
<TD valign="top">
        Chapter 3
        ("Basic concepts") provides common definitions used in the
        rest of the document. Now that we have concepts as a
        primary feature, the title of this chapter can be confusing
        as it does not refer to the language feature but to
        definitions used in the document.
&#160;
  </TD>
<TD valign="top">
        Change the title to "Basic definitions".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK21">UK 21</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/359">
     [359]
    </A></TD>
<TD valign="top">
3

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        Concepts is now the name of a specific
        feature of the language, the term now risks confusion and
        ambiguity when used in the more general sense.
&#160;
  </TD>
<TD valign="top">
        Rename the chapter Basic ???. THe note in
        p2 specifically needs similar rewording
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK22">UK 22</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/362">
     [362]
    </A></TD>
<TD valign="top">
3

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        References are
        frequently considered variables, but this definition only
        applies to objects.
&#160;
  </TD>
<TD valign="top">
        Add "or reference" after both uses of
        "object"
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#633">633</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK23">UK 23</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/277">
     [277]
    </A></TD>
<TD valign="top">
3.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        alias-declarations are not definitions and should be added
        to the list
&#160;
  </TD>
<TD valign="top">
        Add alias-declaration after typedef
        declaration.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#758">758</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK24">UK 24</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/360">
     [360]
    </A></TD>
<TD valign="top">
3.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The current
        words suggest the declaration of a static integral constant
        data member of a class cannot be a definition. Trying to
        fix this wording in-place will be verbose and risk raising
        more confusion than it solves, so suggest a footnote to
        call out the special case
&#160;
  </TD>
<TD valign="top">
        Add a footnote attached to the static data
        membmer rule: *static data member delcarations of intergral
        type may also be definitions if a constant integral
        expression is provided for an initializer.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The in-class declaration of such a static data member is, in fact, not
a definition; an out-of-class definition must be provided if the member
is "used" as described in 3.2.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK25">UK 25</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/361">
     [361]
    </A></TD>
<TD valign="top">
3.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Example is
        misleading as implicitly defined default constructor uses
        default initialization, not value initialization, for
        non-static data members. In the case of std::String this
        makes no difference, but it makes a big difference for
        fundamental types and pointers.
&#160;
  </TD>
<TD valign="top">
        Remove the : s() from the illustrated
        default constructor: struct C { std::string s; C() { }
        C(const C&amp; x): s(x.s) { } C&amp; operator=(const C&amp;
        x) { s = x.s; return *this; } ~C() { } };
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK26">UK 26</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/363">
     [363]
    </A></TD>
<TD valign="top">
3.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        THe one
        definition rule should cover references, and unless the
        term 'variable' is extended to cover references the list in
        this paragraph is incomplete.
&#160;
  </TD>
<TD valign="top">
        Either include references in the definition
        of 'variable' (see earlier comment) or add reference to the
        list in this paragraph.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#570">570</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK27">UK 27</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/364">
     [364]
    </A></TD>
<TD valign="top">
3.2

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        A class type
        must be complete when catching exceptions, even by
        reference or pointer. See 15.3.
&#160;
  </TD>
<TD valign="top">
        Add "when used in an exception-handler
        (15.3)" to the list.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR16">FR 16</A></TD>
<TD valign="top">
3.3
        [Declarative
        regions and scopes.]
&#160;
  </TD>
<TD valign="top">
        The scope of function
        parameters is defined, but what is the scope of template
        parameters?
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#481">481</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK28">UK 28</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/365">
     [365]
    </A></TD>
<TD valign="top">
3.3.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Class templates
        are not classes, so we should include this case.
&#160;
  </TD>
<TD valign="top">
        ammend "class" to "class or class template"
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK29">UK 29</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/366">
     [366]
    </A></TD>
<TD valign="top">
3.3.10

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        operators and conversion functions do not
        have names, yet are susceptible to 'name hiding' within a
        class - indeed we rely on this for the implicitly declared
        copy-assignment operator.
&#160;
  </TD>
<TD valign="top">
        Add the
        additional phrase "The declaration of an operator or
        conversion function in a derived class (Clause 10) hides
        the declaration of an operator or conversion function of a
        base class of the same operator or type;"
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
These entities do, in fact, have names, as described in 3&#182;4.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR17">FR 17</A></TD>
<TD valign="top">
3.5 [Program
and linkage]
&#160;
  </TD>
<TD valign="top">
        This section does not specify
        whether concept names have linkage.
        Do they or not? If concept
        names do not have linkage, then a note is appropriate, and
        that would be a bit surprising and curious. What is the
        rationale?
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#791">791</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK30">UK 30</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/367">
     [367]
    </A></TD>
<TD valign="top">
3.5

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        This paragraph implies concepts have no
        linkage (do they need it?) and that the entities behind
        names without linkage cannot be used in other scopes. This
        maybe a bigger problem for concept maps?
&#160;
  </TD>
<TD valign="top">
        Add a note to clarify that concepts don't
        need linkage.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#791">791</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK31">UK 31</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/368">
     [368]
    </A></TD>
<TD valign="top">
3.5

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        What is the linkage of names declared
        inside a namespace, in turn declared inside an anonymous
        namespace? It is not clear why such a namespace has no
        linkage, and there is no language suggesting its memmbers
        should lose linkage with it, which we assume is the
        intended consequence.
&#160;
  </TD>
<TD valign="top">
        Clarify rules for namespaces inside nested
        namespaces, or remove the restriction.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US23">US 23</A></TD>
<TD valign="top">
3.5

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        Bad
        paragraph break.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR18">FR 18</A></TD>
<TD valign="top">
3.5
        [basic.link]

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        The paragraph number is not aligned with the text.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR19">FR 19</A></TD>
<TD valign="top">
3.6 [Start
and
termination]
&#160;
  </TD>
<TD valign="top">
        This section completely
        ignores the real world and practical case of dynamically
        linked or loaded libraries. In current computing
        environments, they are ubiquitous and they cannot be
        ignored in
        practical C++ programs. The
        Standard
        should address this aspect.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The Committee explicitly voted that this issue could not be addressed
within the time frame for this revision of the Standard.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK32">UK 32</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/369">
     [369]
    </A></TD>
<TD valign="top">
3.6.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Do we really want to allow: constexpr int
        main() { return 0; } as a valid program?
&#160;
  </TD>
<TD valign="top">
        Add constexpr to
        the list of ill-formed things to annotate main 
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US24">US 24</A></TD>
<TD valign="top">
3.6.1

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        std::quick_exit is not
        referenced.
&#160;
  </TD>
<TD valign="top">
        Reference std::quick_exit as well as std::exit in saying
        that automatic objects are not destroyed. It should
        <font size="2" style="font-size: 11pt"><strong>not</strong>
        do so in saying that calling std::quick_exit is undefined
        from within destructors for static or thread duration
        objects.</font>
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#792">792</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US25">US 25</A></TD>
<TD valign="top">
3.6.3

    &#182;
    
&#182; 2 last sent.
&#160;
  </TD>
<TD valign="top">
        The parenthesized phrase, introduced via
        &#8220;i.e.&#8221; is in the nature of an example.
&#160;
  </TD>
<TD valign="top">
        Change &#8220;i.e.&#8221; to &#8220;e.g.&#8221;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The parenthesized phrase is in the nature of a clarification, so
"i.e." is appropriate.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP6">JP 6</A></TD>
<TD valign="top">
3.7.4.1

    &#182;
    
4<sup>th</sup> <font size="2" style="font-size: 11pt">para,
4<sup>th</sup>
        line</font>
&#160;
  </TD>
<TD valign="top">
        Typo.
        <BR><BR>
        Lack of a comma right after &#8220;(3.7.2)&#8221; in the
        sentence while there are commas after any other recitations
        like &#8220;(3.7.1)&#8221;. It is just a unification
        matter.
        
        <BR><BR>[
        Note: in particular, a global allocation function is not
        called to allocate storage for objects with static storage
        duration (3.7.1), for objects or references with thread
        storage duration (3.7.2) for objects of type std::type_info
        (5.2.8), or for the copy of an object thrown by a throw
        expression (15.1). -end note ]
        
        <BR><BR>should be
        
        <BR><BR>[
        Note: in particular, a global allocation function is not
        called to allocate storage for objects with static storage
        duration (3.7.1), for objects or references with thread
        storage duration (3.7.2), for objects of type
        std::type_info (5.2.8), or for the copy of an object thrown
        by a throw expression (15.1). -end note ]
&#160;
  </TD>
<TD valign="top">
        Correct typo.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE3">DE 3</A></TD>
<TD valign="top">
3.7.4.3
&#160;
  </TD>
<TD valign="top">
        DE-3 It is
        unclear whether the following code has well-defined
        behavior; none of the bullets in the second paragraph seem
        to apply.
        <BR><BR>int&amp; i =
        *new int(5);
        <BR><BR>delete &amp;i;
&#160;
  </TD>
<TD valign="top">
        Clarify that &amp;i is considered a safely-derived
        pointer value.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#735">735</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US26">US 26</A></TD>
<TD valign="top">
3.8

    &#182;
    
1 and 5
&#160;
  </TD>
<TD valign="top">
        Use of object fields during
        destruction is excessively and erroneously constrained.
&#160;
  </TD>
<TD valign="top">
        See
        the attached document "Issues with the C++ Standard" under
        Chapter 3 "Use of objects, especially from other threads,
        during destruction".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#793">793</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US27">US 27</A></TD>
<TD valign="top">
3.9

    &#182;
    
&#182; 9 first sent.
&#160;
  </TD>
<TD valign="top">
        There is a superfluous/extraneous &#8220;and&#8221;.
&#160;
  </TD>
<TD valign="top">
        Delete &#8220;and&#8221; from the phrase &#8220;and
        std::nullptr_t&#8221;.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR20">FR 20</A></TD>
<TD valign="top">
3.9 [Types]
&#160;
  </TD>
<TD valign="top">
        The phrase 'effective type'
        is defined and used in a way that is incompatible with C99.
        Such a deliberate incompatible choice of terminology is
        both unfortunate and confusing, given past practice of the
        committee to maintain greater compatibility with C99. We
        strongly suggest that the phrase 'effective type' not be
        used in such an incompatible way.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The choice of the term was previously discussed and no better term
could be found.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP7">JP 7</A></TD>
<TD valign="top">
3.9.2

    &#182;
    
3<sup>rd</sup> <font size="2" style="font-size: 11pt">para,
13<sup>th</sup>
        line</font>
&#160;
  </TD>
<TD valign="top">
        over-aligned type was added as new notion. So it is
        preferable to add the link after that.
&#160;
  </TD>
<TD valign="top">
        Add
        (3.11) after over-aligned type as the link.
        <BR><BR>[ Note: pointers to
        over-aligned types<font color="#008000">(3.11)</font>
        <font size="2" style="font-size: 11pt">have no special
        representation, but their range of valid values is
        restricted by the extended alignment requirement. This
        International Standard specifies only two ways of obtaining
        such a pointer: taking the address of a valid object with
        an over-aligned type<font color="#008000">(3.11)</font>,
        and using one of the runtime pointer alignment functions.
        An implementation may provide other means of obtaining a
        valid pointer value for an over-aligned type<font color="#008000">(3.11)</font>.&#8212;end note ]</font>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US28">US 28</A></TD>
<TD valign="top">
3.9.3

    &#182;
    
&#182; 5 first sent.
&#160;
  </TD>
<TD valign="top">
        The closing
        braces of the first two sets are preceded by extraneous
        space.
&#160;
  </TD>
<TD valign="top">
        Delete the extra spaces.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE4">DE 4</A></TD>
<TD valign="top">
4.2

    &#182;
    
p2
&#160;
  </TD>
<TD valign="top">
        DE-4 The deprecated conversion from string literals to
        pointer to non-const character types should be limited to
        those conversions and types of string literals that were
        already present in ISO/IEC 14882:2003, or the deprecated
        conversions should be removed entirely.
&#160;
  </TD>
<TD valign="top">
        Consider
        applying the proposed resolution presented in core issue
        693 in WG21 document N2714 &#8220;C++ Standard Core
        Language Active Issues, Revision 58&#8220;, available at
        http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2714.html
        ; or remove only the conversions to "pointer to char16_t",
        "pointer to char32_t" in 4.2 paragraph 2 and 15.1 paragraph
        3.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#693">693</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH1">CH 1</A></TD>
<TD valign="top">
4.9 and 5.2.9
&#160;
  </TD>
<TD valign="top">
        With respect to the target type, pointer to members
        should behave like normal pointers (least surprise
        principle).
&#160;
  </TD>
<TD valign="top">
        The standard
        should allow implicit conversions from ``pointer to member
        of <tt>T</tt> of type <i>cv</i> <tt>D</tt>'' to ``pointer
        to member of <tt>T</tt> of type <i>cv</i> B'', where D is
        of class type and B is a public base of D, It should allow
        explicit conversion the other way around.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#794">794</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Section reference should be 4.11 instead of 4.9.
There was no consensus to make this change at this point in the
standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE5">DE 5</A></TD>
<TD valign="top">
4.11,
5.3.1,
5.5
&#160;
  </TD>
<TD valign="top">
        DE-5 Ref-qualification has not been integrated with
        pointer-to-members.
&#160;
  </TD>
<TD valign="top">
        Review implicit
        conversions (4.11), forming pointer-to-members (5.3.1), and
        dereferencing pointer-to-members (5.5) for type-safety
        concerns in the presence of ref-qualifiers on the member.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#731">731</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK33">UK 33</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/374">
     [374]
    </A></TD>
<TD valign="top">
4.13

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        We have: "No two signed integer types shall
        have the same rank ..." "the rank of char shall equal the
        rank of signed char" Can we therefore deduce that char may
        not be signed?
&#160;
  </TD>
<TD valign="top">
        Replace the
        first sentence with "No two signed integer types shall have
        the same rank, even if they have the same representation,
        except that signed char shall have the same rank as char
        even if char is signed (3.9.1/1)."
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK34">UK 34</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/375">
     [375]
    </A></TD>
<TD valign="top">
4.13

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        6th bullet, "the
        rank of char" - first letter should be capitalised for
        consistency with the other bullets
&#160;
  </TD>
<TD valign="top">
        The rank of char
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK36">UK 36</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/407">
     [407]
    </A></TD>
<TD valign="top">
5.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        Primary
        expressions are literals, names, names qualified by the
        scope resolution operator ::, and lambda expressions. The
        immediately following grammar flatly contradicts this -
        this and (e) are also lambda expressions.
&#160;
  </TD>
<TD valign="top">
        Delete this paragraph.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
The introductory sentence was deleted, but the paragraph (containing
the grammar) remains.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK37">UK 37</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/224">
     [224]
    </A></TD>
<TD valign="top">
5.1

    &#182;
    
11
&#160;
  </TD>
<TD valign="top">
        Member function
        templates are not member functions, so should also be
        listed in the 3rd bullet
&#160;
  </TD>
<TD valign="top">
        Add member function templates to the 3rd
        bullet
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The text is clear enough as it is. There are many places in the Standard
where function templates are not explicitly mentioned in a reference to
functions.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK38">UK 38</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/230">
     [230]
    </A></TD>
<TD valign="top">
5.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        <TT>this</TT> might be useful in a few more places
        than it is permitted, specifically in decltype expressions
        within a class. Two examples that would be ill-formed at
        class scope without changes: typedef decltype( *this )
        this_type; decltype( [this]{ return this-&gt;memfun(); } )
        my_lambda;
&#160;
  </TD>
<TD valign="top">
        ... words to follow ...
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for this change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP8">JP 8</A></TD>
<TD valign="top">
5.1

    &#182;
    
7<sup>th</sup> <font size="2" style="font-size: 11pt">para, Syntax rules</font>
&#160;
  </TD>
<TD valign="top">
        In
        the current syntax definition, a scope operator(::) cannot
        be applied to decltype, but it should be. It would be
        useful in the case to obtain member type(nested-type) from
        an instance as follows:
        <BR><BR>
        vector&lt;int&gt; v;
        <BR><BR>decltype(v)::value_type i = 0;
        // int i = 0;
&#160;
  </TD>
<TD valign="top">
        Add
        &#8220;decltype ( expression ) :: &#8220; to
        nested-name-specifier syntax like below.
        
        <BR><BR>
        nested-name-specifier:
        <BR>type-name ::
        <BR>namespace-name ::
        <BR>
        nested-name-specifier identifier ::
        <BR>
        nested-name-specifier templateopt simple-template-id ::
        <BR>
        nested-name-specifieropt concept-id ::
        <BR>decltype (
        expression ) ::
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#743">743</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP9">JP 9</A></TD>
<TD valign="top">
5.1.1
&#160;
  </TD>
<TD valign="top">
        It
        would be preferable that &#8220;&amp;&amp;&#8221; could be
        specified in a lambda expression to declare move capture.
        <BR><BR>
        
         Here is an example from N2709.
        <BR><BR>
        
         template&lt;typename F&gt;
        <BR>
        std::unique_future&lt;typename
        std::result_of&lt;F()&gt;::type&gt; spawn_task(F f){
        <BR>
        typedef typename std::result_of&lt;F()&gt;::type
        result_type;
        <BR>
        
        <BR>
        struct local_task {
        <BR>
        std::promise&lt;result_type&gt; promise;
        <BR>F
        func;
        <BR>
        local_task(local_task const&amp; other)=delete;
        <BR>
        local_task(F func_):
        <BR>
        func(func_)
        <BR>{}
        <BR>
        
        <BR>
        local_task(local_task&amp;&amp; other):
        <BR>
        promise(std::move(other.promise)),
        <BR>
        f(std::move(other.f))
        <BR>{}
        <BR>
        
        <BR>
        void operator() {
        <BR>try
        <BR>{
        <BR>
        promise.set_value(f());
        <BR>}
        <BR>
        catch(...)
        <BR>{
        <BR>
        promise.set_exception(std::current_exception());
        <BR>}
        <BR>}
        <BR>};
        <BR>
        
        <BR>
        local_task task(std::move(f));
        <BR>
        
        <BR>
        std::unique_future&lt;result_type&gt;
        res(task.promise.get_future());
        <BR>
        std::thread(std::move(task));
        <BR>
        return res;
        <BR>}
        <BR>
        
        <BR>
        This can be rewritten simply as follows if move capture can
        be used in a lambda expression.
        <BR>
        
        <BR>
        template&lt;typename F&gt;
        <BR>
        std::unique_future&lt;typename
        std::result_of&lt;F()&gt;::type&gt; spawn_task(F f){
        <BR>
        typedef typename std::result_of&lt;F()&gt;::type
        result_type;
        <BR>
        
        <BR>
        std::promise&lt;result_type&gt; promise;
        <BR>
        std::unique_future&lt;result_type&gt;
        res(promise.get_future());
        <BR>
        std::thread([&amp;&amp;promise, &amp;&amp;f]() {
        <BR>try
        <BR>{
        <BR>
        promise.set_value(f());
        <BR>}
        <BR>
        catch(...)
        <BR>{
        <BR>
        promise.set_exception(std::current_exception());
        <BR>}
        <BR>});
        <BR>
        return res;
        <BR>}
        <BR>
&#160;
  </TD>
<TD valign="top">
        Add
        move capture in a lambda expression.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This would be a dangerous feature, allowing &#8220;moving&#8221; from
named variables. It would also contradict the change made by paper
<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">
N2844</A>, prohibiting the binding of rvalue references to lvalues, which
was adopted at the March, 2009 meeting.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP10">JP 10</A></TD>
<TD valign="top">
5.1.1
&#160;
  </TD>
<TD valign="top">
        In
        the current syntax definition, a returned type of a
        function object cannot be obtained by using result_of from
        an unnamed function object generated by a lambda expression
        because it doesn&#8217;t have result type.
        
        <BR><BR>
        template &lt;class F&gt;
        <BR>
        void foo(F f)
        <BR>{
        <BR>
        typedef std::result_of&lt;F()&gt;::type result; // error
        <BR>}
        <BR>
        foo([]{});
        <BR>
        
        <BR>If
        &#8220;Callable&#8221; or &#8220;Predicate&#8221; concept
        is specified, a returned type can be obtained from a
        function object without result_type. But it is preferable
        to be able to obtain it with template.
&#160;
  </TD>
<TD valign="top">
        Add
        result_type to the syntax of an unnamed function object
        generated by a lambda expression.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This is not a defect.  The definition of <TT>std::result_of</TT> now
uses <TT>decltype</TT> and does not require a <TT>result_type</TT> member
typedef, so the desired functionality is already present in the current
specification.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US29">US 29</A></TD>
<TD valign="top">
5.1.1
&#160;
  </TD>
<TD valign="top">
        The
        standard does not state whether or not direct recursion of
        lambdas is possible.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#762">762</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
     N2927</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US30">US 30</A></TD>
<TD valign="top">
5.1.1
&#160;
  </TD>
<TD valign="top">
        <font color="#000000">The standard does not clarify the
        meaning of</font> <font size="2" style="font-size: 11pt"><code><font color="#000000">this</font></code> <font color="#000000">in
        lambdas. Does it mean this lambda, or this class within
        which the lambda is nested?</font></font>
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#762">762</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
     N2927</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US31">US 31</A></TD>
<TD valign="top">
5.1.1
&#160;
  </TD>
<TD valign="top">
        <font color="#000000">The current wording does not specify
        how context capturing and name resolution</font>
        <font size="2" style="font-size: 11pt">take place when the
        inner lambda refers to the outer lambda's locals variables
        and parameters.</font>
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#752">752</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
     N2927</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK45">UK 45</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/444">
     [444]
    </A></TD>
<TD valign="top">
5.1.1

    &#182;
    
para 2
&#160;
  </TD>
<TD valign="top">
        Lambda is a language feature with an
        apparent dependency on &lt;functional&gt;. This increases
        dependency of language on library, and is inconsistent with
        the definition of freestanding in 17.6.2.4.
&#160;
  </TD>
<TD valign="top">
        Change the text
        "a closure object behaves as a function object" to "a
        closure object is a built-in object which behaves as a
        function object"; and after "context.", insert " A closure
        object may be used without any need for
        &lt;functional&gt;." This makes clear what may already be
        implied, namely that lambdas can be used in freestanding
        implementations and don't increase dependency of language
        on library. (Marked as technical comment anyway because
        this clarity is technically important).
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#795">795</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The reference to 20.7 appears only in a note, not in normative text, and
is intended only to clarify the meaning of the term &#8220;function
object,&#8221; as defined there: &#8220;Function objects are objects with
an <TT>operator()</TT> defined.&#8221;  This creates no dependency on
&lt;functional&gt; or any other library facitlity.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US32">US 32</A></TD>
<TD valign="top">
5.1.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        The
        final italic "this" in the paragraph should be a teletype
        "this".
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK39">UK 39</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/408">
     [408]
    </A></TD>
<TD valign="top">
5.1.1

    &#182;
    
11
&#160;
  </TD>
<TD valign="top">
        This paragraph lists all the special member
        functions for the class representing a lambda. But it omits
        the destructor, which is awkward.
&#160;
  </TD>
<TD valign="top">
        Add "F has an implicitly-declared
        destructor".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#759">759</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
     N2927</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK40">UK 40</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/409">
     [409]
    </A></TD>
<TD valign="top">
5.1.1

    &#182;
    
12
&#160;
  </TD>
<TD valign="top">
        If one or more
        names in the effective capture set are preceded by &amp;,
        the effect of invoking a closure object or a copy after the
        innermost block scope of the context of the lambda
        expression has been exited is undefined. That is too
        restrictive. The behaviour should be undefined iff the
        lifetime of any of the variables referenced has ended. This
        should be safe and legal; currently it has undefined
        behaviour: int i; reference_closure&lt;void ()&gt; f; if
        (blah) { f = [&amp;i]() { }; } if (f) f();
&#160;
  </TD>
<TD valign="top">
        If one or more names in the effective
        capture set are preceded by &amp;, the effect of invoking a
        closure object or a copy after the lifetime of any of the
        variables referenced has ended is undefined.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#796">796</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
Paragraph reference should be 13, not 12.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
     N2927</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK41">UK 41</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/225">
     [225]
    </A></TD>
<TD valign="top">
5.1.1

    &#182;
    
12
&#160;
  </TD>
<TD valign="top">
        For argument dependant lookup (3.4.2) the
        associated namespaces for a class include its bases, and
        associated namespaces of its bases. Requiring the result of
        a lambda expression *to dervide from*
        std::reference_closure means that ADL will look in
        namespace std when the lambda capture is entirely by
        reference, which might have surprising results. Also,
        relying on the idea of implicitly slicing objects is
        uncomfortable.
&#160;
  </TD>
<TD valign="top">
        Replace inheritance with implicit
        conversion.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
<TT>std::reference_closure</TT> was removed at the March, 2009 meeting,
rendering the issue moot.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2845.html">
     N2845</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK42">UK 42</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/226">
     [226]
    </A></TD>
<TD valign="top">
5.1.1
&#160;
  </TD>
<TD valign="top">
        A lambda with an empty capture list has
        identical semantics to a regular function type. By
        requiring this mapping we get an efficient lambda type with
        a known API that is also compatible with existing operating
        system and C library functions.
&#160;
  </TD>
<TD valign="top">
        Add a new
        paragraph: "A lambda expression with an empty capture set
        shall be convertible to pointer to function type R(P),
        where R is the return type and P is the parameter-type-list
        of the lambda expression." Additionally it might be good to
        (a) allow conversion to function reference (b) allow extern
        "C" function pointer types
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#797">797</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK43">UK 43</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/231">
     [231]
    </A></TD>
<TD valign="top">
5.1.1

    &#182;
    
12
&#160;
  </TD>
<TD valign="top">
        The note spells
        out the intent that objects from lambda-expressions with an
        effective capture list of references should be implemented
        as a pair of pointers. However, nothing in the rest of
        5.1.1 lifts the requirement of to declare a reference
        member for each captured name, and a non-normative note is
        not enough to relax that.
&#160;
  </TD>
<TD valign="top">
        ... provvide exceptions in the right places
        ...
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
<TT>std::reference_closure</TT> was removed at the March, 2009 meeting,
rendering the issue moot.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2845.html">
     N2845</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK44">UK 44</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/252">
     [252]
    </A></TD>
<TD valign="top">
5.1.1

    &#182;
    
12
&#160;
  </TD>
<TD valign="top">
        There is a
        strong similarity between a [&amp;]{} lambda capturing a
        stack frame, and a [this]{} lambda binding a member
        function to a class instance. The reference_closure
        requirement should be extended to the second case, although
        we need some syntax to create such an object that is
        distinct from the existing pointer-to-member syntax. This
        would be a cleaner alternative to the new std::mem_fn
        library component.
&#160;
  </TD>
<TD valign="top">
        Extend reference_closure requirement to
        cover [this] lambdas. Consider a simple syntax for creating
        such bound expressions.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus to make the suggested change at this point in
the standardization process.  Furthermore,
<TT>std::reference_closure</TT> was removed at the March, 2009 meeting,
rendering the issue moot.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK46">UK 46</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/449">
     [449]
    </A></TD>
<TD valign="top">
5.1.1

    &#182;
    
para 12
&#160;
  </TD>
<TD valign="top">
        The requirement that a lambda meeting
        appropriate conditions be an object derived from
        reference_closure makes lambda the language feature
        dependent on &lt;functional&gt;, which increases dependency
        of the language on the library and bloats the definition of
        freestanding C++.
&#160;
  </TD>
<TD valign="top">
        Replace text "is
        publicly derived from" with "shall be implemented in a
        manner indistinguishable from". This places an ABI
        constraint on reference closures such that compiler and
        library implementer have to do compatible things. But it
        cuts the dependency of lambda syntax on &lt;functional&gt;.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
<TT>std::reference_closure</TT> was removed at the March, 2009 meeting,
rendering the issue moot.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2845.html">
     N2845</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE6">DE 6</A></TD>
<TD valign="top">
5.1.1, 20.7.18
&#160;
  </TD>
<TD valign="top">
        DE-6 Some uses of lambda expressions refer to
        specializations of the unconstrained class template
        std::reference_closure (5.1.1). If the lambda expression
        appears in a constrained context and the return type or a
        parameter type for the lambda depend on a template
        parameter (see 14.10), such a use is ill-formed.
&#160;
  </TD>
<TD valign="top">
        In 20.7.18, for the class template
        std::reference_closure, require Returnable for R and
        VariableType for each of the ArgTypes.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
<TT>std::reference_closure</TT> was removed at the March, 2009 meeting,
rendering the issue moot.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2845.html">
     N2845</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE7">DE 7</A></TD>
<TD valign="top">
5.1.1

    &#182;
    
p10
&#160;
  </TD>
<TD valign="top">
        DE-7 The note at the end of paragraph 10 appears to be
        garbled.
&#160;
  </TD>
<TD valign="top">
        Remove "or references" in the note.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Looks okay: "captured" applies to "variables or references".
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE8">DE 8</A></TD>
<TD valign="top">
5.1.1

    &#182;
    
p10
&#160;
  </TD>
<TD valign="top">
        DE-8 The construction of the function call operator
        signature is missing specifications for the ref-qualifier
        and the attribute-specifier.
&#160;
  </TD>
<TD valign="top">
        Add bullets that say that the ref-qualifier and the
        attribute-specifier are absent.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US33">US 33</A></TD>
<TD valign="top">
5.1.1

    &#182;
    
11
&#160;
  </TD>
<TD valign="top">
        There is no definition of &#8220;move constructor&#8221;
        or &#8220;move operation&#8221;
&#160;
  </TD>
<TD valign="top">
        Since this is
        the first place the terms are used, a definition should
        either be added here, or a cross reference to one.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#680">680</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The term &#8220;move constructor&#8221; is no longer used; instead, the
behavior of the constructor is described.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
     N2927</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE9">DE 9</A></TD>
<TD valign="top">
5.1.1
&#160;
  </TD>
<TD valign="top">
        DE-9 There is not a single example of a
        lambda-expression in the standard. See also core issue 720
        in WG21 document N2791 "C++ Standard Core Language Active
        Issues, Revision 59", available at
        http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
        .
&#160;
  </TD>
<TD valign="top">
        Add a few well-chosen examples.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#720">720</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
     N2927</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK52">UK 52</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/232">
     [232]
    </A></TD>
<TD valign="top">
5.2

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        This paragraph seens out of place,
        assignment expressions are covered in 5.17
&#160;
  </TD>
<TD valign="top">
        Move p3 to subsection 5.17
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Removed the paragraph; grammar changes make it moot.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK53">UK 53</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/233">
     [233]
    </A></TD>
<TD valign="top">
5.2.1
&#160;
  </TD>
<TD valign="top">
        The definition in p1 makes no allowance for
        overloaded operator[] that treats the expression as a
        simple function call, and does not support the
        interchangability of arguments. Howver p2 relies on this
        definition when describing the use of brace-init-lists
        inside [].
&#160;
  </TD>
<TD valign="top">
        Insert a new p2 describing the changed
        semantics for overloaded operator[]. This should be a note
        to avoid introducing normative text that could potentially
        conflict with the later definiton of these semantics.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#798">798</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK59">UK 59</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/410">
     [410]
    </A></TD>
<TD valign="top">
5.2.2

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
        When there is no parameter for a given
        argument, the argument is passed in such a way that the
        receiving function can obtain the value of the argument by
        invoking va_arg. That shouldn't apply to parameter packs.
        template &lt;class ... Types&gt; void f(Types ... pack);
        f(1, 2, 3);
&#160;
  </TD>
<TD valign="top">
        Clarify that this sentence only applies
        where the ellipsis is used.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK60">UK 60</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/411">
     [411]
    </A></TD>
<TD valign="top">
5.2.5

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        In the remainder of 5.2.5, cq represents
        either const or the absence of const vq represents either
        volatile or the absence of volatile.
&#160;
  </TD>
<TD valign="top">
        Add "and" before vq
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK61">UK 61</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/234">
     [234]
    </A></TD>
<TD valign="top">
5.2.5

    &#182;
    
p1
&#160;
  </TD>
<TD valign="top">
        Together with footnote 60 there may be
        confusion that the postfix expression is always evaluated -
        even when part of an unevaluated operand. We believe the
        standard does not require this, and a comment in the
        existing note would be a useful clarification.
&#160;
  </TD>
<TD valign="top">
        Clarify in footnote 60 that this will not
        happen if the whole expression is an unevaluated operand.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK62">UK 62</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/235">
     [235]
    </A></TD>
<TD valign="top">
5.2.5

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        In the final bullet, what does 'not an
        lvalue' mean? Does it imply rvalue, or are there other
        possible meanings? Should clauses that trigger on rvalues
        pick up on this?
&#160;
  </TD>
<TD valign="top">
        Replace 'not an lvalue' with 'is an
        rvalue'.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE10">DE 10</A></TD>
<TD valign="top">
5.2.5
&#160;
  </TD>
<TD valign="top">
        DE-10 If E1.E2 is referring to a non-static member
        function, the potential ref-qualification on E2 should be
        taken into account.
&#160;
  </TD>
<TD valign="top">
        Adjust the presentation of the types involved as
        appropriate.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#731">731</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK63">UK 63</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/412">
     [412]
    </A></TD>
<TD valign="top">
5.2.6

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        Paragraph 2 is missing its number.
&#160;
  </TD>
<TD valign="top">
        Add one.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK64">UK 64</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/413">
     [413]
    </A></TD>
<TD valign="top">
5.2.7

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        A new name R is introduced for use in
        paragraphs 3 and 4. But R is the same as T.
&#160;
  </TD>
<TD valign="top">
        Replace R with T
        and replace "the required result type (which, for
        convenience, will be called R in this description)" with
        "T".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK65">UK 65</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/414">
     [414]
    </A></TD>
<TD valign="top">
5.2.7

    &#182;
    
8
&#160;
  </TD>
<TD valign="top">
        In the first two
        bullets we have "the result is a pointer (an lvalue
        referring) to". But para 2 makes clear that a dynamic_cast
        of an rvalue references produces a rvalue. (Can an lvalue
        refer to anything anyway?)
&#160;
  </TD>
<TD valign="top">
        Replace "an lvalue referring to" with
        "reference", twice.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK66">UK 66</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/415">
     [415]
    </A></TD>
<TD valign="top">
5.2.8

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        typeid may
        return "an implementation-defined class derived from std ::
        type_info". The derivation must be public.
&#160;
  </TD>
<TD valign="top">
        an implementation-defined class publicly
        derived from std :: type_info
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK67">UK 67</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/416">
     [416]
    </A></TD>
<TD valign="top">
5.2.9

    &#182;
    
1, 2, 3
&#160;
  </TD>
<TD valign="top">
        Paragraph 1 specifies when the result of
        static_cast is an lvalue; repeating it is unnecessary.
&#160;
  </TD>
<TD valign="top">
        In para 2,
        delete "It is an lvalue if the type cast to is an lvalue
        reference; otherwise, it is an rvalue." and "The result is
        an rvalue.". In para 3, delete "The result is an lvalue if
        T is an lvalue reference type (8.3.2), and an rvalue
        otherwise."
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
The sentence in question is 20.1.1/5.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK54">UK 54</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/417">
     [417]
    </A></TD>
<TD valign="top">
5.2.10

    &#182;
    
3, 6
&#160;
  </TD>
<TD valign="top">
        Para 3: "The mapping performed by
        reinterpret_cast is implementation-defined.". Para 6: "...
        the result of such a pointer conversion is unspecified."
        Which is it?
&#160;
  </TD>
<TD valign="top">
        In para 6,
        replace unspecified with implementation-defined.
        Alternatively, delete paragraph 3, since individual cases
        are labelled appropriately.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK55">UK 55</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/236">
     [236]
    </A></TD>
<TD valign="top">
5.2.10

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        dynamic_cast and reinterpret_cast
        crossreference 5.2.11 without creating an extra note. The
        second half of the note is unrelated to the crossrefernce,
        and would serve as well in normative text.
&#160;
  </TD>
<TD valign="top">
        Strike the note
        about definition of casting away constness, preserve the
        cross-reference. The second sentance on reintrepret_cast to
        its own type should move out of the note into the normative
        text.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#799">799</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
The repetition of the reference to 5.2.11 was handled as a quasi-editorial
change in paper N2841.  Issue 799 was opened for the question about casting
to the same type as the operand.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK56">UK 56</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/237">
     [237]
    </A></TD>
<TD valign="top">
5.2.10

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
        The notion of
        safely derived pointers means this conversion may not be as
        safe in the revised standard as the original. It would be
        good to call attention to the changed semantics with a
        note.
&#160;
  </TD>
<TD valign="top">
        Add: [Note: the result of such a conversion
        will not be a safely-derived pointer value (3.7.4.3) -- end
        note]
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK57">UK 57</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/238">
     [238]
    </A></TD>
<TD valign="top">
5.2.10

    &#182;
    
8
&#160;
  </TD>
<TD valign="top">
        Conditionally supported behaviour gives a
        wide range or permission, so clarify relationship between
        safely-derived object pointers and function pointers in a
        note.
&#160;
  </TD>
<TD valign="top">
        Add: [Note: In such cases, the
        implementation shall also define whether a safely-derived
        object pointer cast to a function pointer can be safely
        cast back -- end note]
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#800">800</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The definition of "safely-derived pointer" is exclusively formulated in
terms of pointers to dynamically-allocated objects. The conversion between
function pointers and object pointers is principally intended for use
with dynamic loading of shared libraries, which has minimal interaction
with garbage-collected objects.  There was no perceived need for the
Standard to say anything further on this topic.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK58">UK 58</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/418">
     [418]
    </A></TD>
<TD valign="top">
5.2.11

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
        Casting from an
        lvalue of type T1 to an lvalue of type T2 using a reference
        cast casts away constness if a cast from an rvalue of type
        &#8220;pointer to T1&#8221; to the type &#8220;pointer to
        T2&#8221; casts away constness. That doesn't cover rvalue
        references.
&#160;
  </TD>
<TD valign="top">
        Replace lvalue with "lvalue or rvalue"
        twice.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#801">801</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US34">US 34</A></TD>
<TD valign="top">
5.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The list of unary operator
        should be in teletype font.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK68">UK 68</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/419">
     [419]
    </A></TD>
<TD valign="top">
5.3.1

    &#182;
    
2-9
&#160;
  </TD>
<TD valign="top">
        All the unary operands other than * return
        rvalues - but this is not stated.
&#160;
  </TD>
<TD valign="top">
        Add a paragraph
        1a "The following unary operators all produce results that
        are rvalues."
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK69">UK 69</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/240">
     [240]
    </A></TD>
<TD valign="top">
5.3.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        If we cannot
        bind references/take address of functions in concept_maps,
        does that mean we cannot use generic bind in constrained
        templates? Launch threads with expressions found via
        concept map lookup? Hit problems creating std::function
        objects? Does the problem only occur if we use qualified
        lookup to explicitly name a concept map? Does it only kick
        in if we rely on the implicit function implementation
        provided by a concept_map, so some types will work and
        others won't for the same algorithm?!
&#160;
  </TD>
<TD valign="top">
        ... unknown ...
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#802">802</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK70">UK 70</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/420">
     [420]
    </A></TD>
<TD valign="top">
5.3.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The sizeof
        operator shall not be applied to ... an enumeration type
        before all its enumerators have been declared We should
        allow enum E : int; sizeof(E).
&#160;
  </TD>
<TD valign="top">
        Change "an enumeration type" to "an
        enumeration type whose underlying type is not fixed".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#803">803</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK71">UK 71</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/254">
     [254]
    </A></TD>
<TD valign="top">
5.3.4

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The type of an allocated object wih the
        type specifier auto is determined by the rules of copy
        initialization, but the initialization applied will be
        direct initialization. This would affect classes which
        declare their copy constructor explicit, for instance. For
        consistency, use the same form of initiailization for the
        deduction as the new expression.
&#160;
  </TD>
<TD valign="top">
        Replace T x = e; with T x(e);
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#804">804</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK72">UK 72</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/257">
     [257]
    </A></TD>
<TD valign="top">
5.3.4

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
        The library
        headers have been carefully structured to limit the
        dependencies between core language and specific headers.
        The exception thrown should be catchable by a handler for a
        type lised in &lt;exception&gt; header in cluase 18. This
        might be accomplished by moving length_error into the
        &lt;exception&gt; header, but its dependency on logic_error
        with its std::string constructors suggest this is not a
        good idea. Prefer to pick an existing exception instead.
&#160;
  </TD>
<TD valign="top">
        Throw std::bad_alloc instead of
        std::length_error.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#805">805</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/N2932.pdf">
     N2932</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK73">UK 73</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/258">
     [258]
    </A></TD>
<TD valign="top">
5.3.4

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        A class type
        with conversion operator can only be used if the conversion
        type is constexpr and the class is a literal type. Adding
        the single word 'literal' before class type will clarify
        this.
&#160;
  </TD>
<TD valign="top">
        Add 'literal' before 'class type'
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This is not a defect.  The leftmost subscript in the
<I>noptr-new-declarator</I> (the <I>expression</I>, as opposed to the
<I>constant-expression</I>) need not be constant.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK74">UK 74</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/259">
     [259]
    </A></TD>
<TD valign="top">
5.3.4

    &#182;
    
8
&#160;
  </TD>
<TD valign="top">
        operators, like
        constructors and destructors, do not have names. However,
        in certain circumstances they can be treated as if they had
        a name, but usually the stanadard is very clear not to
        actually describe their name as a distinct property.
&#160;
  </TD>
<TD valign="top">
        Change "the allocation function&#8217;s
        name is operator new" to "the allocation function is named
        operator new" and similarly for operator delete.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The premise is incorrect: according to 3 [basic] paragraph 4, operators
do indeed have names.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK35">UK 35</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/260">
     [260]
    </A></TD>
<TD valign="top">
5.3.4

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
        Missing period in middle of paragraph
        between "in the scope of T" and "If this lookup fails"
&#160;
  </TD>
<TD valign="top">
        Add a period
        between "in the scope of T" and "If this lookup fails"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK75">UK 75</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/262">
     [262]
    </A></TD>
<TD valign="top">
5.3.5

    &#182;
    
8
&#160;
  </TD>
<TD valign="top">
        A paragraph
        strarting with [Note... is easily skipped when reading,
        missing the normative text at the end.
&#160;
  </TD>
<TD valign="top">
        Swap order of the note and normative text.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR21">FR 21</A></TD>
<TD valign="top">
5.3.6
        [Alignof
&#160;
  </TD>
<TD valign="top">
        Should not the type of alignof-expression be of type
        std::max_align_t?
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
<TT>std::max_align_t</TT> is not guaranteed to be integral, only a POD.
<TT>std::size_t</TT> is the correct choice.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US35">US 35</A></TD>
<TD valign="top">
5.8

    &#182;
    
2 and 3
&#160;
  </TD>
<TD valign="top">
        There is curious spacing in the expressions "E1 &lt;&lt;E2"
        and "E1 &gt;&gt;E2". This is a formatting change since
        previous versions of the Standard.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK47">UK 47</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/242">
     [242]
    </A></TD>
<TD valign="top">
5.14 / 5.15

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        Why are the
        descriptions of order of evaluation of expressions and side
        effects different between &amp;&amp; and || operators. The
        interaction with the memory model should be identical, so
        identical words should be used to avoid accidential
        inconsistencies in interpretation.
&#160;
  </TD>
<TD valign="top">
        Pick one form of wording as 'the best' and
        apply it in both places.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK48">UK 48</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/249">
     [249]
    </A></TD>
<TD valign="top">
5.18

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The defining
        feature of the comma operator is the guaranteed sequencing
        of two expressions. This guarantee is lost when presented
        with an overloaded operator, and this change is subtle
        enough to call attention to it.
&#160;
  </TD>
<TD valign="top">
        Add: [Note: There are no guarantees on the
        order of value computation for an overloaded comma operator
        -- end note]
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK49">UK 49</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/376">
     [376]
    </A></TD>
<TD valign="top">
5.19

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        Is an implementation permitted to reject
        this? constexpr int f() { return f(); } int a[f()]; AFAICT
        it is well-formed; f() seems to satisfy all the rules to
        make it a constant expression. I would hate compilation to
        become a potentially non-terminating experience.
&#160;
  </TD>
<TD valign="top">
        Add an escape
        clause to allow the implementation to reject excessively
        deep nesting of constexpr function evaluations. (This can
        possibly be a note, since it is arguable that this point is
        handled by the general rule on resource limits in 1.4/2. A
        sufficiently smart compiler could use tail recursion above,
        meaning that it would never run out of memory given this
        program though.)
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#699">699</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK50">UK 50</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/378">
     [378]
    </A></TD>
<TD valign="top">
5.19

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The following should be valid: enum E { foo
        = 4}; const E c = foo; int a[c]; But currently it is not -
        c is not an lvalue of effective integral type (4th bullet).
        (See also 7.1.6.1/2)
&#160;
  </TD>
<TD valign="top">
        Change
        "effective integral type" to "effective integral or
        enumeration type" in the 4th bullet, 1st sub-bullet.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#806">806</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK51">UK 51</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/251">
     [251]
    </A></TD>
<TD valign="top">
5.19

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        typeid
        expressions can never be constant, whether or not the
        operand is a polymorphic class type. The result of the
        expression is a reference, and the typeinfo class that the
        reference refers to is polymorphic, with a virtual
        destructor - it can never be a literal type.
&#160;
  </TD>
<TD valign="top">
        Strike the words "whose operand is of a
        polymorphic class type" on the bullet for typeid
        expressions.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#807">807</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The result of <TT>typeid</TT> applied to a non-polymorphic type can
be treated as an address constant and thus usable for static
initialization (e.g., to initialize a reference). The result of
<TT>typeid</TT> applied to an lvalue of polymorphic type cannot be
known at compile time. The polymorphic nature of the <TT>typeinfo</TT>
class is irrelevant to this usage and distinction.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK76">UK 76</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/131">
     [131]
    </A></TD>
<TD valign="top">
6.3
&#160;
  </TD>
<TD valign="top">
        Do we really need two different terms that
        say the same thing?
&#160;
  </TD>
<TD valign="top">
        Pick either
        'block' or 'compound statement' as the preferred term and
        use it consistently throughout the standard.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Both terms are in common use, and there was no consensus for removing
one of them.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR22">FR 22</A></TD>
<TD valign="top">
6.4.2
[The switch
statement]
&#160;
  </TD>
<TD valign="top">
        The constant-expression in
        <BR><BR>case constant-expression
        <BR><BR>should be allowed to be of
        any constant expression of literal type for which a
        constexpr comparison operator (operator&lt; and operator==)
        is in scope. Now that constant expressions of other
        integral types are evaluated at compile time, the
        restriction for case-labels is at best artificial.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making this change at this point in the
standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK77">UK 77</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/132">
     [132]
    </A></TD>
<TD valign="top">
6.5

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
        The terms i/o
        operation, synchronize operation and atomic operation have
        very specific meanings within the standard. The paragraph
        would be much easier to understand with the terms
        crossreferenced.
&#160;
  </TD>
<TD valign="top">
        Profide a cross-reference for the terms:
        i/o operation, synchronize operation and atomic operation
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP11">JP 11</A></TD>
<TD valign="top">
6.5.4

    &#182;
    
1<sup>st</sup> <font size="2" style="font-size: 11pt">para,
5<sup>th</sup>
        line</font>
&#160;
  </TD>
<TD valign="top">
        There is no _RangeT type in the equivalent code to
        &#8220;range-base for&#8221; statement. It existed in
        N2049.
&#160;
  </TD>
<TD valign="top">
        Add
        a typedef for _RangeT in the example as follows:
        
        <BR><BR>{
        <BR>
         <u>typedef decltype( expression )
        _RangeT;</u>
        <BR>
         auto &amp;&amp; __range = ( expression
        );
        <BR>
         for ( auto __begin =
        std::Range&lt;_RangeT&gt;:: begin(__range),
        <BR>
         __end = std::Range&lt;_RangeT&gt;:: end(__range);
        <BR>
        __begin != __end;
        <BR>        
        ++__begin )
        <BR>
         {
        <BR>        
        for-range-declaration = *__begin;
        <BR>
         statement
        <BR>
         }
        <BR>}
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The change was intentional; the term is defined in the descriptive
text.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK78">UK 78</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/130">
     [130]
    </A></TD>
<TD valign="top">
6.5.4

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        Including the header
        &lt;iterator_concepts&gt; is far too unwieldy to enable an
        important and (expected to be) frequently used syntax.
&#160;
  </TD>
<TD valign="top">
        Merge
        &lt;iterator_concepts&gt; into &lt;concepts&gt; and change
        6.5.4p2 to refer to &lt;concepts&gt;, or make the Range
        concept fundamental along with the other support concepts
        in 14.9.4 and strike any reference to including a header.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1001">1001</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2930.html">
     N2930</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK79">UK 79</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/445">
     [445]
    </A></TD>
<TD valign="top">
6.5.4
&#160;
  </TD>
<TD valign="top">
        The definition
        of for (for-range-declaration : expression) statement is
        expanded in terms which require a Range concept, and the
        program is ill-formed if &lt;iterator_concepts&gt; isn't
        included. For users, iterating through old-fashioned
        arrays, this is a sledge-hammer to crack a nut and compares
        poorly with other languages. It's also not possible to
        implement this without adversely impacting the freestanding
        definition in 17.6.2.4.
&#160;
  </TD>
<TD valign="top">
        When expression is an array a of length N
        whose length is known at compile time, expand range-for as
        'for (... p=a, p!=a+N, p++) ...' without requiring the
        Range concept or &lt;iterator_concepts&gt;. Also, when
        expression is an initializer_list, expand range-for
        similarly without requiring &lt;iterator_concepts&gt;.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2930.html">
     N2930</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE11">DE 11</A></TD>
<TD valign="top">
6.9

    &#182;
    
p1
&#160;
  </TD>
<TD valign="top">
        DE-11 A
        sentence in paragraph 1 reads: "Outside of a constrained
        context, the late-checked block has no effect." This, at
        face value, specifies that the <em>compound-statement</em>
        of such a late-checked block is never executed, which
        appears to be unintended.
&#160;
  </TD>
<TD valign="top">
        State that such a late-checked block has the same
        meaning as if the late_check keyword were absent.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK80">UK 80</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/370">
     [370]
    </A></TD>
<TD valign="top">
7

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        Many of the
        sections and major subsections open with a sentence
        summarising the content. I'm not sure this is necessary;
        this isn't a tutorial. The problem with these summaries is
        that because they omit much of the detail, they tend to be
        inaccurate. This may not matter, but I feel the document
        would be improved by omitting them. There's a prime example
        here: "Declarations specify how names are to be
        interpreted." Not true for static_assert, an asm
        declaration nor an anonymous bit field.
&#160;
  </TD>
<TD valign="top">
        Strike the first sentence.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Tweaked first sentence.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK81">UK 81</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/371">
     [371]
    </A></TD>
<TD valign="top">
7

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        String literal
        concatenation happens in phase 6, before parsing, so it is
        legal and useful to use it for the string literal in a
        static_assert. It would be useful to add a note mentioning
        this.
&#160;
  </TD>
<TD valign="top">
        Add a note: Multiple adjacent string
        literals may be used instead of a single /string-literal/;
        see [lex.phases].
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The Standard is already clear enough on this point.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK82">UK 82</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/386">
     [386]
    </A></TD>
<TD valign="top">
7

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        Paragraph 2
        talks about declarations that can have nested declarations
        within them. It doesn't mention scoped enumerations - but
        according to 7.2/11, "Each scoped enumerator is declared in
        the scope of the enumeration."
&#160;
  </TD>
<TD valign="top">
        Add "scoped enumeration" to the list in the
        second sentence.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This suggestion was already considered and rejected.  In particular,
the following statement (&#8220;These nested scopes, in turn, can have
declarations nested within them&#8221;) is not true of an enumeration
scope.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK83">UK 83</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/372">
     [372]
    </A></TD>
<TD valign="top">
7.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The longest
        sequence of decl-specifiers that could possibly be a type
        name is taken as the decl-specifier-seq of a declaration.
        But many sequences of decl-specifiers cannot possibly be a
        type name - eg the sequence "friend int", or "typedef int".
&#160;
  </TD>
<TD valign="top">
        Not sure. I understand the rule, just not
        how to say it.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#808">808</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK84">UK 84</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/404">
     [404]
    </A></TD>
<TD valign="top">
7.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The grammar
        includes alignment-specifier as a production for
        decl-specifier, but there is no production for
        alignment-specifier. I suspect this is a holdover from
        before alignment was handled as an attribute.
&#160;
  </TD>
<TD valign="top">
        Delete the production (including the
        duplicate in A6)
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI3">FI 3</A></TD>
<TD valign="top">
7.1

    &#182;
    
[dcl.
        spec.
        auto]
&#160;
  </TD>
<TD valign="top">
        While
        it&#8217;s considered too late for this standard revision,
        consider loosening the restrictions for auto specifier and
        making it more a mirror of a deduced template function
        parameter.
&#160;
  </TD>
<TD valign="top">
        See restricted-auto.ppt
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
As noted, the suggestion comes too late for consideration at this point
in the standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK85">UK 85</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/373">
     [373]
    </A></TD>
<TD valign="top">
7.1.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        ... the
        init-declarator-list of the declaration shall not be empty
        (except for global anonymous unions, which shall be
        declared static). Global here means "declared at namespace
        scope". (cf 9.5/3 "Anonymous unions declared in a named
        namespace or in the global namespace shall be declared
        static.").
&#160;
  </TD>
<TD valign="top">
        Replace "global" with "namespace scope".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#940">940</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK86">UK 86</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/403">
     [403]
    </A></TD>
<TD valign="top">
7.1.1

    &#182;
    
2,3
&#160;
  </TD>
<TD valign="top">
        The register
        keyword serves very little function, offering no more than
        a hint that a note says is typically ignored. It should be
        deprecated in this version of the standard, freeing the
        reserved name up for use in a future standard, much like
        auto has been re-used this time around for being similarly
        useless.
&#160;
  </TD>
<TD valign="top">
        Deprecate current usage of the register
        keyword.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#809">809</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK87">UK 87</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/405">
     [405]
    </A></TD>
<TD valign="top">
7.1.1

    &#182;
    
1, 4, 5
&#160;
  </TD>
<TD valign="top">
        Why require two
        keywords, where one on its own becomes ill-formed?
        thread_local should imply 'static' in this case, and the
        combination of keywords should be banned rather than
        required. This would also eliminate the one of two
        exceptions documented in 7.1.1p1.
&#160;
  </TD>
<TD valign="top">
        Drop requirement to combine static keyword
        with thread_local at block-scope inside a function
        definition.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#810">810</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US36">US 36</A></TD>
<TD valign="top">
7.1.1

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        The
        permission to use thread_local static data members is
        missing.
&#160;
  </TD>
<TD valign="top">
        Add the static members as a
        permitted use.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#717">717</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR23">FR 23</A></TD>
<TD valign="top">
7.1.5
        [constexpr]
&#160;
  </TD>
<TD valign="top">
        'constexpr' functions should
        be allowed to take const reference parameters, as long as
        their uses are in a context where a constant expression may
        be required. For example, the following should be allowed
        <BR><BR>template&lt;typename T, int
        N&gt;
        <BR>int size(const T(&amp;)[N]) {
        return N; }
        <BR>
        <BR>int a[] = { 41,42,43,44 };
        <BR>enum { v = size(a) };
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making this change without a more complete
proposal.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP12">JP 12</A></TD>
<TD valign="top">
7.1.5
&#160;
  </TD>
<TD valign="top">
        It should be
        allowed to define constexpr recursively.
        <BR><BR>
        There is an explanation in N2235, Generalized Constant
        Expressions&#8212;Revision 5, as follows.
        <BR><BR>We (still)
        prohibit recursion in all its form in constant expressions.
        That is not strictly necessary because an implementation
        limit on recursion depth in constant expression evaluation
        would save us from the possibility of the compiler
        recursing forever. However, until we see a convincing use
        case for recursion, we don&#8217;t propose to allow it.
        <BR><BR>
        Then, here are the use cases where allowing recursion for
        constexpr is very useful.
        <BR><BR>
        Range of problem to be handled with constexpr would become
        extended. For example, user defined type (e.g. Complex
        type) could be placed in ROM area. But with current
        specification, a function defined with constexpr cannot be
        called recursively. As a side effect is not allowed in
        compile-time, it cannot be implemented to repeat anything
        without recursion. Although it could be implemented without
        recursion like func0, func1, func2 in an example below, it
        is not elegant solution.
        <BR><BR>
        constexpr double func0(double x) { /* ... */}
        <BR>
        constexpr double func1(double x) { /* call for func0 */ }
        <BR>
        constexpr double func2(double x) { /* call for func1 */ }
        <BR>/*
        ... */
        <BR><BR>-
        Compile-time and runtime
        <BR><BR>As
        constexpr can be also evaluated both in compile-time and
        runtime, we need to discuss about both cases.
        <BR><BR>
        Runtime evaluation is just to execute it. If you eliminate
        constexpr keyword, it is executable as of now. Any modern
        compiler may optimize tail recursion easily.
        <BR><BR>
        Compile-time evaluation is the same thing as template
        recursion. It is necessary to support floating point
        operation, but it is already possible to calculate it in
        compile-time, so it&#8217;s ok.
        <BR><BR>-
        Sample
        <BR><BR>
        Here is an example to calculate a square root using
        constexpr recursively.
        <BR><BR>
        /*constexpr*/ double SqrtHelper(double x, double a, int n)
        <BR>{
        <BR>
        return n == 0 ? a : SqrtHelper(x, (x / a + a) / 2.0, n -
        1);
        <BR>}
        <BR><BR>
        /*constexpr*/ double Sqrt(double x)
        <BR>{
        <BR>
        return SqrtHelper(x, x, 20);
        <BR>}
        <BR><BR>/*constexpr*/
        double root2 = Sqrt(2.0); // 1.41421...
&#160;
  </TD>
<TD valign="top">
        Allow constexpr recursion.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#699">699</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US37">US 37</A></TD>
<TD valign="top">
7.1.6.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        There is a "Note: 3.9.3 describes how cv-qualifiers affect
        object and function types." So far as I can see, 3.9.3
        CV-qualifiers only describes cv-qualifiers for objects,
        cv-qualifiers for (member) functions being described in
        8.3.5 Functions.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK89">UK 89</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/377">
     [377]
    </A></TD>
<TD valign="top">
7.1.6.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The two
        normative sentences in this paragraph appear to duplicate
        text elsewhere - but they aren't exact duplicates, which
        introduces uncertainty. 1. "An object declared in namespace
        scope with a const-qualified type has internal linkage
        unless it is explicitly declared extern or unless it was
        previously declared to have external linkage.". This nearly
        repeats 7.1.1/7: "Objects declared const and not explicitly
        declared extern have internal linkage." The former seems to
        allow more wiggle room - can an object be "previously
        declared to have external linkage" without having been
        "explicitly declared extern"? 2. "A variable of
        non-volatile const-qualified integral or enumeration type
        initialized by an integral constant expression can be used
        in integral constant expressions (5.19)." This nearly
        duplicates 5.19/2, bullet 4, 1st sub-bullet - "[... an
        integaral constant expression can use] an lvalue of
        effective integral type that refers to a non-volatile const
        variable or static data member initialized with constant
        expressions". The latter does not allow for lvalues of
        enumeration type (neither scoped not unscoped enumerations
        are integral types - 3.9.1/7, and note 44). This seems to
        be a flaw in 5.19/2.
&#160;
  </TD>
<TD valign="top">
        Make the normative text in this section
        into one or more notes, with cross references, and correct
        the referenced text if necessary.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#811">811</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK90">UK 90</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/379">
     [379]
    </A></TD>
<TD valign="top">
7.1.6.2

    &#182;
    
para 1 and table 9
&#160;
  </TD>
<TD valign="top">
        The grammar in
        paragraph one makes "nested-name-specifier template
        simple-template-id" a simple-type-specifier, but unlike all
        the others it is omitted from table 9.
&#160;
  </TD>
<TD valign="top">
        Add a row to table 9 mentioning
        simple-template-id and punting to clause 14 (cf
        decltype(expression)).
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK91">UK 91</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/380">
     [380]
    </A></TD>
<TD valign="top">
7.1.6.2

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        5.1/5 says "[A]
        parenthesized expression can be used in exactly the same
        contexts as those where the enclosed expression can be
        used, and with the same meaning, except as otherwise
        indicated." When the first bullet point of this paragraph,
        describing the type denoted by decltype(e), says "if e is
        an id-expression ... decltype(e) is the type of the entity
        named by e", 5.1/5 is not excluded, which would imply that
        decltype((e)) was also the type of e. But the intention
        appears that it should be caught by the third bullet and
        treated as an lvalue expression, so decltype((e)) should be
        a reference to the type of e. Conversely, the second bullet
        point says "(parentheses around e are ignored)", which is
        redundant because of 5.1/5.
&#160;
  </TD>
<TD valign="top">
        Insert "unparenthised" in the first bullet
        point - "if e is an *unparenthised* id-expression ...". In
        the second bullet point, move "(parentheses around e are
        ignored)" into a note.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK92">UK 92</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/382">
     [382]
    </A></TD>
<TD valign="top">
7.1.6.3

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The note
        correctly indicates that, if T is a template type
        parameter, then "friend class T;" is ill-formed. It might
        be worth pointing out at the same time that the alternative
        "friend T;" is now allowed - see 11.4/3.
&#160;
  </TD>
<TD valign="top">
        Either strike the note or add reference to
        11.4/3 and/or mention of "friend T;".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK93">UK 93</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/454">
     [454]
    </A></TD>
<TD valign="top">
7.1.6.3

    &#182;
    
Grammar before para 1
&#160;
  </TD>
<TD valign="top">
        In the third
        production, "enum ::opt nested-name-specifieropt
        identifier", enum should not be in italics; its referring
        to the enum keyword.
&#160;
  </TD>
<TD valign="top">
        Change to keyword font
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK94">UK 94</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/383">
     [383]
    </A></TD>
<TD valign="top">
7.1.6.4

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The auto type-specifier signifies that the
        type of an object being declared shall be deduced from its
        initializer or specified explicitly at the end of a
        function declarator. A function declarator does not declare
        an object.
&#160;
  </TD>
<TD valign="top">
        The auto
        type-specifier signifies that the type of an object being
        declared shall be deduced from its initializer or that the
        return type of a function is specified explicitly at the
        end of a function declarator.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK95">UK 95</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/396">
     [396]
    </A></TD>
<TD valign="top">
7.1.6.4

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        (See also
        c++std-core-13583) This paragraph allows auto "in the
        type-specifier-seq in a new-type-id (5.3.4)" (and nowhere
        else not listed). Specifically, it isn't allowed in a
        type-id in a new-expression. That allows "new auto (42)",
        but not "new (auto)(42)". However, 5.3.4/2 suggests the
        latter should be allowed "If the auto type-specifier
        appears in the type-specifier-seq of a new-type-id or
        type-id of a new-expression ...". The inconsistency should
        be resolved, ideally in favour of allowing both forms.
&#160;
  </TD>
<TD valign="top">
        Change "in a new-type-id" to "in a
        new-type-id or type-id in a new-expression".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#746">746</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR24">FR 24</A></TD>
<TD valign="top">
7.1.6.4
[auto
specifier]
&#160;
  </TD>
<TD valign="top">
        Now that 'auto' is finally
        used in its most obvious sense to state `deduce the type of
        this variable from initializer', it should also be allowed
        in template parameter declarations, as in
         <BR><BR>template&lt;auto n&gt; struct
        X { /* &#8230; */ };
        <BR><BR>X&lt;903&gt; x;
        <BR><BR>
        X&lt;&amp;Widget::callback&gt; y;
        <BR><BR>instead of the current, often
        verbose and cumbersome
        <BR><BR><span lang="fr-FR">template&lt;typename T, T n&gt; struct X { /*
        &#8230;</span> <font face="Consolas, monospace">*/
        };</font>
        <BR><BR>X&lt;int,903&gt; x;
        <BR><BR>X&lt;void
        (Widget::*)(),&amp;Widget::callback&gt; y;
        <BR><BR>We understand that 'auto' is
        used in 14.1/18 in a different way (for constrained
        template), but that usable appears very strange syntax,
        unnatural and does not fit well with the usage in this
        section.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus to make this change at this point in the
standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US38">US 38</A></TD>
<TD valign="top">
7.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The
        discussion of attribute specifiers should be a separate
        paragraph.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
It's okay where it is. It's a list of constraints on the grammar.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US39">US 39</A></TD>
<TD valign="top">
7.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The
        paragraph says in part "An opaque-enum-declaration
        declaring an unscoped enumeration shall not omit the
        enum-base." This statement implies that the base may be
        omitted for scoped enumerations, which is somewhat
        inconsistent with paragraph 3 and somewhat consistent with
        paragraph 5.
&#160;
  </TD>
<TD valign="top">
        As this implication leaves no
        representation, it should be either affirmed here or the
        statement should be expanded. Perhaps a note is warranted.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The current specification is consistent.  A scoped enumeration with
an omitted <I>enum-base</I> has an underlying type of <TT>int</TT>.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP13">JP 13</A></TD>
<TD valign="top">
7.2

    &#182;
    
para 3
&#160;
  </TD>
<TD valign="top">
        In
        the description for an unscoped enumeration, enum-base in
        redeclaration must be the same underlying type as in the
        1st declaration, but it is not described explicitly, while
        it is referred that all enum-bases in redeclarations must
        specify the same underlying type.
&#160;
  </TD>
<TD valign="top">
        Replace the description, "same underlying type", with
        "same as underlying type of (previous) declaration."
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK96">UK 96</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/384">
     [384]
    </A></TD>
<TD valign="top">
7.2

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
        enum E { }; What
        are the values of E? It has neither a smallest nor largest
        enumerator, so paragraph 7 doesn't help. (Paragraph 6
        indicates that the underlying type is as if E had a single
        enumerator with value 0, but that does not define the
        values of E.)
&#160;
  </TD>
<TD valign="top">
        Add a second sentence to paragraph 7
        (before "Otherwise"): "If the enumerator-list is empty, 0
        is the only value of the enumeration."
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#628">628</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK97">UK 97</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/385">
     [385]
    </A></TD>
<TD valign="top">
7.2

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
        Missing
        punctuation after "blue" in: "The possible values of an
        object of type color are red, yellow, green, blue these
        values can be converted ..."
&#160;
  </TD>
<TD valign="top">
        Add a semicolon: "The possible values of an
        object of type color are red, yellow, green, blue; these
        values can be converted ..."
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK98">UK 98</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/402">
     [402]
    </A></TD>
<TD valign="top">
7.2

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
        It would be
        useful to be able to determine the underlying type of an
        arbitrary enumeration type. This would allow safe casting
        to an integral type (especially needed for scoped enums,
        which do not promote), and would allow use of
        numeric_limits. In general it makes generic programming
        with enumerations easier.
&#160;
  </TD>
<TD valign="top">
        Add a TransformationTrait to 20.5.6 that
        returns the underlying type of an enumeration type.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1055">1055</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Section reference should be 20.5.6 instead of 7.2.
Name of trait changed to underlying_type.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK99">UK 99</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/421">
     [421]
    </A></TD>
<TD valign="top">
7.2

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        It is unclear
        whether an enumeration type is complete after an
        opaque-enum-declaration. This paragraph only says so in a
        note, and the general rule in 3.9/5 ("Incompletely-defined
        object types ... are incomplete types") is unclear in this
        situation.
&#160;
  </TD>
<TD valign="top">
        Move "an enumeration declared by an
        opaque-enum-declaration ... is a complete type" from the
        note to normative text.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The definition of an incomplete type in 3.9 paragraph 5 does not mention
opaque enumeration types; therefore, an opaque enumeration type is not
an incomplete type.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP14">JP 14</A></TD>
<TD valign="top">
7.3.1
&#160;
  </TD>
<TD valign="top">
<P>The description of the behavior when a member that was
defined with same name in other namespace was referred.</P>
<UL><LI><P>
It seems that the behavior of the following case is not
defined. So we think that it is necessary to define that.</P>
<PRE>
  namespace Q {
    inline namespace V {
      int g;
    }
    int g;
  }
  Q::g = 1; // ill-fromed,
            // Q::V::g = 1;,
            // or Q::g = 1;?
</PRE>
</LI>
<LI><P>
Add that the following case is ill-formed to more easily
to understand.</P>
<PRE>
  namespace Q {
    inline namespace V1 {
      int g;
    }
    inline namespace V2 {
      int g;
    }
  }
  Q::g = 1;  // ill-formed
</PRE>
</LI></UL>
&#160;
  </TD>
<TD valign="top">
        Add the description of the behavior when a member that was
        defined with same name in other namespace was referred.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#812">812</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK100">UK 100</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/387">
     [387]
    </A></TD>
<TD valign="top">
7.3.3

    &#182;
    
10 and 13
&#160;
  </TD>
<TD valign="top">
        Para 10 says "A
        using-declaration is a declaration and can therefore be
        used repeatedly where (and only where) multiple
        declarations are allowed." Para 13 says "Since a
        using-declaration is a declaration, the restrictions on
        declarations of the same name in the same declarative
        region (3.3) also apply to using-declarations." These
        appear to be saying exactly the same thing.
&#160;
  </TD>
<TD valign="top">
        Delete para 10, moving its example into
        para 13.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The two citations are different: paragraph 10 is referring to repeated
declarations of the same entity, while paragraph 13 deals with declarations
of different entities with the same name.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK101">UK 101</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/388">
     [388]
    </A></TD>
<TD valign="top">
7.3.3

    &#182;
    
20
&#160;
  </TD>
<TD valign="top">
        If a
        using-declaration uses the keyword typename and specifies a
        dependent name (14.6.2), the name introduced by the
        using-declaration is treated as a typedef-name (7.1.3).
        That doesn't specify at all what the effect of using
        typename with a non-dependent name is. Is it allowed? What
        about outside any template? What if the name isn't a type?
        (14.6/4 doesn't cover this, I think.)
&#160;
  </TD>
<TD valign="top">
        Allow typename for non-dependent names iff
        they refer to a type.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#813">813</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE12">DE 12</A></TD>
<TD valign="top">
7.3.3

    &#182;
    
p15
&#160;
  </TD>
<TD valign="top">
        DE-12
        Overriding and hiding of member functions named in
        using-declarations should consider ref-qualifiers, because
        they are part of the function type.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#731">731</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR25">FR 25</A></TD>
<TD valign="top">
7.3.3
[The using
declaration]

    &#182;
    
Para 21
&#160;
  </TD>
<TD valign="top">
        The syntax for concept map alias is unnecessarily both
        confused and verbose.
&#160;
  </TD>
<TD valign="top">
        We strongly suggest
        simplifications, e.g.
        <BR><BR>using N1::C&lt;int&gt;;
        <BR><BR>that fits well with existing
        constructs. The syntactic complexity is too high for a new
        feature presumably designed to support sound programming.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The complexity is considered necessary to allow concepts and concept
maps to be members of different namespaces, as illustrated in the
example.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK102">UK 102</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/389">
     [389]
    </A></TD>
<TD valign="top">
7.3.4

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        This paragraph
        says "If name lookup finds a declaration for a name in two
        different namespaces, and the declarations do not declare
        the same entity and do not declare functions, the use of
        the name is ill-formed." But the example uses declaration
        of functions, so is not covered by this paragraph.
&#160;
  </TD>
<TD valign="top">
        Move the example to paragraph 7, and/or
        replace it with an appropriate example.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Changed the example slightly to make it clearer.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US40">US 40</A></TD>
<TD valign="top">
7.6
&#160;
  </TD>
<TD valign="top">
        The
        list of attributes is missing an attribute to indicate that
        a function with a <font size="2" style="font-size: 11pt"><code>throw()</code> (throws nothing)
        clause need not have the <code>unexpected()</code> catch
        clause generated. This attribute was a motivating example
        for the attribute syntax, and its omission is
        surprising.</font>
&#160;
  </TD>
<TD valign="top">
        Add the attribute.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#814">814</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US41">US 41</A></TD>
<TD valign="top">
7.6
&#160;
  </TD>
<TD valign="top">
        A
        common problem is unintentionally declaring a new virtual
        member function instead of overriding a base virtual member
        function.
&#160;
  </TD>
<TD valign="top">
        An attribute stating intent to
        override would enable better diagnostics.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#939">939</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.html">
     N2928</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR26">FR 26</A></TD>
<TD valign="top">
7.6[Attributes]
&#160;
  </TD>
<TD valign="top">
        Are they part of object types
        or not? The section does not appear to indicate that
        clearly.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
None of the standard attributes says that it is part of the type of an
object, which would be required for it to be so. Nonstandard attributes
might be, but nothing can be said normatively about such attributes.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI1">FI 1</A></TD>
<TD valign="top">
7.6
&#160;
  </TD>
<TD valign="top">
        Add override-attribute for functions in order to avoid
        mistakes when overriding functions.
&#160;
  </TD>
<TD valign="top">
        See override&#173;-attribute.doc, override-attribute.ppt
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#939">939</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.html">
     N2928</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR27">FR 27</A></TD>
<TD valign="top">
7.6.1
&#160;
  </TD>
<TD valign="top">
        This section specifies that
        no name lookup is performed on any identifier contained in
        an attribute-token. This in particular implies that, for
        example, it is impossible to define a template class
        parameterized by its alignment. That restriction is
        unacceptable.
        <BR><BR>The original alignment
        proposal made that useful construct possible.
        <BR><BR>Furthermore paragraph 7.6.1/2
        appears contradictory with the rest of that section --
        since no name lookup is performed, how a 'type-id'is
        determined?
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The comment is based on a misunderstanding: what is not looked up is,
informally, the attribute name (e.g., <TT>align</TT>), including the
<I>attribute-namespace</I>, if any.  The
<I>attribute-argument-clause</I>, if present, can have identifiers
that are looked up, depending on the attribute.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK103">UK 103</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/397">
     [397]
    </A></TD>
<TD valign="top">
7.6.1
&#160;
  </TD>
<TD valign="top">
        Attributes should support pack expansion.
        For example, this would be extremely useful with the align
        attribute, directly supporting the (removed) functionality
        of aligned_union. NOte that aligned_union was removed as
        varaiant-unions were considered a complete replacement -
        however this is not true for variadic templates. Adding
        this support to attributes would remove the remaining need,
        and support similar attributes in the future.
&#160;
  </TD>
<TD valign="top">
        Add: attribute... to the grammar for
        attribute-list Add to list in 14.5.3p4: "In an
        attribute-list(7.6.1); the pattern is an attribute."
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#815">815</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/N2933.htm">
     N2933</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK104">UK 104</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/398">
     [398]
    </A></TD>
<TD valign="top">
7.6.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        It is helpful
        for each subclause to contain a short paragraph introducing
        its intent an purpose. 7.6 has such a paragraph, but it is
        nested under a more specific subsection.
&#160;
  </TD>
<TD valign="top">
        7.6.1p1 should move up one level to become
        7.6p1. There grammar should remain under 7.6.1
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
ISO editing guidelines insist that only leaf clauses have text. Moving
this sentence to 7.6 would violate that rule (not that the standard
doesn't violate it in many places, but we shouldn't make this worse
now).
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK105">UK 105</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/448">
     [448]
    </A></TD>
<TD valign="top">
7.6.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        Allowing only one level of namespaces in
        attributes seems unnecessarily limiting.
&#160;
  </TD>
<TD valign="top">
        To: attribute-scoped-token:
        attribute-namespace :: identifier add attribute-namespace
        :: attribute-scoped-token
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This suggestion was discussed earlier and rejected, and there was no
consensus for reconsideration.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK106">UK 106</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/391">
     [391]
    </A></TD>
<TD valign="top">
7.6.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        Extensive use of
        alignment and related terms without cross reference.
&#160;
  </TD>
<TD valign="top">
        Add cross-reference to 3.11.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP15">JP 15</A></TD>
<TD valign="top">
7.6.2
&#160;
  </TD>
<TD valign="top">
        An abbreviation
        of 7.6.2 should be &#8220;[decl.attr.align]&#8221; instead
        of &#8220;[dcl.align]&#8221;.
        Section name &#8220;[dcl.align]&#8221; is not consistent
        with others, because others in 7.6 are the form of
        &#8220;dcl.attr.*&#8221;. In N2761, the section name of
        7.1.7 had been changed from &#8220;[dcl.align]&#8221; to
        &#8220;[dcl.attr.align]&#8221;, but in N2800 it was
        reverted to &#8220;[dcl.align]&#8221; along with a change
        of section number, 7.1.7 to 7.6.2.
&#160;
  </TD>
<TD valign="top">
        Change "[dcl.align]" of 7.6.2 to "[decl.attr.align]".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Tags don't change. This section used to be somewhere else, and the tag
was appropriate there.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK107">UK 107</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/399">
     [399]
    </A></TD>
<TD valign="top">
7.6.3
&#160;
  </TD>
<TD valign="top">
        While undefined
        behaviour might be the best we can guarantee, it would be
        helpful to encourage implementations to diagnose function
        definitions that might execute a return.
&#160;
  </TD>
<TD valign="top">
        Adda a [Note : implementations are
        encouraged to issue a diagnostic where the definition of a
        function marked [[noreturn]] might execute a return
        statement -- end note]
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK108">UK 108</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/401">
     [401]
    </A></TD>
<TD valign="top">
7.6.4

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        It is unclear
        why no diagnostic is required for an easily detectable
        violation. It is even more surprising that the associated
        footnote mandates behaviour for an ill-formed program.
&#160;
  </TD>
<TD valign="top">
        Strike "no diagnostic required" and the
        associated footnote.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#816">816</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US42">US 42</A></TD>
<TD valign="top">
7.6.4
&#160;
  </TD>
<TD valign="top">
        The
        meaning of the <font size="2" style="font-size: 11pt"><code>[[final]]</code> attribute applied
        to classes is inconsistent with other languages and not
        desirable in its own right.</font>
&#160;
  </TD>
<TD valign="top">
        Modify the semantics of <font size="2" style="font-size: 11pt"><code>[[final]]</code> applied to
        classes. See the attached paper "Issues with the C++
        Standard" under Chapter 7 "Meaning of
        <code>[[final]]</code> attribute applied to
        classes".</font>
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#817">817</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK109">UK 109</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/392">
     [392]
    </A></TD>
<TD valign="top">
7.6.5

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        The example code
        refers in comments to "Compilation unit" A and B. The term
        should be "Translation unit" (2/1)
&#160;
  </TD>
<TD valign="top">
        Replace "Compilation" with "Translation" in
        two places
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK110">UK 110</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/393">
     [393]
    </A></TD>
<TD valign="top">
7.6.5

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        The code in the
        example (compilation unit A) has:
        "foo_head[i].load(memory_order_consume)". foo_head[i] is of
        type foo *, so it does not have a load member.
&#160;
  </TD>
<TD valign="top">
        Change the type of foo_head to
        atomic&lt;foo *&gt;[].
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US43">US 43</A></TD>
<TD valign="top">
8
&#160;
  </TD>
<TD valign="top">
        With the introduction of late-specified return types for
        functions and lambda expressions, we now have three
        different syntaxes for declaring functions. The <font size="2" style="font-size: 11pt"><code>-&gt;</code> late
        declaration is used in two. The <code>auto</code> keyword
        is used in one, but also used differently in variable
        definitions.</font>
&#160;
  </TD>
<TD valign="top">
        Some simplification is needed.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus to make a change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK111">UK 111</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/457">
     [457]
    </A></TD>
<TD valign="top">
8.3.5

    &#182;
    
13
&#160;
  </TD>
<TD valign="top">
        Example missing
        closing bracket in template&lt;typename... T&gt; void f(T
        (* ...t)(int, int);
&#160;
  </TD>
<TD valign="top">
        Add closing bracket like this:
        template&lt;typename... T&gt; void f(T (* ...t)(int, int));
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US44">US 44</A></TD>
<TD valign="top">
8.3.5

    &#182;
    
13
&#160;
  </TD>
<TD valign="top">
        In
        the Example, "template void f(T (* ...t)(int, int);" is
        missing a close parenthesis.
&#160;
  </TD>
<TD valign="top">
        It presumably should read:
        "template void f(T (* ...t))(int, int);".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US45">US 45</A></TD>
<TD valign="top">
8.3.5

    &#182;
    
13
&#160;
  </TD>
<TD valign="top">
        At present,
        function parameter packs can only occur at the end of a
        parameter-declaration-list. This restriction unnecessarily
        prohibits uses of function parameter packs in cases where
        template argument deduction isn&#8217;t needed, e.g.,
        <BR><BR>
        template&lt;class... T&gt; struct X { };
        <BR><BR>
        template&lt;class... T1, class... T2&gt;
        <BR>struct
        X&lt;pair&lt;T1, T2&gt;...&gt; {
        <BR>void f(T1...,
        T2...);
        <BR>};
        <BR><BR>More
        importantly, this restriction is inconsistent with the way
        pack expansions are handled. For example, this template is
        well-formed (but X&lt;T..., int&gt; is a non-deduced
        context):
        <BR><BR>
        template&lt;class... T&gt; void f(X&lt;T..., int&gt;);
        <BR><BR>Therefore, the restriction that limits
        function parameter packs to the end of the
        parameter-declaration-list should be removed. Instead,
        function parameter packs not at the end of the
        parameter-declaration-list should be considered non-deduced
        contexts.
&#160;
  </TD>
<TD valign="top">
        In 8.3.5p13,
        remove the sentence &#8220;<span lang="">A function
        parameter pack, if present, shall occur at the end of the
        parameter-declaration-list.&#8221;</span>
        <BR><BR><span lang="">In
        14.8.2.1p1, replace the phrase &#8220;For a function
        parameter pack&#8221; with &#8220;For a function parameter
        pack that occurs at the end of a</span> <font size="3" face="Helvetica, sans-serif"><span lang=""><i>parameter-declaration-list</i>&#8221;.</span></font>
        <BR><BR><span lang="">Replace the note text &#8220;A function parameter pack
        can only occur at the end of a
        parameter-declaration-</span>list (8.3.5).&#8221; with
        &#8220;A function parameter pack that does not occur at the
        end of a parameter-declaration-list is a non-deduced
        context.&#8221;
        <BR><BR>In 14.8.2.5p5,
        add a new bullet: &#8220;A function parameter pack that
        does not occur at the end of its
        parameter-declaration-list.&#8221;
        <BR><BR>In 14.8.2.5p10,
        replace &#8220;<span lang="">If</span> <font size="3" face="Helvetica, sans-serif">the parameter-declaration
        corresponding to Pi is a function parameter pack&#8221;
        with &#8220;<span lang="">If</span> <font size="3">the
        parameter-declaration corresponding to Pi is a function
        parameter pack and Pi occurs at the end of the
        parameter-declaration-list&#8221;.</font></font>
        <BR><BR>Replace
        <font size="3" face="Helvetica, sans-serif"><span lang="">the note text &#8220;A function parameter pack can only
        occur at the end of a parameter-declaration-</span>list
        (8.3.5).&#8221; with &#8220;A function parameter pack that
        does not occur at the end of a parameter-declaration-list
        is a non-deduced context.&#8221;</font>
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#818">818</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE13">DE 13</A></TD>
<TD valign="top">
8.4

    &#182;
    
p2
&#160;
  </TD>
<TD valign="top">
        DE-13 The second paragraph, quoting the grammar for the
        declarator of a function declaration, is not considering
        late-specified return types and attributes.
&#160;
  </TD>
<TD valign="top">
        Properly quote the grammar from 8.3.5.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#732">732</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf">
     N2927</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP16">JP 16</A></TD>
<TD valign="top">
8.5

    &#182;
    
        15<sup>th</sup> <font size="2" style="font-size: 11pt">para, 1<sup>st</sup> line</font>
&#160;
  </TD>
<TD valign="top">
        Typo, duplicated "in"
        <BR><BR>"The initialization that
        occurs in in the forms"
&#160;
  </TD>
<TD valign="top">
        Remove one.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US46">US 46</A></TD>
<TD valign="top">
8.5.3
&#160;
  </TD>
<TD valign="top">
        The ability for
        an rvalue reference to bind to an lvalue opens a
        type-safety hole that becomes very dangerous with concepts.
        For example, consider vector&#8217;s push_back operation:
        <BR><BR>requires
        MoveConstructible&lt;T&gt; void push_back(T&amp;&amp;);
        <BR><BR>requires
        CopyConstructible&lt;T&gt; void push_back(const T&amp;);
        <BR><BR>For a
        copy-constructible T (which is also move-constructible),
        push_back does the right thing. However, if T is something
        that is move-constructible (e.g., unique_ptr&lt;int&gt;),
        the second overload is removed from considered (it is
        effectively SFINAE&#8217;d away), so only the first
        overload remains. Therefore, one could accidentally call
        push_back with an lvalue of type T, and push_back would
        silently move from the lvalue. The same problem occurs
        without concepts (albeit less frequently).
&#160;
  </TD>
<TD valign="top">
        Prohibit rvalue
        references from binding to lvalues.
        <BR><BR>Unfortunately
        this change will break some current use cases of rvalue
        reference including the use of rvalue streams, and of the
        forward function itself. To resolve this we may want to
        consider three types of references:
        <ol>
          <li> The current
            reference.</li>
          <li> A non-const
            reference that only binds to rvalues.</li>
          <li> A non-const
            reference that will bind to both lvalues and rvalues.</li>
          </ol>
        Still another solution would be to adopt
        the &#8220;deleted function&#8221; solution for all
        functions. This solution is described in comment for 12.1,
        12.4, 12.8, but restricted to special functions in that
        comment. (See US NN).
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">
     N2844</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US49">US 49</A></TD>
<TD valign="top">
8.5.4

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        In the Example, the comments
        could be improved.
&#160;
  </TD>
<TD valign="top">
        See
        the attached paper "Issues with the C++ Standard" under
        "Editorial Issues" and "8.5.4/6".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK112">UK 112</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/440">
     [440]
    </A></TD>
<TD valign="top">
9

    &#182;
    
4-9
&#160;
  </TD>
<TD valign="top">
        We now have
        concepts that should (or should not?) map to the terms
        described in Clause 9 - these should be at least
        referenced.
&#160;
  </TD>
<TD valign="top">
        Add appropriate forward references to
        14.9.4
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This seems excessive. If people want to know about concepts they
should read about concepts.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK113">UK 113</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/250">
     [250]
    </A></TD>
<TD valign="top">
9.4.2

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Mis-applied edit from the paper n2756
&#160;
  </TD>
<TD valign="top">
        The term 'constant-initializer' should have
        been struck out when replaced by
        brace-or-equal-initializer. There are two occurrences in
        this paragraph
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US50">US 50</A></TD>
<TD valign="top">
12.1,
12.4,
12.8
&#160;
  </TD>
<TD valign="top">
        Implicitly-declared default constructors, destructors, copy
        constructors, and copy assignment operators are deleted
        when their definitions would be ill-formed. However, unlike
        with overloading and template argument deduction, access
        control is performed as part of the check for making one of
        these special function deleted. This inconsistency should
        be removed.
        <BR><BR>This change
        would sacrifice some backward compatibility in favor of
        consistency. With the current wording, checking that the
        following class &#8216;A&#8217; is CopyConstructible would
        proceed without error (it is not CopyConstructible):
        <BR><BR>class A {
        A(const A&amp;); };
        <BR><BR>With the
        proposed change, testing whether A is CopyConstructible
        would produce a diagnostic. To fix the problem, the user
        would have to use a deleted function:
        <BR><BR>class A {
        A(const A&amp;) = delete; };
&#160;
  </TD>
<TD valign="top">
        In 12.1p5,
        remove the phrase &#8220;<span lang="">or inaccessible from
        the implicitly-declared default</span> <font size="3" face="Helvetica, sans-serif">constructor&#8221;.</font>
        <BR><BR>In 12.4p3,
        remove the phrase &#8220;<span lang="">or a destructor that
        is inaccessible from the implicitly-declared
        destructor,&#8221; and the phrase &#8220;or a destructor
        that is inaccessible from the</span> <font size="3" face="Helvetica, sans-serif">implicitly-declared
        destructor<span lang="">&#8221;.</span></font>
        <BR><BR>In 12.8p5,
        remove the phrase &#8220;<span lang="">or inaccessible from
        the implicitly-declared copy constructor&#8221; from the
        two places it occurs.</span>
        <BR><BR>In 12.8p10,
        remove the phrase &#8220;<span lang="">or inaccessible from
        the implicitly-declared copy assignment operator&#8221;
        from the two places it occurs.</span>
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#819">819</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The current treatment is sufficiently useful to warrant the inconsistency
with the other handling of access control.  In particular, it enables such
cases to be detected by SFINAE.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR28">FR 28</A></TD>
<TD valign="top">
12.6.1
[Explicit
initialization]
&#160;
  </TD>
<TD valign="top">
        This section, in particular the example with `g' appears
        contradictory with the syntax for uniform initialization.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US51">US 51</A></TD>
<TD valign="top">
12.6.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The
        discussion of delegating constructors should be in its own
        paragraph.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK114">UK 114</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/167">
     [167]
    </A></TD>
<TD valign="top">
12.6.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        Despite all the attempts to unify
        initialization syntax, it is still not possible to
        copy-initialize base classes or non-static data members,
        which means the explicit keyword cannot have a bearing
        during evaluation of a constructor. A minimal addition to
        the grammar, allowing an optional = between the
        mem-initializer-id and braced-init-list would allow the
        user to choose between copy and direct initialization
&#160;
  </TD>
<TD valign="top">
        Ammend the
        grammar for mem-initializer: mem-initializer-id =OPT
        braced-init-list Extend p3 to allow for Copy Initialization
        if the optional = is present: 3 The expression-list or
        braced-init-list in a mem-initializer is used to initialize
        the base class or non-static data member subobject denoted
        by the mem-initializer-id according to the initialization
        rules of 8.5 for direct-initialization, OR
        COPY-INITIALIZATION IF THE OPTIONAL = IS PRESENT BETWEEN
        THE MEM-INITIALIZER-ID and the BRACED-INIT-LIST.
        [Example:...
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
There was no consensus for making the change as described. The concerns are
addressed for members (but not for base classes) by using the "="
form of the <I>brace-or-equal-initializer</I> on a member declaration
instead of a <I>mem-initializer</I>.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US52">US 52</A></TD>
<TD valign="top">
13.5.8

    &#182;
    
&#182; 5
&#160;
  </TD>
<TD valign="top">
        A word is misspelled.
&#160;
  </TD>
<TD valign="top">
        Change &#8220;shal&#8221; to &#8220;shall&#8221;.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK115">UK 115</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/432">
     [432]
    </A></TD>
<TD valign="top">
14

    &#182;
    
6-11
&#160;
  </TD>
<TD valign="top">
        Exported
        templates were a great idea that is generally understood to
        have failed. In the decade since the standard was adopted,
        only one implementation has appeared. No current vendors
        appear interested in creating another. We tentatively
        suggest this makes the feature ripe for deprecation. Our
        main concern with deprecation is that it might turn out
        that exported constrained templates become an important
        compile-time optimization, as the constraints would be
        checked once in the exported definition and not in each
        translation unit consuming the exported declarations.
&#160;
  </TD>
<TD valign="top">
        Consider deprecating exported templates,
        but no action yet. Examine interaction with constrained
        templates, and see if other more appropriate mechanism will
        support compile-time optimization.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#820">820</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK116">UK 116</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/434">
     [434]
    </A></TD>
<TD valign="top">
14

    &#182;
    
6-11
&#160;
  </TD>
<TD valign="top">
        Is it possible
        to export a concept map template? The current wording
        suggests it is possible, but it is not entirely clear what
        it would mean.
&#160;
  </TD>
<TD valign="top">
        Either prohibit exporting concept map
        templates, or more directly address what it means to export
        a concept map.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#821">821</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK117">UK 117</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/430">
     [430]
    </A></TD>
<TD valign="top">
14

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        It would be nice
        to allow template alias within a function scope, and
        possibly a scoped concept map. As these affect name lookup
        and resolution, rather than defining new callable code,
        they are not seen to present the same problems that
        prevented class and function templates in the past.
&#160;
  </TD>
<TD valign="top">
        Allow template aliases to be declared
        inside a function scope, and consider scoped concept maps.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#822">822</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was non consensus for making this change at this point in the
standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK118">UK 118</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/431">
     [431]
    </A></TD>
<TD valign="top">
14

    &#182;
    
6-11
&#160;
  </TD>
<TD valign="top">
        Exported
        templates are a complicated feature with surprisingly
        little text. To make this important text more visible,
        split it off into its own subclause [temp.export]
&#160;
  </TD>
<TD valign="top">
        Create a new subclause [temp.export]
        containing 14p6-11. Move 14p12 ahead of this subclause.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK119">UK 119</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/433">
     [433]
    </A></TD>
<TD valign="top">
14

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        Does a concept
        map have linkage? Reading this paragraph and 3.5 suggests a
        concept map template has external linkage, but not a
        'regular' concept map. Believe this is an oversight that
        the linkage words were not updated to provide an exception,
        rather than linkage of concept maps is intended.
&#160;
  </TD>
<TD valign="top">
        Add an exception that concept map templates
        have no linkage, or add concept maps to the list of
        entities with linkage in 3.5
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#791">791</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK120">UK 120</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/422">
     [422]
    </A></TD>
<TD valign="top">
14.1

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
        As this is the
        first time the phrase &#8220;parameter pack&#8221; appears
        in Ch 14 I would like to see the section 8.3.5 referenced
        here (as well as in 14.1p17).
&#160;
  </TD>
<TD valign="top">
        Insert &#8220;(8.3.5)&#8221; after
        &#8220;parameter pack&#8221;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK121">UK 121</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/423">
     [423]
    </A></TD>
<TD valign="top">
14.1

    &#182;
    
18
&#160;
  </TD>
<TD valign="top">
        The example
        (that follows the normative text) has no begin example
        marker
&#160;
  </TD>
<TD valign="top">
        Prefix the example code with "[ Example:"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR29">FR 29</A></TD>
<TD valign="top">
14.3
[Template
arguments]
&#160;
  </TD>
<TD valign="top">
        Constant expressions of any literal type should be
        allowed as template arguments.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#823">823</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
There was no consensus for the suggested change. A problem was discovered
that literal types with constexpr conversion functions to literal and
enumeration types were not allowed, and issue 823 was opened to address
this omission.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US53">US 53</A></TD>
<TD valign="top">
14.5.1

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
        If the
        requirements of a constrained member that is a copy
        constructor, copy assignment operator, or destructor are
        not satisfied, then that user-declared special function
        will not exist. It appears that, in this case, the special
        function will then be <font size="3" face="Helvetica, sans-serif"><i>implicitly</i> <font size="3">defined, which is likely to either (a) fail to compile
        or (b) produce a function with the wrong semantics. For
        example:</font></font>
        <BR><BR>
        template&lt;ObjectType T&gt; class vector {
        <BR>T* first, last,
        end;
        <BR>public:
        <BR>requires
        CopyConstructible&lt;T&gt; vector(const vector&amp;);
        <BR>};
        <BR><BR>If instantiated with a type that is not
        CopyConstructible, vector will get an implicitly-defined
        copy constructor that performs a copy of the pointers.
&#160;
  </TD>
<TD valign="top">
        Add to 14.5.1p5:
        <BR><BR>If the constrained member is a copy
        constructor (12.8), destructor (12.4), or copy assignment
        operator and its template requirements are not satisfied,
        then a copy constructor, destructor, or copy assignment
        operator, respectively, with the same signature as the
        constrained member (after substituting the class
        template&#8217;s template arguments for its template
        parameters) will be declared as a deleted function (8.4).
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#824">824</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK122">UK 122</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/426">
     [426]
    </A></TD>
<TD valign="top">
14.5.3

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        Variadic
        templates should be supported in axioms. There are axioms
        in the library that rely on this feature, such as the
        FrontEmplacement axiom in FrontEmplacementContainer
        (23.1.6.1p10)
&#160;
  </TD>
<TD valign="top">
        Add clarification in p2 that function
        parameter packs can be used to declare axioms, much like p1
        clarifies they can be used to declare concepts as well as
        templates.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR30">FR 30</A></TD>
<TD valign="top">
14.5.7
[Template
aliases]
&#160;
  </TD>
<TD valign="top">
        When are two template alias
        names equivalent?
        E.g. given
        <BR><BR>
        template&lt;template&lt;class&gt; class&gt; struct X { };
        <BR><BR>
        template&lt;typename,typename&gt; struct Y { };
        <BR>template&lt;typename T&gt;
        <BR>using Z1 = Y&lt;int,T&gt;;
        <BR>template&lt;typename T&gt;
        <BR>using Z2 = Y&lt;int,T&gt;;
        <BR><BR>Are the types X&lt;Z1&gt; and
        X&lt;Z2&gt; equivalent?
        <BR><BR>We would suggest yes (since
        Z1&lt;T&gt; and Z2&lt;T&gt; are the same for all T), but we
        do not see any wording to that effect.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This is already clear in the Standard; see 14.5.7 paragraph 2 and 14.4
paragraph 1.  The last example in 14.4 paragraph 1 is very similar to
the one given here.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP17">JP 17</A></TD>
<TD valign="top">
14.7.2

    &#182;
    
2<sup>nd</sup> <font size="2" style="font-size: 11pt">para, 15<sup>th</sup>
        line</font>
&#160;
  </TD>
<TD valign="top">
        Typo.
        <BR><BR>if
        that namespace is inline, any namespace from its enclosing
        namespace set.
        <BR><BR>
        should be
        <BR><BR>if
        that namespace is inline, any namespace <font size="2" style="font-size: 11pt"><font color="#339966">forming</font> its enclosing namespace
        set.</font>
&#160;
  </TD>
<TD valign="top">
        Replace "from" with "forming"
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The current wording is correct.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE14">DE 14</A></TD>
<TD valign="top">
14.7.3

    &#182;
    
p1
&#160;
  </TD>
<TD valign="top">
        DE-14 The bulleted list neither addresses "member
        function template of a class" nor "member class template of
        a class".
&#160;
  </TD>
<TD valign="top">
        Add the respective bullets.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#730">730</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP18">JP 18</A></TD>
<TD valign="top">
14.7.3

    &#182;
    
2<sup>nd</sup> <font size="2" style="font-size: 11pt">para, 2<sup>nd</sup>
        line</font>
&#160;
  </TD>
<TD valign="top">
        Typo,
        <BR><BR>any
        namespace from its enclosing namespace set
        <BR><BR>
        should be
        <BR><BR>any
        namespace <font size="2" style="font-size: 11pt"><font color="#339966">forming</font> its
        enclosing namespace set</font>
&#160;
  </TD>
<TD valign="top">
        Replace "from" with "forming"
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The current wording is correct.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP19">JP 19</A></TD>
<TD valign="top">
14.8.2

    &#182;
    
6<sup>th</sup> <font size="2" style="font-size: 11pt">para, 1<sup>st</sup>
        line</font>
&#160;
  </TD>
<TD valign="top">
        Typo, duplicated "is"
        <BR><BR>"At certain
        points in the template argument deduction process it <u>is
        is</u> necessary"
&#160;
  </TD>
<TD valign="top">
        Remove one
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US54">US 54</A></TD>
<TD valign="top">
14.9
[concept],
        14.10
[temp.
        constrained]
&#160;
  </TD>
<TD valign="top">
        Concepts is of course the largest new feature in C++0x
        (in terms of new text inserted into the wording), and
        already we have found some significant defects with it. So
        far nothing devastating has been found, but more time is
        needed to shake more bugs out.
&#160;
  </TD>
<TD valign="top">
        I propose no specific change here.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US55">US 55</A></TD>
<TD valign="top">
14.9.1

    &#182;
    
&#182; 6
&#160;
  </TD>
<TD valign="top">
        The paragraph number is in the wrong place, causing a
        grammar rule to be indented more than its fellows.
&#160;
  </TD>
<TD valign="top">
        Move the paragraph number so as to follow the grammar
        rules, thus numbering the single sentence, &#8220;The body
        of a concept &#8230; .&#8221;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US56">US 56</A></TD>
<TD valign="top">
14.9.1

    &#182;
    
&#182; 6
&#160;
  </TD>
<TD valign="top">
        The sentence contains two references to 14.9.1.3
        [concept.req].
&#160;
  </TD>
<TD valign="top">
        Change the second such reference (at the end of the
        sentence) to 14.9.1.4 [concept.axiom].
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Yes; they apply to different terms.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US57">US 57</A></TD>
<TD valign="top">
14.9.1.4

    &#182;
    
&#182; 3
&#160;
  </TD>
<TD valign="top">
        A word is misplaced, changing the intended meaning.
&#160;
  </TD>
<TD valign="top">
        Change &#8220;only find &#8230; if&#8221; to &#8220;find
        &#8230; only if&#8221;.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
These mean the same thing, and the latter is stilted.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US58">US 58</A></TD>
<TD valign="top">
14.9.1.4

    &#182;
    
&#182; 3
&#160;
  </TD>
<TD valign="top">
        The listed phrases are not grammatically parallel.
&#160;
  </TD>
<TD valign="top">
        Insert &#8220;in&#8221; before &#8220;one&#8221; so as
        to obtain &#8220;... in the concept, in one of its less
        refined concepts, or in an associated requirement.&#8221;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US59">US 59</A></TD>
<TD valign="top">
14.9.1.4
&#160;
  </TD>
<TD valign="top">
        Axioms are under-specified and provide
        little benefit to programmers, so they should be removed
        from the working paper. The optimizations permitted by
        axioms (see 14.9.1.4p4-5) are not compulsory (and,
        therefore, programmers cannot rely on them) and the
        semantics expressed by axioms cannot be verified by any
        implementation. The resulting specification has lead to
        great confusion (see the reflector thread &#8220;Are
        floating point types Regular?&#8221; starting with
        c++std-lib-22717). Given the level of confusion and the
        inability to verify the correctness of axioms, it is likely
        that many axioms written by programmers (including those
        specified in the candidate draft) will be incorrect.
&#160;
  </TD>
<TD valign="top">
        Remove clause
        14.9.1.4 [concept.axiom]
        <BR><BR>In 2.11p1,
        remove &#8220;axiom&#8221; from the list of keywords.
        <BR><BR>In 14.5.8p7,
        remove &#8220;, or if the resulting concept map fails to
        satisfy the axioms of the corresponding concept&#8221;
        <BR><BR>In 14.9.1p6,
        remove axiom-definition from the list of grammar
        productions for concept-member-specifier. Remove &#8220;,
        and axioms&#8221; from the final sentence, and instead
        &#8220;and&#8221; prior to &#8220;associated
        requirements&#8221; in the final sentence.
        <BR><BR>Remove paragraph
        14 of clause 14.9.2.
        <BR><BR>In 14.10.1p6,
        remove the sentence, &#8220;When the
        concept-instance-alias-def appears in the optional
        requires-clause of an axiom-definition (14.9.1.4), the
        potential scope of the identifier begins at its point of
        declaration and terminates at the end of the
        axiom-de&#64257;nition.&#8221;
        <BR><BR>In clauses
        20.2.5, 20.2.8, 23.1.6.1, 23.1.6.2, and 24.1.4, remove the
        axiom-definitions and replace them with paragraphs (denoted
        Requires, Postconditions, or Effects, as appropriate) that
        express the intended semantics of the concepts from which
        the axiom-definitions were removed.
        <BR><BR>In 24.1.4p2,
        replace the word &#8220;axiom&#8221; with
        &#8220;condition.&#8221;
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR31">FR 31</A></TD>
<TD valign="top">
14.9.1.4
[Axioms]
&#160;
  </TD>
<TD valign="top">
        This section states that an
        axiom-definition defines a new semantics axiom but is
        unusually vague as to what those semantics might be.
        <BR><BR>The use of the '==' and '!='
        with completely new semantics, unrelated to anything we
        have seen before in C++ is both unwise and confusing,
        especially if the types involved in the expressions happen
        to have operator== and operator!= defined.
        <BR><BR>We strongly suggest use of
        different tokens, e.g. <font face="Consolas, monospace">&#61683;, and opposed to this obscure
        usage/overload.</font>
        <BR><BR>The description is very
        vague. How many times is an implementation permitted to
        replace one expression by another one when they have side
        effects?
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE15">DE 15</A></TD>
<TD valign="top">
14.9.1.4
&#160;
  </TD>
<TD valign="top">
        DE-15 There is no implementation experience for axioms.
        Use of axioms is an area of active scientific research. It
        is likely that syntax changes will become necessary to make
        good use of axioms; having the syntax space already crowded
        is unhelpful. Axioms ought to be useful in concepts
        applicable to floating-point types (such as
        EqualityComparable), but IEEE floating-point types have
        special values such as NaN violating the axioms.
&#160;
  </TD>
<TD valign="top">
        Remove section 14.9.1.4 and any reference to axioms in
        the rest of the proposed standard other than the keyword
        reservation in section 2.11.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK123">UK 123</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/248">
     [248]
    </A></TD>
<TD valign="top">
14.9.1.4
&#160;
  </TD>
<TD valign="top">
        auto concepts
        and axioms are incompatible. An axiom defines the semantics
        of an operaton or set of operations that describes the run
        time behaviour. A concept describes purely syntactic
        requirements at compile time. Where an auto concept will
        match anything that meets the syntax requirements, there is
        no way to know if the axioms will be met or not, and no way
        to opt out via some kind of negative concept map.
&#160;
  </TD>
<TD valign="top">
        Add a paragraph making axioms ill-formed
        inside an auto concept.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK124">UK 124</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/288">
     [288]
    </A></TD>
<TD valign="top">
14.9.1.4

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        Spelling mistake, double-e in were.
&#160;
  </TD>
<TD valign="top">
        weere -&gt; were
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK125">UK 125</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/289">
     [289]
    </A></TD>
<TD valign="top">
14.9.1.4

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The implicit
        equality comparison operator available to axioms has no
        semantic. It is not clear what expressing the condition if(
        a == b ) { conditional-axiom } would mean if a and b are
        not truly EqualityComparable. We suspect the intent of the
        'implicit defefinition' is to support declaring the
        equivalence of statements, a context where the operator
        will not actually be evaluated.
&#160;
  </TD>
<TD valign="top">
        Define the semantics of the implicitly
        declared comparison operators, or restrict their usage to
        declaring equivalence between statements.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK126">UK 126</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/438">
     [438]
    </A></TD>
<TD valign="top">
14.9.4

    &#182;
    
41
&#160;
  </TD>
<TD valign="top">
        This paragraph
        contains the only definition of the underlying_type member
        - but it's a note, so not normative.
&#160;
  </TD>
<TD valign="top">
        Move the second sentence to the Requires
        clause in paragraph 42.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK127">UK 127</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/118">
     [118]
    </A></TD>
<TD valign="top">
14.9.4
&#160;
  </TD>
<TD valign="top">
        Provide a
        diagram clearly showing refinement relationship between the
        different support concepts. Several were created during
        development of this clause and they were very helpful.
&#160;
  </TD>
<TD valign="top">
        Provide the diagram.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK128">UK 128</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/435">
     [435]
    </A></TD>
<TD valign="top">
14.9.4

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        It is surprising for many people that
        non-copyable move-only types can be used with a return
        statement, and so Returnable does not always imply
        CopyConstructible.
&#160;
  </TD>
<TD valign="top">
        A non-normative
        note: [Note: 'move only' types that are constructible from
        rvalue references may be Returnable, but not
        CopyConstructible(20.1.8) - end note]
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP20">JP 20</A></TD>
<TD valign="top">
14.9.4

    &#182;
    
2<sup>nd</sup> <font size="2" style="font-size: 11pt">para</font>
&#160;
  </TD>
<TD valign="top">
        Trivially copyable type was added in &#8220;3.9
        Types&#8221;, so we think that it is necessary to add
        concept to trivially copyable type like
        &#8220;TriviallyCopyableType&#8221;.
&#160;
  </TD>
<TD valign="top">
        Add
        TriviallyCopyableType that is trivially copyable type as
        concept.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#825">825</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK129">UK 129</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/128">
     [128]
    </A></TD>
<TD valign="top">
14.10.1,
20.1.2
&#160;
  </TD>
<TD valign="top">
        It should be
        possible to support boolean constant expressions as
        requirements without resorting to defining the True concept
        in the library. Boolean expressions are very likely to be
        constraints when deadline with non-type template parameters
        and variadic templates, and constraints in these cases
        should feel just as natural as constraints on the type
        system.
&#160;
  </TD>
<TD valign="top">
        Remove the True concept and library
        subclause 20.1.2. Provide support in 14.10.1 for boolean
        constant expressions as constraints. This may involve
        overloading the true keyword to disambiguate but ideally
        would not.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#826">826</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US60">US 60</A></TD>
<TD valign="top">
14.10.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The use of &amp;&amp; as the separator for
        a list of requirements has shown itself to be a serious
        teachability problem. The mental model behind
        &#8216;&amp;&amp;&#8217; treats concepts as simple
        predicates, which ignores the role of concepts in
        type-checking templates. The more programmers read into the
        &#8216;&amp;&amp;&#8217; (and especially try to fake ||
        with &amp;&amp; and !), the harder it is for them to
        understand the role of concept maps. Simply changing the
        separator to &#8216;,&#8217; would eliminate a significant
        source of confusion.
&#160;
  </TD>
<TD valign="top">
        Replace
        <BR><BR>
        requirement-list:
        <BR>requirement-list
        ... [opt] &amp;&amp; requirement
        <BR>requirement ...
        [opt]
        <BR><BR>with
        <BR><BR>requirement-list
        <BR>requirement-list
        ...[opt] , requirement
        <BR>requirement ...
        [opt]
        <BR><BR>In 14.5.4p6,
        replace the first sentence with:
        <BR><BR>The
        instantiation of an expansion produces a comma-separated
        list E1, E2, ..., EN, where N is the number of elements in
        the pack expansion parameters.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#827">827</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related features have been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK130">UK 130</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/32">
     [32]
    </A></TD>
<TD valign="top">
15.1

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        With the new
        crrent_exception API it is possible to capture a reference
        to an exception that will outlive its last active handler.
        That is in conflict with the sentance "When the last
        remaining active handler for the exception exits by any
        means other than throw; the temporary object is destroyed
        and the implementation may deallocate the memory for the
        temporary object;"
&#160;
  </TD>
<TD valign="top">
        Update sentence to allow for exceptions
        held in excpetion_ptr objects.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#828">828</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK131">UK 131</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/34">
     [34]
    </A></TD>
<TD valign="top">
15.3

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        A handler
        catching its parameter by rvalue-reference is syntactically
        valid, but will never be activated.
&#160;
  </TD>
<TD valign="top">
        Disallow handlers catching by
        rvalue-reference.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">
     N2844</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK132">UK 132</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/36">
     [36]
    </A></TD>
<TD valign="top">
15.3

    &#182;
    
16
&#160;
  </TD>
<TD valign="top">
        There are
        obscure cases whrere a copy constructor is not usually the
        best match to copy-initialize an object, e.g. A converting
        constructor template taking arguments by non-const
        reference. A footnote explaining such cases would be
        helpful, or the sentance could be rewritten using
        copy-initialization instead of directly calling a copy
        constructor.
&#160;
  </TD>
<TD valign="top">
        Rewite using copy-initialization rather
        than directly invoking the copy constructor
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK133">UK 133</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/37">
     [37]
    </A></TD>
<TD valign="top">
15.4

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        Template aliases
        have the same semantics as a typedef so should also be
        disallowed
&#160;
  </TD>
<TD valign="top">
        add "or alias-declaration" after "shall not
        appear in a typedef declaration".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK134">UK 134</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/38">
     [38]
    </A></TD>
<TD valign="top">
15.4

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        The sentance "An
        exception-specification can also include the class
        std::bad_exception (18.7.2.1)." is redundant.
&#160;
  </TD>
<TD valign="top">
        Either strike the quoted sentance, or add a
        note explaining why it is worth calling special attention
        to this class.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK135">UK 135</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/39">
     [39]
    </A></TD>
<TD valign="top">
15.4

    &#182;
    
8
&#160;
  </TD>
<TD valign="top">
        Unclear if std::unexpected is called before
        or after the function arguments have been destroyed
&#160;
  </TD>
<TD valign="top">
        Clarify the sequence of calling unexpected
        with respect to interesting objects, such as function
        arguments or partially constructed bases and members when
        called from a constructor or destructor
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#829">829</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
15.5.2 paragraph 1 specifies that <TT>std::unexpected</TT> is called
&#8220;immediately after completing stack unwinding&#8221; for the
function whose <I>exception-specification</I> has been violated.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK136">UK 136</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/40">
     [40]
    </A></TD>
<TD valign="top">
15.4
&#160;
  </TD>
<TD valign="top">
        Exception specifications have proven close
        to worthless in practice, while adding a measurable
        overhead to programs. The feature should be deprecated. The
        one exception to the rule is the empty throw specification
        which could serve a legitimate optimizing role if the
        requirement to call the runtime unexpected mechanism was
        relaxed in this case.
&#160;
  </TD>
<TD valign="top">
        Move 15.4 and the parts of 15.5 that refer
        to it to Appendix D. Replace 15.4 with a simpler
        specification for empty throw specifications, where the
        std::unexpected call is conditionally supported allowing
        vendors to choose between optimizing and providing runtime
        checks. Ideally require vendors to provide a mode where the
        runtime checks are always disabled.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#830">830</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK137">UK 137</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/44">
     [44]
    </A></TD>
<TD valign="top">
15.5
&#160;
  </TD>
<TD valign="top">
        There is no
        mention of the current_exception API which can extend the
        lifetime of an exception object. There should at least be a
        forward reference to the library clause 18.7.5
&#160;
  </TD>
<TD valign="top">
        Add another paragraph outlining 18.7.5 and
        the ability of an exception_ptr to extend the lifetime of
        an exception object
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK138">UK 138</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/41">
     [41]
    </A></TD>
<TD valign="top">
15.5.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The third bullet
        is redundant with the first, as it is a subset of the same
        conditions.
&#160;
  </TD>
<TD valign="top">
        Merge the third bullet into the first
        bullet as a note or example.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
They're subtly different. The first bullet is about calls made to
create, copy, and destroy the exception object itself. The third
bullet is about destructors of stack objects during stack unwinding.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK139">UK 139</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/42">
     [42]
    </A></TD>
<TD valign="top">
15.5.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        According to the
        first bullet it is perfectly alright for a library function
        to exit by throwing an exception during stack unwinding,
        This is clearly not true.
&#160;
  </TD>
<TD valign="top">
        Strike the word 'user' from the first
        bullet point.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2841.html">
     N2841</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK140">UK 140</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/43">
     [43]
    </A></TD>
<TD valign="top">
15.5.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The detailed
        specification can fool people into thinking an exception
        will automatically be translated into bad_exception, where
        the default behaviour of std::unexcepted is to immediately
        call std::terminate();
&#160;
  </TD>
<TD valign="top">
        Add a note highlighting the default
        behaviour of std::unexpected if the user does not supply a
        hander-function
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK141">UK 141</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/45">
     [45]
    </A></TD>
<TD valign="top">
15.6
&#160;
  </TD>
<TD valign="top">
        This whole
        subclause is redundant due to 15.1p5 and 15.3p17
&#160;
  </TD>
<TD valign="top">
        Strike 15.6
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK142">UK 142</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/455">
     [455]
    </A></TD>
<TD valign="top">
16.3.5

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        This paragraph
        opens with "[ Note" but has no corresponding "end note ]"
&#160;
  </TD>
<TD valign="top">
        Add "end note ]"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK143">UK 143</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/456">
     [456]
    </A></TD>
<TD valign="top">
16.3.5

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
        Example uses #define t(x,y.z) x ## y ## z
&#160;
  </TD>
<TD valign="top">
        Change "x,y.z" to "x,y,z"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US2">US 2</A></TD>
<TD valign="top">
17-30
&#160;
  </TD>
<TD valign="top">
        The
        active issues identified in WG21 N2806, C++ Standard
        Library Active Issues, must be addressed and appropriate
        action taken.
        <BR>
        <font color="#000080"><u><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">
        http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html</a></u></font>
&#160;
  </TD>
<TD valign="top">
        Appropriate action would
        include making changes to the CD, identifying an issue as
        not requiring a change to the CD, or deferring the issue to
        a later point in time.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#N/A">N/A</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR2">FR 2</A></TD>
<TD valign="top">
General
Comment

    &#182;
    
Library
&#160;
  </TD>
<TD valign="top">
        The adoption of the library `constexpr' proposal was not
        reflected in the draft, despite formal WG21 committee vote.
&#160;
  </TD>
<TD valign="top">
        FR 2
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1156">1156</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US61">US 61</A></TD>
<TD valign="top">
17 onward
&#160;
  </TD>
<TD valign="top">
        The concepts core language feature is applied to only
        some of the Standard Library clauses, and even then not
        always consistently.
&#160;
  </TD>
<TD valign="top">
        Review all
        clauses of the Standard Library, and consistently apply
        concept technology wherever possible and appropriate. The
        proposed wording in WG21 N2781 exemplifies the necessary
        level of detail.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#N/A">N/A</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA2">CA 2</A></TD>
<TD valign="top">
17 Library
&#160;
  </TD>
<TD valign="top">
        &#8220;Concepts&#8221; are a significant new addition to
        the language, but are not exploited uniformly in the
        library as documented in CD 14882.
&#160;
  </TD>
<TD valign="top">
        Fix
        the standard library so that &#8220;Concepts&#8221; are
        used appropriately in the library.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#N/A">N/A</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US62">US 62</A></TD>
<TD valign="top">
17-30
&#160;
  </TD>
<TD valign="top">
        Provide concepts
        and requirements clauses for all standard library templates
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#N/A">N/A</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US63">US 63</A></TD>
<TD valign="top">
17-30
&#160;
  </TD>
<TD valign="top">
        The behavior of the library in the presence of threads
        is incompletely specified.
        <BR><BR>For example, if thread 1 assigns to X, then writes data
        to file f, which is read by thread 2, and then accesses
        variable X, is thread 2 guaranteed to be able to see the
        value assigned to X by thread 1? In other words, does the
        write of the data "happen before" the read?
        <BR><BR>Another example: does simultaneous access using operator
        at() to different characters in the same non-const string
        really introduce a data race?
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1151">1151</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE2">DE 2</A></TD>
<TD valign="top">
17 through 30
&#160;
  </TD>
<TD valign="top">
        DE-2 Marking a constructor with "explicit" has semantics
        even for a constructor with zero or several parameters:
        Such a constructor cannot be used with list-initialization
        in a copy-initialization context, see 13.3.1.7. The
        standard library apparently has not been reviewed for
        marking non-single-parameter constructors as "explicit".
&#160;
  </TD>
<TD valign="top">
        Consider marking zero-parameter and multi-parameter
        constructors "explicit" in classes that have at least one
        constructor marked "explicit" and that do not have an
        initializer-list constructor.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1153">1153</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP21">JP 21</A></TD>
<TD valign="top">17 Library 21.2, 21.4,
        27.2, 27.6,
27.7,
27.8.1,
28.4
&#160;
  </TD>
<TD valign="top">
        Support of char16_t/char32_t is insufficient. The basic_xxx
        classes of &lt;iostream&gt;, &lt;fstream&gt;,
        &lt;regex&gt;, etc. does not have typedefs for
        char16_t/char32_t.
        <BR><BR>
        Functions such as stoi, to_string in &#8216;21.4 Numeric
        Conversion&#8217; does not support char16_t/char32_t types.
&#160;
  </TD>
<TD valign="top">
        Add commented
        lines corresponding to char16_t, char32_t.
        <BR>
        
        <BR>
        21.2 paragraph1
        <BR>
        
        <BR>
        namespace std {
        <BR>
        ...
        <BR>
        
        <BR>
        // 21.4: numeric conversions
        <BR>
        ...
        <BR>
        
        <BR>
        int stoi(const u16string&amp; str, size_t *idx = 0,
        int base = 10);
        <BR>
        long stol(const u16string&amp; str, size_t *idx = 0,
        int base = 10);
        <BR>
        unsigned long stoul(const u16string&amp; str, size_t
        *idx = 0, int base = 10);
        <BR>
        long long stoll(const u16string&amp; str, size_t *idx
        = 0, int base = 10);
        <BR>
        unsigned long long stoull(const u16string&amp; str,
        size_t *idx = 0, int base = 10);
        <BR>
        float stof(const u16string&amp; str, size_t *idx =
        0);
        <BR>
        double stod(const u16string&amp; str, size_t *idx =
        0);
        <BR>
        long double stold(const u16string&amp; str, size_t
        *idx = 0);
        <BR>
        u16string to_u16string(long long val);
        <BR>
        u16string to_u16string(unsigned long long val);
        <BR>
        u16string to_u16string(long double val);
        <BR>
        
        <BR>
         int stoi(const u32string&amp; str, size_t *idx = 0,
        int base = 10);
        <BR>
        long stol(const u32string&amp; str, size_t *idx = 0,
        int base = 10);
        <BR>
        unsigned long stoul(const u32string&amp; str, size_t
        *idx = 0, int base = 10);
        <BR>
        long long stoll(const u32string&amp; str, size_t *idx
        = 0, int base = 10);
        <BR>
        unsigned long long stoull(const u32string&amp; str,
        size_t *idx = 0, int base = 10);
        <BR>
        float stof(const u32string&amp; str, size_t *idx =
        0);
        <BR>
        double stod(const u32string&amp; str, size_t *idx =
        0);
        <BR>
        long double stold(const u32string&amp; str, size_t
        *idx = 0);
        <BR>
        u32string to_u32string(long long val);
        <BR>
        u32string to_u32string(unsigned long long val);
        <BR>
        u32string to_u32string(long double val);
        <BR>}
        <BR>
        
        <BR>
        27.2
        <BR>
        
        <BR>
        namespace std {
        <BR>
        ...
        <BR>
        typedef basic_ios&lt;char&gt; ios;
        <BR>
        typedef basic_ios&lt;wchar_t&gt; wios;
        <BR>
        typedef basic_ios&lt;char16_t&gt; u16ios;
        <BR>
        typedef basic_ios&lt;char32_t&gt; u32ios;
        <BR>
        
        <BR>
        ...
        <BR>
        typedef basic_ifstream&lt;wchar_t&gt; wifstream;
        <BR>
        typedef basic_ofstream&lt;wchar_t&gt; wofstream;
        <BR>
        typedef basic_fstream&lt;wchar_t&gt; wfstream;
        <BR>
        
        <BR>
        typedef basic_streambuf&lt;char16_t&gt; u16streambuf;
        <BR>
        typedef basic_istream&lt;char16_t&gt; u16istream;
        <BR>
        typedef basic_ostream&lt;char16_t&gt; u16ostream;
        <BR>
        typedef basic_iostream&lt;char16_t&gt; u16iostream;
        <BR>
        
        <BR>
        typedef basic_stringbuf&lt;char16_t&gt; u16stringbuf;
        <BR>
        typedef basic_istringstream&lt;char16_t&gt;
        u16istringstream;
        <BR>
        typedef basic_ostringstream&lt;char16_t&gt;
        u16ostringstream;
        <BR>
        typedef basic_stringstream&lt;char16_t&gt;
        u16stringstream;
        <BR>
        typedef basic_filebuf&lt;char16_t&gt; u16filebuf;
        <BR>
        
        <BR>
        typedef basic_ifstream&lt;char16_t&gt; u16ifstream;
        <BR>
        typedef basic_ofstream&lt;char16_t&gt; u16ofstream;
        <BR>
        typedef basic_fstream&lt;char16_t&gt; u16fstream;
        <BR>
        
        <BR>
        typedef basic_streambuf&lt;char32_t&gt; u32streambuf;
        <BR>
        typedef basic_istream&lt;char32_t&gt; u32istream;
        <BR>
        typedef basic_ostream&lt;char32_t&gt; u32ostream;
        <BR>
        typedef basic_iostream&lt;char32_t&gt; u32iostream;
        <BR>
        
        <BR>
        typedef basic_stringbuf&lt;char32_t&gt; u32stringbuf;
        <BR>
        typedef basic_istringstream&lt;char32_t&gt;
        u32istringstream;
        <BR>
        typedef basic_ostringstream&lt;char32_t&gt;
        u32ostringstream;
        <BR>
        typedef basic_stringstream&lt;char32_t&gt;
        u32stringstream;
        <BR>
        typedef basic_filebuf&lt;char32_t&gt; u32filebuf;
        <BR>
        
        <BR>
        typedef basic_ifstream&lt;char32_t&gt; u32ifstream;
        <BR>
        typedef basic_ofstream&lt;char32_t&gt; u32ofstream;
        <BR>
        <u>typedef basic_fstream&lt;char32_t&gt;
        u32fstream;</u>
        <BR>
        
        <BR>
        ...
        <BR>
        template &lt;class state&gt; class fpos;
        <BR>
        typedef
        fpos&lt;char_traits&lt;char&gt;::state_type&gt; streampos;
        <BR>
        typedef
        fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;
        wstreampos;
        <BR>
        typedef
        fpos&lt;char_traits&lt;char16_t&gt;::state_type&gt;
        u16streampos;
        <BR>
        typedef
        fpos&lt;char_traits&lt;char32_t&gt;::state_type&gt;
        u32streampos;
        <BR>}
        <BR>
        
        <BR>
        27.6
        <BR>
        
        <BR>
        namespace std {
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt; &gt;
        <BR>
        class basic_istream;
        <BR>
        typedef basic_istream&lt;char&gt; istream;
        <BR>
        typedef basic_istream&lt;wchar_t&gt; wistream;
        <BR>
        <u>typedef basic_istream&lt;char16_t&gt;
        u16istream;</u>
        <BR>
        typedef basic_istream&lt;char32_t&gt; u32istream;
        <BR>
        
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt; &gt;
        <BR>
        class basic_iostream;
        <BR>
        typedef basic_iostream&lt;char&gt; iostream;
        <BR>
        typedef basic_iostream&lt;wchar_t&gt; wiostream;
        <BR>
        <u>typedef basic_iostream&lt;char16_t&gt;
        u16iostream;</u>
        <BR>
        typedef basic_iostream&lt;char32_t&gt; u32iostream;
        <BR>}
        <BR>
        
        <BR>
        namespace std {
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt; &gt;
        <BR>
        class basic_ostream;
        <BR>
        typedef basic_ostream&lt;char&gt; ostream;
        <BR>
        typedef basic_ostream&lt;wchar_t&gt; wostream;
        <BR>
        <u>typedef basic_ostream&lt;char16_t&gt;
        u16ostream;</u>
        <BR>
        typedef basic_ostream&lt;char32_t&gt; u32ostream;
        <BR>}
        <BR>
        
        <BR>
        27.7 paragraph 1
        <BR>
        
        <BR>
        namespace std {
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt;,
        <BR>
         class Allocator =
        allocator&lt;charT&gt; &gt;
        <BR>
        class basic_stringbuf;
        <BR>
        
        <BR>
        typedef basic_stringbuf&lt;char&gt; stringbuf;
        <BR>
        typedef basic_stringbuf&lt;wchar_t&gt; wstringbuf;
        <BR>
        <u>typedef basic_stringbuf&lt;char16_t&gt;
        u16stringbuf;</u>
        <BR>
        typedef basic_stringbuf&lt;char32_t&gt; u32stringbuf;
        <BR>
        
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt;,
        <BR>
         class Allocator =
        allocator&lt;charT&gt; &gt;
        <BR>
        class basic_istringstream;
        <BR>
        
        <BR>
        typedef basic_istringstream&lt;char&gt;
        istringstream;
        <BR>
        typedef basic_istringstream&lt;wchar_t&gt;
        wistringstream;
        <BR>
        <u>typedef basic_istringstream&lt;char16_t&gt;
        u16istringstream;</u>
        <BR>
        typedef basic_istringstream&lt;char32_t&gt;
        u32istringstream;
        <BR>
        
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt;,
        <BR>
         class Allocator =
        allocator&lt;charT&gt; &gt;
        <BR>
        class basic_ostringstream;
        <BR>
        
        <BR>
        typedef basic_ostringstream&lt;char&gt;
        ostringstream;
        <BR>
        typedef basic_ostringstream&lt;wchar_t&gt;
        wostringstream;
        <BR>
        <u>typedef basic_ostringstream&lt;char16_t&gt;
        u16ostringstream;</u>
        <BR>
        typedef basic_ostringstream&lt;char32_t&gt;
        u32ostringstream;
        <BR>
        
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt;,
        <BR>
         class Allocator =
        allocator&lt;charT&gt; &gt;
        <BR>
        class basic_stringstream;
        <BR>
        
        <BR>
        typedef basic_stringstream&lt;char&gt; stringstream;
        <BR>
        typedef basic_stringstream&lt;wchar_t&gt;
        wstringstream;
        <BR>
        typedef basic_stringstream&lt;char16_t&gt;
        u16stringstream;
        <BR>
        typedef basic_stringstream&lt;char32_t&gt;
        u32stringstream;
        <BR>}
        <BR>
        
        <BR>
        27.8.1 paragraph 1
        <BR>
        
        <BR>
        namespace std {
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt; &gt;
        <BR>
        class basic_filebuf;
        <BR>
        typedef basic_filebuf&lt;char&gt; filebuf;
        <BR>
        typedef basic_filebuf&lt;wchar_t&gt; wfilebuf;
        <BR>
        <u>typedef basic_filebuf&lt;char16_t&gt;
        u16filebuf;</u>
        <BR>
        typedef basic_filebuf&lt;char32_t&gt; u32filebuf;
        <BR>
        
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt; &gt;
        <BR>
        class basic_ifstream;
        <BR>
        typedef basic_ifstream&lt;char&gt; ifstream;
        <BR>
        typedef basic_ifstream&lt;wchar_t&gt; wifstream;
        <BR>
        <u>typedef basic_ifstream&lt;char16_t&gt;
        u16ifstream;</u>
        <BR>
        typedef basic_ifstream&lt;char32_t&gt; u32ifstream;
        <BR>
        
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt; &gt;
        <BR>
        class basic_ofstream;
        <BR>
        typedef basic_ofstream&lt;char&gt; ofstream;
        <BR>
        typedef basic_ofstream&lt;wchar_t&gt; wofstream;
        <BR>
        <u>typedef basic_ofstream&lt;char16_t&gt;
        u16ofstream;</u>
        <BR>
        typedef basic_ofstream&lt;char32_t&gt; u32ofstream;
        <BR>
        
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt; &gt;
        <BR>
        class basic_fstream;
        <BR>
        typedef basic_fstream&lt;char&gt; fstream;
        <BR>
        typedef basic_fstream&lt;wchar_t&gt; wfstream;
        <BR>
        <u>typedef basic_fstream&lt;char16_t&gt;
        u16fstream;</u>
        <BR>
        typedef basic_fstream&lt;char32_t&gt; u32fstream;
        <BR>}
        <BR>
        
        <BR>
        28.4
        <BR>
        
        <BR>
        namespace std {
        <BR>
        ...
        <BR>
        typedef basic_regex&lt;char&gt; regex;
        <BR>
        typedef basic_regex&lt;wchar_t&gt; wregex;
        <BR>
        typedef basic_regex&lt;char16_t&gt; u16regex;
        <BR>
        typedef basic_regex&lt;char32_t&gt; u32regex;
        <BR>
        
        <BR>
        ...
        <BR>
        typedef sub_match&lt;const char*&gt; csub_match;
        <BR>
        typedef sub_match&lt;const wchar_t*&gt; wcsub_match;
        <BR>
        typedef sub_match&lt;const char16_t*&gt;
        u16csub_match;
        <BR>
        typedef sub_match&lt;const char32_t*&gt;
        u16csub_match;
        <BR>
        typedef sub_match&lt;string::const_iterator&gt;
        ssub_match;
        <BR>
        typedef sub_match&lt;wstring::const_iterator&gt;
        wssub_match;
        <BR>
        typedef sub_match&lt;u16string::const_iterator&gt;
        u16ssub_match;
        <BR>
        typedef sub_match&lt;u32string::const_iterator&gt;
        u32ssub_match;
        <BR>
        
        <BR>
        ...
        <BR>
        typedef match_results&lt;const char*&gt; cmatch;
        <BR>
        typedef match_results&lt;const wchar_t*&gt; wcmatch;
        <BR>
        typedef match_results&lt;const char16_t*&gt;
        u16cmatch;
        <BR>
        typedef match_results&lt;const char32_t*&gt;
        u32cmatch;
        <BR>
        typedef match_results&lt;string::const_iterator&gt;
        smatch;
        <BR>
        typedef match_results&lt;wstring::const_iterator&gt;
        wsmatch;
        <BR>
        typedef
        match_results&lt;u16string::const_iterator&gt; u16smatch;
        <BR>
        typedef
        match_results&lt;u32string::const_iterator&gt; u32smatch;
        <BR>
        
        <BR>
        ...
        <BR>
        typedef regex_iterator&lt;const char*&gt;
        cregex_iterator;
        <BR>
        typedef regex_iterator&lt;const wchar_t*&gt;
        wcregex_iterator;
        <BR>
        typedef regex_iterator&lt;const cha16r_t*&gt;
        u16cregex_iterator;
        <BR>
        typedef regex_iterator&lt;const char32_t*&gt;
        u32cregex_iterator;
        <BR>
        typedef regex_iterator&lt;string::const_iterator&gt;
        sregex_iterator;
        <BR>
        typedef regex_iterator&lt;wstring::const_iterator&gt;
        wsregex_iterator;
        <BR>
        typedef
        regex_iterator&lt;u16string::const_iterator&gt;
        u16sregex_iterator;
        <BR>
        typedef
        regex_iterator&lt;u32string::const_iterator&gt;
        u32sregex_iterator;
        <BR>
        
        <BR>
        ...
        <BR>
        typedef regex_token_iterator&lt;const char*&gt;
        cregex_token_iterator;
        <BR>
        typedef regex_token_iterator&lt;const wchar_t*&gt;
        wcregex_token_iterator;
        <BR>
        typedef regex_token_iterator&lt;const char16_t*&gt;
        u16cregex_token_iterator;
        <BR>
        typedef regex_token_iterator&lt;const char32_t*&gt;
        u32cregex_token_iterator;
        <BR>
        typedef
        regex_token_iterator&lt;string::const_iterator&gt;
        sregex_token_iterator;
        <BR>
        typedef
        regex_token_iterator&lt;wstring::const_iterator&gt;<span lang="zxx">
        &#12288;&#12288;&#12288;</span>wsregex_token_iterator;
        <BR>
        typedef
        regex_token_iterator&lt;u16string::const_iterator&gt;
        u16sregex_token_iterator;
        <BR>
        typedef
        regex_token_iterator&lt;u32string::const_iterator&gt;<span lang="zxx">
        &#12288;</span>u32sregex_token_iterator;
        <BR>}
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Previously considered; we decided not to do it. We believe it is
not too onerous to use <TT>wbuffer_convert</TT> and
<TT>wstring_convert</TT> which were added as intermediaries to
avoid proliferation of types.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK144">UK 144</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/72">
     [72]
    </A></TD>
<TD valign="top">
17.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        List of contents of library should be
        extened to cover new clauses
&#160;
  </TD>
<TD valign="top">
        Add "regular expressions, atomic operations
        and threads"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK145">UK 145</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/73">
     [73]
    </A></TD>
<TD valign="top">
17.1

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        <span lang="en-US">Summary of numeric facilities should
        mention random numbers</span>
&#160;
  </TD>
<TD valign="top">
        Add random number framework to the list of
        library facilities
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK146">UK 146</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/74">
     [74]
    </A></TD>
<TD valign="top">
17.1
&#160;
  </TD>
<TD valign="top">
        Add a summary paragraph for regular
        expressions
&#160;
  </TD>
<TD valign="top">
        Add a summary paragraph for regular
        expressions
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK147">UK 147</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/75">
     [75]
    </A></TD>
<TD valign="top">
17.1
&#160;
  </TD>
<TD valign="top">
        Add a summary paragraph for threads
&#160;
  </TD>
<TD valign="top">
        Add a summary paragraph for threads
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK148">UK 148</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/247">
     [247]
    </A></TD>
<TD valign="top">
17.2

    &#182;
    
Table 12
&#160;
  </TD>
<TD valign="top">
        Table 12 is
        mentioned in and relates to section 17.2, but has been
        pushed down to appear directly after the title of section
        17.3 which is rather unfortunate/confusing for the reader.
&#160;
  </TD>
<TD valign="top">
        Make sure tables are rendered in the
        section to which they relate.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK149">UK 149</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/84">
     [84]
    </A></TD>
<TD valign="top">
17.3
&#160;
  </TD>
<TD valign="top">
        For consistency
        with narrow-oriented and wide-oriented streams, we should
        add terms for streams of Unicode character sequences
&#160;
  </TD>
<TD valign="top">
        Define Utf16-oriented stream classes and
        Uft32-oriented stream classes for streams of
        char16_t/char32_t values.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The terms "narrow-oriented iostream classes" and "wide-oriented
iostream classes" are never used in the standard (except in a somewhat
garbled passage that I have rewritten without them), so rather than
proliferate definitions of unused terms, I've removed the original
culprits.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK150">UK 150</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/199">
     [199]
    </A></TD>
<TD valign="top">
17.3
&#160;
  </TD>
<TD valign="top">
        The addition of move semantics to the
        language means that many library APIs leave an object in a
        safely-destructible state, where no other operations can
        safely be performed unless it is assigned a new value.
        Library presentation would be simplified and made more
        precise if we introduce a term for this state. By analogy
        with singular iterators suggest the term 'singular object'
        or 'the object is in a singular state'.
&#160;
  </TD>
<TD valign="top">
        Define 'singular
        state' such that an object with a singular state can only
        be assigned to or safely destroyed. Assiging a new value
        typically removes the singular state. Note that objects
        with a singular state may not be safely copied, so you
        cannot put an object into a singular state by copying
        another object in a singular state. Use this new term in
        the postcondition of all library APIs that move from an
        rvalue reference. It might also be used to simplify the
        definition of singular iterator to an iterator value with a
        singular state.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK151">UK 151</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/77">
     [77]
    </A></TD>
<TD valign="top">
17.3.1
&#160;
  </TD>
<TD valign="top">
        Missing
        crossreference to 17.3.17 [defns.repositional.stream]
&#160;
  </TD>
<TD valign="top">
        Add cross-reference in the existing empty
        brackets
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Removed the reference.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK152">UK 152</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/80">
     [80]
    </A></TD>
<TD valign="top">
17.3.12
&#160;
  </TD>
<TD valign="top">
        Object state is
        using a definition of object (instance of a class) from
        outside the standard, rather than the 'region of storage'
        definiton in 1.8p1
&#160;
  </TD>
<TD valign="top">
        Clarify terms and usage
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1064">1064</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>This will not affect user or implementer code.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK153">UK 153</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/82">
     [82]
    </A></TD>
<TD valign="top">
17.3.17
&#160;
  </TD>
<TD valign="top">
        If a
        repositional stream can only seek to a position previously
        encountered, then an arbitrary-positional-stream cannot
        satisfy this definition, as cross-referenced in 17.3.17
&#160;
  </TD>
<TD valign="top">
        Strike the word 'only'. A note might be
        added to reinforce the intent
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK154">UK 154</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/83">
     [83]
    </A></TD>
<TD valign="top">
17.3.20
&#160;
  </TD>
<TD valign="top">
        Missing definition of a stable partition
        algorithm
&#160;
  </TD>
<TD valign="top">
        Add definition from 25.2.12p7
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Since the term "stable partition algorithm" is never used, there is no
need to define it. The requirements for the algorithm stable_partition
are clear as written.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK155">UK 155</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/78">
     [78]
    </A></TD>
<TD valign="top">
17.3.3
&#160;
  </TD>
<TD valign="top">
        Add clause 28 to list that use this
        definition of character
&#160;
  </TD>
<TD valign="top">
        Add clause 28 to list that use this
        definition of character
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK156">UK 156</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/79">
     [79]
    </A></TD>
<TD valign="top">
17.3.4
&#160;
  </TD>
<TD valign="top">
        Add regular
        expressions to set of templates using character container
        type
&#160;
  </TD>
<TD valign="top">
        Add regular expressions to set of templates
        using character container type
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK157">UK 157</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/86">
     [86]
    </A></TD>
<TD valign="top">
17.5.2.2

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Add concepts to
        the ordered list of presentation
&#160;
  </TD>
<TD valign="top">
        Add concepts into the sequence
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top"><BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK158">UK 158</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/87">
     [87]
    </A></TD>
<TD valign="top">
17.5.2.2

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        templates are neither classes nor functions
&#160;
  </TD>
<TD valign="top">
        Replace
        'classes' and 'functions' with 'classes and class
        templates' and 'functions and function templates'
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK159">UK 159</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/88">
     [88]
    </A></TD>
<TD valign="top">
17.5.2.4

    &#182;
    
Footnote 152
&#160;
  </TD>
<TD valign="top">
        This informative
        footnote was relevant in 1998, not 2008. The term 'existing
        vendors' may imply something different now
&#160;
  </TD>
<TD valign="top">
        Strike the footnote, or replace 'existing'
        with 'original' or similar
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK160">UK 160</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/89">
     [89]
    </A></TD>
<TD valign="top">
17.5.2.4

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        requires is now
        a keyword with a specific meaning related to concepts, and
        its use in library specifcation may be confusing. Generally
        the Requires clause is used to make requirements on the
        caller, not the library, so typically providing runtime
        pre-conditions. Suggest a new name to refflect that. Note
        that Clause 30 already seems to be written to this
        convention.
&#160;
  </TD>
<TD valign="top">
        Replace 'Requires' with 'Preconditions'
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK161">UK 161</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/90">
     [90]
    </A></TD>
<TD valign="top">
17.5.2.4

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        This paragraph
        is redundant as the definition of the term 'handler
        function' is already provided in 17.3. Are we in danger of
        proving two definitions of the same terms? Which is the
        'controlling' definition?
&#160;
  </TD>
<TD valign="top">
        Strike 17.5.2.4p4
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
17.3 defines "handler function"; 17.5.2.4/4 imposes requirements on
handler functions and replacement functions. There is no redundancy.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK162">UK 162</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/170">
     [170]
    </A></TD>
<TD valign="top">
17.5.2.4

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Clause 30 makes
        use of a 'Synchronization' semantic element, that
        frequently appears either between Effects: and
        Postconditions:, or between Returns: and Throws:
&#160;
  </TD>
<TD valign="top">
        Add 'Synchronization' to the list either
        between Effects: and Postconditions:, or between Returns:
        and Throws:.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK163">UK 163</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/219">
     [219]
    </A></TD>
<TD valign="top">
17.5.2.4

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Many functions
        are defined as "Effects: Equivalent to a...", which seems
        to also define the preconditions, effects, etc. But this is
        not made clear.
&#160;
  </TD>
<TD valign="top">
        Introduce an explicit "Equivalent to",
        which defines all of the properties of the function.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#997">997</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK164">UK 164</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/91">
     [91]
    </A></TD>
<TD valign="top">
17.5.3.2.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        This phrasing predates concepts. While this
        kind of description is still used, the examples provided
        are now all concepts, and should be replaced with
        appropriate examples
&#160;
  </TD>
<TD valign="top">
        Use better names
        for the examples. Ideally totally replace the need by
        constraining all templates in library, so that real
        concepts are all that is needed. Note if retained that
        CopyConstructible is mis-spelled.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK165">UK 165</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/92">
     [92]
    </A></TD>
<TD valign="top">
17.5.3.2.2,
17.5.3.2.3
&#160;
  </TD>
<TD valign="top">
        constraints on
        bitmask and enumation types were supposed to be tightened
        up as part of the motivation for the constexpr feature -
        see paper n2235 for deails
&#160;
  </TD>
<TD valign="top">
        Adopt wording in line with the motivation
        described in N2235
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1156">1156</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK166">UK 166</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/93">
     [93]
    </A></TD>
<TD valign="top">
17.5.3.2.4.1,
17.5.3.3
&#160;
  </TD>
<TD valign="top">
        List of library clauses should go up to 30,
        not 27
&#160;
  </TD>
<TD valign="top">
        Replace initial refernce to ch27 with ch30
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK167">UK 167</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/246">
     [246]
    </A></TD>
<TD valign="top">
17.5.3.4
Private
members
&#160;
  </TD>
<TD valign="top">
        Comment marker in wrong place.
&#160;
  </TD>
<TD valign="top">
        Change: //
        streambuf* sb; exposition only to streambuf* sb; //
        exposition only To reflect actual usage.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK168">UK 168</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/406">
     [406]
    </A></TD>
<TD valign="top">
17.6.2.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        We should make
        it clear (either by note or normatively) that namespace std
        may contain inline namespaces, and that entities specified
        to be defined in std may in fact be defined in one of these
        inline namespaces. (If we're going to use them for
        versioning, eg when TR2 comes along, we're going to need
        that.)
&#160;
  </TD>
<TD valign="top">
        Replace "namespace std or namespaces nested
        within namespace std" with "namespace std or namespaces
        nested within namespace std or inline namespaces nested
        directly or indirectly within namespace std"
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1065">1065</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK169">UK 169</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/95">
     [95]
    </A></TD>
<TD valign="top">
17.6.2.2
&#160;
  </TD>
<TD valign="top">
        This phrasing
        contradicts later freedom to implement the C standard
        library portions in the global namespace as well as std.
        (17.6.2.3p4)
&#160;
  </TD>
<TD valign="top">
        Resolve conflict in either place
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#992">992</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK170">UK 170</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/96">
     [96]
    </A></TD>
<TD valign="top">
17.6.2.3
&#160;
  </TD>
<TD valign="top">
        One of goals of
        C++0x is to make language easier to teach and for
        'incidental' programmers. The fine-grained headers of the
        C++ library are valuable in large scale systems for
        managing dependencies and optimising build times, but
        overcomplicated for simple development and tutorials. Add
        additional headers to support the whole library through a
        single include statement.
&#160;
  </TD>
<TD valign="top">
        Add a new header &lt;std&gt; that has the
        effect of including everything in tables 13 and 14, except
        &lt;iosfwd&gt; and &lt;cassert&gt;. Add an additional
        header &lt;fwd&gt; that adds all declarations from
        &lt;std&gt; but no definitions.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1002">1002</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus for change. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK171">UK 171</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/98">
     [98]
    </A></TD>
<TD valign="top">
17.6.2.4

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Does
        freestanding implementation require a full implementation
        of all listed headers? The reference to abort, at_exit and
        exit is confusing. Is a conforming implementation allow to
        deliver partial forms of these headers? If so which ones?
        Are empty versions of everything but &lt;cstdlib&gt;
        conforming?
&#160;
  </TD>
<TD valign="top">
        Either strike the references to abort,
        at_exit and exit, or clarify which headers only require
        partial support.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK172">UK 172</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/99">
     [99]
    </A></TD>
<TD valign="top">
17.6.2.4

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        No reference to
        new functions quick_exit and at_quick_exit
&#160;
  </TD>
<TD valign="top">
        Add reference to quick_exit and
        at_quick_exit
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1264">1264</A>&#160;
  </TD>
<TD valign="top">We do not belive at_exit and at_quick_exit should be required by 
    freestanding implementations.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK173">UK 173</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/450">
     [450]
    </A></TD>
<TD valign="top">
17.6.2.4

    &#182;
    
table 15
&#160;
  </TD>
<TD valign="top">
        &lt;initializer_list&gt; is missing from headers required
        in freestanding implementations.
&#160;
  </TD>
<TD valign="top">
        Add 18.8, initializer lists,
        &lt;initializer_list&gt;, to the end of the table.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP23">JP 23</A></TD>
<TD valign="top">
17.6.2.4

    &#182;
    
2<sup>nd</sup> <font size="2" style="font-size: 11pt">para, Table 15</font>
&#160;
  </TD>
<TD valign="top">
        There is a
        freestanding implementation including &lt;type_traits&gt;,
        &lt;array&gt;, &lt;ratio&gt;, lately added to Table 13, C++
        library headers.
        Programmers think them useful and hope that these headers
        are also added to Table 15, C++ headers for freestanding
        implementations, that shows the set of headers which a
        freestanding implementation shall include at least.
&#160;
  </TD>
<TD valign="top">
        Add
        &lt;type_traits&gt;, &lt;array&gt;, &lt;ration&gt; to Table
        15.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1003">1003</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>See Martin Tasker's paper Fixing Freestanding which provides the
wording to include &lt;type_traits&gt; into freestanding implementations. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK174">UK 174</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/100">
     [100]
    </A></TD>
<TD valign="top">
17.6.3.2

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        The phrasing is
        mildly ambiguous when using the word 'it' to refer back to
        the header - an unfotunate reading might confuse it with
        the translate unit, which is the subject of the surrounding
        clause.
&#160;
  </TD>
<TD valign="top">
        Replace 'the first reference to any of the
        entities declared in that header by the translation unit'
        with 'the first reference to any of the entities that
        header declares in the translation unit'
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK175">UK 175</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/101">
     [101]
    </A></TD>
<TD valign="top">
17.6.4.2.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        Local types can
        now be used to instantiate templates, but don't have
        external linkage
&#160;
  </TD>
<TD valign="top">
        Remove the reference to external linkage
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1157">1157</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK176">UK 176</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/102">
     [102]
    </A></TD>
<TD valign="top">
17.6.4.3.3

    &#182;
    
Footnote 175
&#160;
  </TD>
<TD valign="top">
        Reference to namespace ::std should be
        17.6.4.2
&#160;
  </TD>
<TD valign="top">
        Change referfence from 17.6.4.3 to 17.6.4.2
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Removed footnote.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK177">UK 177</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/103">
     [103]
    </A></TD>
<TD valign="top">
17.6.4.3.4

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Sentence is
        redundant as double underscores are reserved in all
        contexts by 17.6.4.3.3
&#160;
  </TD>
<TD valign="top">
        Strike the sentence
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK178">UK 178</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/104">
     [104]
    </A></TD>
<TD valign="top">
17.6.4.8

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The last sentence of the third bullet
        "Operations on such types can report a failure by throwing
        an exception unless otherwise specified" is redundant as
        behaviour is already undefined.
&#160;
  </TD>
<TD valign="top">
        Strike the sentence
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The sentence is not redundant. It points out that the behavior is
sometimes circumscribed by a prohibition on throwing exceptions.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK179">UK 179</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/105">
     [105]
    </A></TD>
<TD valign="top">
17.6.4.8

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        According to the
        4th bullet there is a problem if "if any replacement
        function or handler function or destructor operation throws
        an exception". There should be no problem throwing
        exceptions so long as they are caught within the function.
&#160;
  </TD>
<TD valign="top">
        Replace the word 'throws' with 'propogates'
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1004">1004</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>Replace "propagates" in the proposed resolution with the phrase "exits via".
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP22">JP 22</A></TD>
<TD valign="top">
17.6.5.7

    &#182;
    
4<sup>th</sup> <font size="2" style="font-size: 11pt">para, 1<sup>st</sup>
        line</font>
&#160;
  </TD>
<TD valign="top">
        The
        statement below describes relation among two or more
        threads using words &#8220;between threads&#8221;:
        [Note: This means, for example, that implementations
        can&#8217;t use a static object for internal purposes
        without synchronization because it could cause a data race
        even in programs that do not explicitly share objects
        between threads. &#8212;end note ]
        <BR><BR>In
        such case, &#8220;among&#8221; is preferred instead of
        &#8220;between&#8221;.
&#160;
  </TD>
<TD valign="top">
        Change "between threads" to "among threads".
        <BR><BR>
        There are same cases in 17.6.1 paragraph 2, 17.6.5.7
        paragraph 6, 30.1 paragraph 1, 30.3.1 paragraph 1 also.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
"Between" expresses one-to-one relations of pairs in a group; "among"
refers to collective relations in a group. "Between" is correct here.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK180">UK 180</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/107">
     [107]
    </A></TD>
<TD valign="top">
17.6.5.10

    &#182;
    
1, 4
&#160;
  </TD>
<TD valign="top">
        It should not be
        possible to strengthen the exception specification for
        virtual functions as this could break user code. Note this
        is not a problem in practice as there are no virtual
        functions with exception specifications in the current
        library, other than empty throw specifications which it is
        not possible to strengthen.
&#160;
  </TD>
<TD valign="top">
        Add restriction that exception
        specification of virtual functions cannot be tightened.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>The standard already has the desired restriction.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK181">UK 181</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/108">
     [108]
    </A></TD>
<TD valign="top">
17.6.5.10

    &#182;
    
Footnote 186
&#160;
  </TD>
<TD valign="top">
        This footnote is
        wrong. C library functions do not have any exception
        specification, but might be treated as if they had an empty
        throw specification
&#160;
  </TD>
<TD valign="top">
        Clarify that this note does not mean the
        functions are genuinely declared with the specification,
        but are treated as-if.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK182">UK 182</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/109">
     [109]
    </A></TD>
<TD valign="top">
17.6.5.10

    &#182;
    
Footnote 188
&#160;
  </TD>
<TD valign="top">
        It is very
        helpful to assume all exceptions thrown by the standard
        library derive from std::exception. The 'encouragement' of
        this note should be made normative.
&#160;
  </TD>
<TD valign="top">
        Make this footnote normative
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>The standard library cannot mandate all standard-library functions that might use some 
    third-party library.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK184">UK 184</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/144">
     [144]
    </A></TD>
<TD valign="top">
18 -&gt; 30
&#160;
  </TD>
<TD valign="top">
        The new
        alias-declaration syntax is generally easier to read than a
        typedef declaration. This is especially true for complex
        types like function pointers.
&#160;
  </TD>
<TD valign="top">
        Replace all typedef declarations in the
        standard library with alias-declarations, except in the
        standard C library.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP24">JP 24</A></TD>
<TD valign="top">
18

    &#182;
    
2<sup>nd</sup> <font size="2" style="font-size: 11pt">para, Table 16</font>
&#160;
  </TD>
<TD valign="top">
        Subclauses are listed in Table 16 as:
        <BR><BR>"18.6 Type
        identification &#8230;"
        <BR><BR>"18.8 Initializer
        lists &#8230;"
        <BR><BR>"18.7 Exception
        handling &#8230;".
&#160;
  </TD>
<TD valign="top">
        Sort them in the increasing order
        "18.6 Type identification &#8230;"
        <BR><BR>"18.7 Exception
        handling &#8230;".
        <BR><BR>
        "18.8 Initializer lists &#8230;"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP25">JP 25</A></TD>
<TD valign="top">
18.1

    &#182;
    
        6<sup>th</sup> <font size="2" style="font-size: 11pt">para , last line, SEE ALSO</font>
&#160;
  </TD>
<TD valign="top">
        max_align_t is described in 18.1, so add 3.11 Alignment as
        the reference.
&#160;
  </TD>
<TD valign="top">
        Add
        "<u>3.11, Alignment</u><font color="#000000">" to</font>
        <font size="2" style="font-size: 11pt">SEE ALSO.</font>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR32">FR 32</A></TD>
<TD valign="top">
18.2.1
[Numeric
limits]
&#160;
  </TD>
<TD valign="top">
        The definition of
        numeric_limits&lt;&gt; as requiring a regular type is both
        conceptually wrong and operationally illogical. As we
        pointed before, this mistake needs to be corrected. For
        example, the template can be left unconstrained. In fact
        this reflects a much more general problem with
        concept_maps/axioms and their interpretations. It appears
        that the current text heavily leans toward experimental
        academic type theory.
&#160;
  </TD>
<TD valign="top">
        We suggest that a more pragmatic approach, in the spirit
        of C and C++, be taken so that calls to constrained
        function templates are interpreted as assertions on
        *values*, not necessarily semantics assertions on the
        carrier type.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#902">902</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE16">DE 16</A></TD>
<TD valign="top">
18.2.1
&#160;
  </TD>
<TD valign="top">
        DE-16 The class
        template numeric_limits should not specify the Regular
        concept requirement for its template parameter, because it
        contains functions returning NaN values for floating-point
        types; these values violate the semantics of
        EqualityComparable. See also library issue 902 in WG21
        document N2794 "C++ Standard Library Active Issues List
        (Revision R60)", available at
        http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2794.html
        .
&#160;
  </TD>
<TD valign="top">
        Specify a concept requirement with fewer constraints as
        appropriate, for example SemiRegular.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#902">902</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP26">JP 26</A></TD>
<TD valign="top">
18.2.1.1
&#160;
  </TD>
<TD valign="top">
        numeric_limits does not use concept.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR>
        
        <BR>
        template&lt;class T&gt; class numeric_limits&lt;const
        T&gt;;
        <BR>
        template&lt;class T&gt; class numeric_limits&lt;volatile
        T&gt;;
        <BR>
        template&lt;class T&gt; class numeric_limits&lt;const
        volatile T&gt;;
        <BR>
        
        <BR>
        should be
        <BR>
        
        <BR>
        template&lt;<u>Regular</u> T&gt; class
        numeric_limits&lt;const T&gt;;
        <BR>
        template&lt;<u>Regular</u> T&gt; class
        numeric_limits&lt;volatile T&gt;;
        <BR>
        template&lt;<u>Regular</u> T&gt; class
        numeric_limits&lt;const volatile T&gt;;
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1005">1005</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE17">DE 17</A></TD>
<TD valign="top">
18.2.6
&#160;
  </TD>
<TD valign="top">
        DE-17 The class
        type_index should be removed; it provides no additional
        functionality beyond providing appropriate concept maps.
&#160;
  </TD>
<TD valign="top">
        Specify concept maps for "const type_info *" as required
        by the ordered and unordered containers and remove the
        class type_index.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1078">1078</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK185">UK 185</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/264">
     [264]
    </A></TD>
<TD valign="top">
18.3.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        There is no
        header &lt;stdint&gt;, it should either be &lt;stdint.h&gt;
        or &lt;cstdint&gt;
&#160;
  </TD>
<TD valign="top">
        Replace &lt;stdint&gt; with &lt;cstdint&gt;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE18">DE 18</A></TD>
<TD valign="top">
18.4
&#160;
  </TD>
<TD valign="top">
        DE-18 The
        proposed C++ standard makes a considerable number of
        existing programs that have well-defined behavior according
        to ISO/IEC 14882:2003 have undefined behavior without a
        diagnostic hint to the programmer at all. This applies to
        the presence of threads and to pointer safety (the latter
        was introduced to support garbage collection). In order to
        avoid requiring a full code review for user code,
        facilities should be present that allow the compile-time
        detection of the advanced features of the proposed C++
        standard. It is expected that C++ implementations will
        provide a means (for example, a command-line switch) to
        turn off either or both of threads and garbage collection
        support, turning potentially undefined programs into
        well-defined ones.
        <i>Note:</i> This issue is contributing significantly to
        Germany's overall &#8220;no&#8221; vote.
&#160;
  </TD>
<TD valign="top">
        Consider applying the changes proposed in WG21 document
        N2693 "Requirements on programs and backwards
        compatibility", available at
        http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html
        .
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1097,1098 ">1097,1098 </A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK186">UK 186</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/265">
     [265]
    </A></TD>
<TD valign="top">
18.4

    &#182;
    
Footnote 221
&#160;
  </TD>
<TD valign="top">
        What is the
        purpose of this comment? The standard stream objects (cin,
        cerr etc.) have a peculiar lifetime that extends beyond the
        program. They may never be destroyed so will not be
        responsible for flushing buffers at the stated time.
&#160;
  </TD>
<TD valign="top">
        Remove the footnote
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK187">UK 187</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/266">
     [266]
    </A></TD>
<TD valign="top">
18.4

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
        The term "thread
        safe" is not defined nor used in this context anywhere else
        in the standard.
&#160;
  </TD>
<TD valign="top">
        Clarify the intended meaing of "thread
        safe"
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1144">1144</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK188">UK 188</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/267">
     [267]
    </A></TD>
<TD valign="top">
18.4

    &#182;
    
12
&#160;
  </TD>
<TD valign="top">
        The function
        _Exit does not appear to be defined in this standard.
        Should it be added to the table of functions
        included-by-reference to the C standard?
&#160;
  </TD>
<TD valign="top">
        Depends on where _Exit comes from
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#993">993</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK189">UK 189</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/273">
     [273]
    </A></TD>
<TD valign="top">
18.4, 18.7
&#160;
  </TD>
<TD valign="top">
        The addition of the [[noreturn]] attribute
        to the language will be an important aid for static
        analysis tools.
&#160;
  </TD>
<TD valign="top">
        The following
        functions should be declared in C++ with the [[noreturn]]
        attribute: abort exit quick_exit terminate unexpected
        rethrow_exception throw_with_nested
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1066">1066</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP27">JP 27</A></TD>
<TD valign="top">
18.4, 18.9,
18.7.2.2,
18.7.3.1
&#160;
  </TD>
<TD valign="top">
        There are Standard library functions that never return to
        the caller. They are explained so in the Standard but not
        declared explicitly.
&#160;
  </TD>
<TD valign="top">
        Consider to add the attribute [[noreturn]] to such
        functions,
        <BR><BR>
        
        <BR><BR>
        15.5.2 unexpected
        18.4: abort(), exit(), quick_exit,
        18.7.2.2: unexpected_handler,
        18.7.3.1: terminate_handler,
        <BR><BR>
        18.7.6 rethrow_nested
        <BR><BR>18.7.6
        throw_with_nested
        18.9: longjmp.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1066">1066</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK190">UK 190</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/268">
     [268]
    </A></TD>
<TD valign="top">
18.5.1

    &#182;
    
various
&#160;
  </TD>
<TD valign="top">
        It is not entirely clear how the current
        specification acts in the presence of a garbage collected
        implementation.
&#160;
  </TD>
<TD valign="top">
        All deallocation
        functions taking a pointer parameter should have a
        Precondition : ptr is a safely-derived pointer value.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1006">1006</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK191">UK 191</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/271">
     [271]
    </A></TD>
<TD valign="top">
18.5.1.1

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        According to the second bullet, behaviour
        becomes undefined (for lack of a specification) if the user
        has not yet called set_new_handler.
&#160;
  </TD>
<TD valign="top">
        Rephrase the
        second bullet in terms of a new handler being installed,
        and update any definition of handler function necessary to
        be sure the term 'installed' is defined.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Reworded, but not with "installed".
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK192">UK 192</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/269">
     [269]
    </A></TD>
<TD valign="top">
18.5.1.2
&#160;
  </TD>
<TD valign="top">
        The declared
        signature is not compatible with the current requirement to
        throw std::length_error. It is too late to weaken the
        exception specification, so the only other change is to
        preserve new (improved) behaviour is to throw
        std::bad_alloc, or something derived from std::bad_alloc.
&#160;
  </TD>
<TD valign="top">
        Fix 5.3.4p7 by required std::bad_alloc
        rather than std::length_error
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#805">805</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/N2932.pdf">
     N2932</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK193">UK 193</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/272">
     [272]
    </A></TD>
<TD valign="top">
18.5.2.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        quick_exit has
        been added as a new valid way to terminate a program in a
        well defined way
&#160;
  </TD>
<TD valign="top">
        Change 3rd bullet: call either abort(),
        exit() or quick_exit();
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#994">994</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK194">UK 194</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/443">
     [443]
    </A></TD>
<TD valign="top">
18.6
&#160;
  </TD>
<TD valign="top">
        The inclusion of
        type_index and hash&lt;type_index&gt; in &lt;typeinfo&gt;
        brings dependencies into &lt;typeinfo&gt; which are
        inconsistent with the definition of freestanding C++ in
        17.6.2.4.
&#160;
  </TD>
<TD valign="top">
        Move type_index and hash&lt;type_index&gt;
        out of &lt;typeinfo&gt; and into a new header,
        &lt;typeindex&gt;.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP28">JP 28</A></TD>
<TD valign="top">
18.6,
18.7,
19.1
&#160;
  </TD>
<TD valign="top">
        Errors reported by Exception classes are of types char or
        std::string only. For example, std::exception is declared
        with char, std::string types, therefore types
        wchar_t/wstring, char16_t/u16string, or char32_t/u32string
        can not be used.
&#160;
  </TD>
<TD valign="top">
        Consider other types.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>There is already guidance in the CD. It is the caller's responsibility 
    to internationalize MB character string.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP29">JP 29</A></TD>
<TD valign="top">
18.7.6
&#160;
  </TD>
<TD valign="top">
        throw_with_nested does not use concept.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR><BR>
        template&lt;class T&gt; void throw_with_nested(T&amp;&amp;
        t); // [[noreturn]]
        <BR><BR>
        
        <BR><BR>should be
        <BR><BR>
        
        <BR><BR>
        template&lt;CopyConstructible T&gt; void
        throw_with_nested(T&amp;&amp; t); // [[noreturn]]
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1007">1007</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP30">JP 30</A></TD>
<TD valign="top">
18.7.6
&#160;
  </TD>
<TD valign="top">
        To
        handle nested exceptions strictly, error information of
        tree structure will be required though, the
        nested_exception does not support tree structure. It is
        insufficient as error handling.
&#160;
  </TD>
<TD valign="top">
        Consider nested_exception to support tree structure.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1132">1132</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>The committee agrees that nested_exception is not a good match for this usage model. The committee did not see a way of improving this within the timeframe allowed.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP31">JP 31</A></TD>
<TD valign="top">
18.7.6
&#160;
  </TD>
<TD valign="top">
        It
        is difficult to understand in which case nested_exception
        is applied.
&#160;
  </TD>
<TD valign="top">
        Consider to add
        a sample program which rethrows exception.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1008">1008</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK195">UK 195</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/451">
     [451]
    </A></TD>
<TD valign="top">
18.8
&#160;
  </TD>
<TD valign="top">
        The class
        definition of std::initializer_list contains concept-maps
        to Range which should be out of the class, and in
        &lt;iterator_concepts&gt; instead. Otherwise, it's not
        possible to use initializer_lists in a freestanding C++
        implementation.
&#160;
  </TD>
<TD valign="top">
        Delete the two concept maps from
        std::initializer_list.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK196">UK 196</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/452">
     [452]
    </A></TD>
<TD valign="top">
18.8.3
&#160;
  </TD>
<TD valign="top">
        Concept maps for initializer_list to Range
        should not be in language support headers, but instead in
        iterator concepts.
&#160;
  </TD>
<TD valign="top">
        Remove section
        18.8.3 and put it in 24.1.8.1 instead, so that the
        concept_maps from initializer_list to Range are specified
        under Range instead of under initializer lists; also, so
        that they're implemented in &lt;iterator_concepts&gt;
        instead of &lt;initializer_list&gt;.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK197">UK 197</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/275">
     [275]
    </A></TD>
<TD valign="top">
19
&#160;
  </TD>
<TD valign="top">
        All the exception classes in this clause
        take a std::string argument by const reference. They should
        all be overloaded to accept std::string by rvalue rerefence
        for an efficient move as well.
&#160;
  </TD>
<TD valign="top">
        Provide a
        constructor for every exception class in clause 19
        accepting a std::string by rvalue reference, with the
        semantics that the passed string may be moved.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Implementations are permitted to add the requested signature under the 
    as-if rule. See clause 17.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP32">JP 32</A></TD>
<TD valign="top">
19.1
&#160;
  </TD>
<TD valign="top">
        Messages returned by the member function what() of standard
        exception classes seem difficult to judge.
        <BR><BR>For
        example, following messages are returned by what() of
        std::bad_alloc of existing implementations:
        <BR><BR>
        
        <BR><BR>
        Compiler: Message returned by what()
        <BR><BR>
        ---------------------------------------------
        <BR><BR>
        Borland C++ 5.6.4: no named exception thrown
        <BR><BR>
        Visual C++ 8.0: bad allocation
        <BR><BR>
        Code Warrior 8.0: exception
        <BR><BR>g++
        3.4.4: St9exception
        <BR><BR>
        
        <BR><BR>It is difficult
        to recognize what exception was thrown when using those
        compilers except Visual C++.
&#160;
  </TD>
<TD valign="top">
        Consider to add footnote that recommends what() returns
        message easy to recognize what exception was thrown.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>This is a quality of implementation issue that is beyond
the scope of the standard.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US64">US 64</A></TD>
<TD valign="top">
19.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        <font color="#000000">&#8220;</font> See also: ISO C
        7.1.4, 7.2, Amendment 1 4.3.<font color="#000000">&#8221;
        It is unclear why this cross reference is here. Amendment 1
        was to C89, not C99.</font>
&#160;
  </TD>
<TD valign="top">
        Delete this
        cross reference. If necessary, expand the main text to
        include the relevant referenced text
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US65">US 65</A></TD>
<TD valign="top">
20
&#160;
  </TD>
<TD valign="top">
        Scoped allocators and
        allocator propagation traits add a small amount of utility
        at the cost of a great deal of machinery. The machinery is
        user visible, and it extends to library components that
        don't have any obvious connection to allocators, including
        basic concepts and simple components like pair and tuple.
&#160;
  </TD>
<TD valign="top">
        Sketch of proposed resolution: Eliminate scoped allocators,
        replace allocator propagation traits with a simple uniform
        rule (e.g. always propagate on copy and move), remove all
        mention of allocators from components that don't explicitly
        allocate memory (e.g. pair), and adjust container
        interfaces to reflect this simplification.
        <BR><BR>
        Components that I propose eliminating include <font size="2" style="font-size: 11pt"><font color="#0000FF"><span style="background: #ffffce">HasAllocatorType</span></font><font color="#000080">
        <u><a href="http://wiki.corp.google.com/twiki/bin/edit/Main/HasAllocatorType?topicparent=Main.CppStandardIssues">
        ?</a></u></font>, is_scoped_allocator,
        allocator_propagation_map, scoped_allocator_adaptor, and
        <font color="#0000FF"><span style="background: #ffffce">ConstructibleAsElement</span></font><font color="#000080">
        <u><a href="http://wiki.corp.google.com/twiki/bin/edit/Main/ConstructibleAsElement?topicparent=Main.CppStandardIssues">
        ?</a></u></font>.</font>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1075">1075</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>Scoped allocators have been revised significantly.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK198">UK 198</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/126">
     [126]
    </A></TD>
<TD valign="top">
20
&#160;
  </TD>
<TD valign="top">
        The organization of clause 20 could be
        improved to better group related items, making the standard
        easier to navigate.
&#160;
  </TD>
<TD valign="top">
        20.6.7, 20.6.8,
        20.6.9 and 20.6.10 should be grouped under a section called
        "operator wrappers" or similar. The goal of all 4
        subsections combined is to provide a functor for every
        operator in the language. 20.6.17 class template hash
        should numerically appear immediately after the operator
        wrappers, as they are functors that are used in similar
        ways 20.6.11, 20.6.12, 20.6.13, 20.6.14, 20.6.15 are
        strongly related to 20.6.3, and to an extent 20.6.2. These
        should all come under a subheading of "function adapters"
        20.7.1, 20.7.3, 20.7.4, 20.7.5, 20.7.6, 20.7.7 and 20.7.10
        should all be grouped as subclauses under [20.7.2
        Allocators] [20.7.12 unique_ptr] should be a sub-section of
        [20.7.13 smart pointers] [20.7.13 smart pointers] is
        important enough to have a high level bullet after [20.7
        memory], suggest renumbering as [20.8 smart pointers]
        [20.7.13.7 Pointer safety] is nothing to do with smart
        pointers and should become its own subclause [20.7.14
        Pointer safety] [20.9 date and time functions] should be
        moved under [20.8 time utilities] and retitled [20.8.6 C
        Library] (as per memory management/C Library) [20.6.18
        reference_closure] is fundamentally a language support
        feature and should move to clause 18, see separate comment
        [20.6.5 reference_wrapper] should be simplified and moved
        into [2.2 utility components], see separate comment [20.6.4
        result_of] should be reorganised as a type trait - see
        separate comment Tuples and pairs are closely related so
        merge tuple and pair into the same subclause - see more
        general comment on this
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK199">UK 199</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/127">
     [127]
    </A></TD>
<TD valign="top">
20.1.1, 20.1.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The requirement
        that programs do not supply concept_maps should probably be
        users do not supply their own concept_map specializations.
        THe program will almost certainly supply concept_maps - the
        standard itself supplies a specialization for RvalueOf?
        references. Note that the term _program_ is defined in
        3.5p1 and makes no account of the standard library being
        treated differently to user written code.
&#160;
  </TD>
<TD valign="top">
        Replace the term 'program' with 'user'.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1015">1015</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK200">UK 200</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/354">
     [354]
    </A></TD>
<TD valign="top">
20.1.4
&#160;
  </TD>
<TD valign="top">
        All standard library use expects Predicates
        to be CopyConstructible, and this should be recognised
        easily without reatedly stating on every use-case.
&#160;
  </TD>
<TD valign="top">
        Either require
        CopyConstructible&lt;F&gt; as part of Predicate, or create
        a refined concept, StdPredicate, used throughout the
        library that requires CopyConstructible as well as
        Callable. Consider making (Std)Predicate SemiRegular.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>After further 
    discussion of UK200, we do not think adding constraints to predicates is a 
    good idea. Straw poll on UK200: status quo, 5 pro - 2 con; remove 
    copy-constructible, 3 pro - 4 con; pred must be copy-constructible, 4 pro - 
    3 con; no consensus for moving away from the status quo.<BR><BR>
    Also see UK245.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK201">UK 201</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/290">
     [290]
    </A></TD>
<TD valign="top">
20.1.5
&#160;
  </TD>
<TD valign="top">
        The Consistency axiom for
        LessThanComparable will not compile.
&#160;
  </TD>
<TD valign="top">
        Add a requires
        clause to the Consistency axiomL requires
        HasLessEquals&lt;T&gt; &amp;&amp;
        HasGreaterEquals&lt;T&gt;, or split the Consistency axiom
        into two so that 'basic' consistency can be asserted
        regardless of the &lt;=/&gt;= requirement.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>After consultation with the submitter, we agreed that the suggestion was in 
    error and there is nothing else to be done.

&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP33">JP 33</A></TD>
<TD valign="top">
20.1.5
&#160;
  </TD>
<TD valign="top">
        LessThanComparable and EqualityComparable don't correspond
        to NaN.
&#160;
  </TD>
<TD valign="top">
        Apply
        concept_map to these concepts at FloatingPointType
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1016">1016</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US66">US 66</A></TD>
<TD valign="top">
20.1.10
&#160;
  </TD>
<TD valign="top">
        Application of the "Regular" concept to floating-point
        types appears to be controversial (see long discussion on
        std-lib reflector).
&#160;
  </TD>
<TD valign="top">
        State that the &#8220;Regular&#8221; concept does not
        apply to floating-point types.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1017">1017</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP34">JP 34</A></TD>
<TD valign="top">
20.2

    &#182;
    
        1<sup>st</sup> <font size="2" style="font-size: 11pt">para, 4<sup>th</sup> line</font>
&#160;
  </TD>
<TD valign="top">
        Though N2672 pointed at adding
        "#include&lt;initializer_list&gt;", it isn't reflected.
&#160;
  </TD>
<TD valign="top">
        add
        followings
        <BR><BR>
        #include &lt;initializer_list&gt; // for concept_map
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US67">US 67</A></TD>
<TD valign="top">
20.2.1

    &#182;
    
5 first sent.
&#160;
  </TD>
<TD valign="top">
        Some connective words are missing.
&#160;
  </TD>
<TD valign="top">
        Insert &#8220;corresponding to&#8221; before &#8220;an
        lvalue reference type.&#8221;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP35">JP 35</A></TD>
<TD valign="top">
20.2.3

    &#182;
    
        6<sup>th</sup> <font size="2" style="font-size: 11pt">para, 1<sup>st</sup> line</font>
&#160;
  </TD>
<TD valign="top">
        Typo,
        <BR><BR>"stdforward" should be
        "std::forward"
&#160;
  </TD>
<TD valign="top">
        Correct typo.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK202">UK 202</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/213">
     [213]
    </A></TD>
<TD valign="top">
20.2.4
&#160;
  </TD>
<TD valign="top">
        The references
        to pair in the tuple-like access to pair functions qualify
        pair with std::pair even though they are in a namespace std
        block.
&#160;
  </TD>
<TD valign="top">
        Remove the std:: qualification from these
        references to pair.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US68">US 68</A></TD>
<TD valign="top">
20.2.12

    &#182;
    
IntegralLike
&#160;
  </TD>
<TD valign="top">
        The code defining the context is syntactically
        incorrect.
&#160;
  </TD>
<TD valign="top">
        Insert a comma in two places: at the end of the third
        line of refinements, and at the end of the fourth line of
        refinements.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
Section reference should be 20.1.12.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK203">UK 203</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/229">
     [229]
    </A></TD>
<TD valign="top">
20.3.2

    &#182;
    
1-4
&#160;
  </TD>
<TD valign="top">
        The ratio_xyz
        types have a misplaced '}'. For example: template &lt;class
        R1, class R2&gt; struct ratio_add { typedef see below}
        type; ;
&#160;
  </TD>
<TD valign="top">
        Move the '}' to after the typedef: template
        &lt;class R1, class R2&gt; struct ratio_add { typedef see
        below type; };
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP36">JP 36</A></TD>
<TD valign="top">
20.4.2.1

    &#182;
    
        19<sup>th</sup> <font size="2" style="font-size: 11pt">para, 6<sup>th</sup> line</font>
&#160;
  </TD>
<TD valign="top">
        Typo.
        <BR><BR>"it
        it" should be "it is"
&#160;
  </TD>
<TD valign="top">
        Correct typo.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK204">UK 204</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/239">
     [239]
    </A></TD>
<TD valign="top">
20.5

    &#182;
    
Table 41
&#160;
  </TD>
<TD valign="top">
        It is not
        possible to create a variant union based on a parameter
        pack expansion, e.g. to implement a classic discriminated
        union template.
&#160;
  </TD>
<TD valign="top">
        Restore aligned_union template that was
        removed by LWG issue 856.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1020">1020</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Section reference should be 20.5.7 instead of 20.5.
Paper N2843 proposes an extension to the [[align]] attribute that further diminishes the need for this template.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US69">US 69</A></TD>
<TD valign="top">
20.5
&#160;
  </TD>
<TD valign="top">
        This section, dealing with tuple&lt;&gt;, should be in
        the same section as the similar utility pair&lt;&gt;.
&#160;
  </TD>
<TD valign="top">
        Restructure Clause 20 so as to bring these similar
        components together.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK205">UK 205</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/253">
     [253]
    </A></TD>
<TD valign="top">
20.5.3
&#160;
  </TD>
<TD valign="top">
        integral_constant objects should be usable in
        integral-constant-expressions. The addition to the language
        of literal types and the enhanced rules for constant
        expressions make this possible.
&#160;
  </TD>
<TD valign="top">
        Add a constexpr conversion operator to
        class tempalate integral_constant: constexpr operator
        value_type() { return value; }
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1019">1019</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK206">UK 206</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/255">
     [255]
    </A></TD>
<TD valign="top">
20.5.5

    &#182;
    
para 4
&#160;
  </TD>
<TD valign="top">
        Currently the
        std says: "In order to instantiate the template
        is_convertible&lt;From, To&gt;, the following code shall be
        well formed:" But the code shown is the requirement for the
        result of is_convertible to be a true_type, not a
        precondition on whether the template can be instantiated.
&#160;
  </TD>
<TD valign="top">
        Change: "In order to instantiate the
        template is_convertible&lt;From, To&gt;, the following code
        shall be well formed:" To: "The template
        is_convertible&lt;From, To&gt; inherits either directly or
        indirectly from true_type if the following code is well
        formed:"
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#975">975</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK207">UK 207</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/256">
     [256]
    </A></TD>
<TD valign="top">
20.5.6.1

    &#182;
    
Table 36
&#160;
  </TD>
<TD valign="top">
        suffix "::type" is missing from the some of
        the examples.
&#160;
  </TD>
<TD valign="top">
        Change:
        Example:remove_const&lt;const volatile int&gt;::type
        evaluates to volatile int, whereas remove_const&lt;const
        int*&gt; is const int*. &#8212;end example To:
        Example:remove_const&lt;const volatile int&gt;::type
        evaluates to volatile int, whereas remove_const&lt;const
        int*&gt;::type is const int*. &#8212;end example And
        change: Example:remove_volatile&lt;const volatile
        int&gt;::type evaluates to const int, whereas
        remove_volatile&lt;volatile int*&gt; is volatile int*.
        &#8212;end example To: Example:remove_volatile&lt;const
        volatile int&gt;::type evaluates to const int, whereas
        remove_volatile&lt;volatile int*&gt;::type is volatile
        int*. &#8212;end example And change:
        Example:remove_cv&lt;const volatile int&gt;::type evaluates
        to int, whereas remove_cv&lt;const volatile int*&gt; is
        const volatile int*. &#8212;end example To:
        Example:remove_cv&lt;const volatile int&gt;::type evaluates
        to int, whereas remove_cv&lt;const volatile int*&gt;::type
        is const volatile int*. &#8212;end example
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP37">JP 37</A></TD>
<TD valign="top">
20.5.7

    &#182;
    
Table 41
&#160;
  </TD>
<TD valign="top">
        Typo.
        <BR><BR>There isn't a
        period at the end of enable_if's comments.
        <BR><BR>
        
        <BR><BR>If
        B is true, the member typedef type shall equal T;
        otherwise, there shall be no member typedef type
        <BR><BR>
        
        <BR><BR>
        should be
        <BR><BR>
        
        <BR><BR>If
        B is true, the member typedef type shall equal T;
        otherwise, there shall be no member typedef type.
&#160;
  </TD>
<TD valign="top">
        Add
        &#8221;.&#8221;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US70">US 70</A></TD>
<TD valign="top">
20.6
&#160;
  </TD>
<TD valign="top">
        Specifications now expressed via narrative text are more
        accurately and clearly expressed via executable code.
&#160;
  </TD>
<TD valign="top">
        Wherever
        concepts are available that directly match this
        section&#8217;s type traits, express the traits in terms of
        the concepts instead of via narrative text. Where the type
        traits do not quite match the corresponding concepts, bring
        the two into alignment so as to avoid two nearly-identical
        notions.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1018">1018</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Section reference should be 20.5 instead of 20.6.
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US71">US 71</A></TD>
<TD valign="top">
20.6.7

    &#182;
    
Table 51, last row, column 3
&#160;
  </TD>
<TD valign="top">
        The grammar is incorrect.
&#160;
  </TD>
<TD valign="top">
        Change &#8220;conversion are&#8221; to &#8220;conversion
        is&#8221;.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
"conversions are" is correct.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP38">JP 38</A></TD>
<TD valign="top">
20.6.12.1.3
&#160;
  </TD>
<TD valign="top">
        add the move requirement for bind's return type.
        
        <BR><BR>
        For example, assume following th1 and th2,
        <BR><BR>
        
        void f(vector&lt;int&gt; v) { }
        
        vector&lt;int&gt; v{ ... };
        thread th1([v]{ f(v); });
        thread th2(bind(f, v));
        
        When function object are set to thread, v is moved to th1's
        lambda expression in a Move Constructor of lambda
        expression becuase th1's lambda expression has a Move
        Constructor. But bind of th2's return type doesn't have the
        requirement of Move, so it may not moved but copied.
        <BR><BR>Add
        the requirement of move to get rid of this useless copy.
        <BR><BR>And also, add
        the MoveConstructible as well as CopyConstructible.
&#160;
  </TD>
<TD valign="top">
        Add
        the following requirements.
        "<font color="#000000">it has a public move constructor
        that performs a member-wise move."</font>
        <BR><BR>Add
        the MoveConstructible.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#817">817</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP39">JP 39</A></TD>
<TD valign="top">
20.6.16.2
&#160;
  </TD>
<TD valign="top">
        There are no requires corresponding to F of std::function.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR><BR>
        template&lt;class F, Allocator A&gt;
        function(allocator_arg_t, const A&amp;, F);
        <BR>
        template&lt;class F, Allocator A&gt;
        function(allocator_arg_t, const A&amp;, F&amp;&amp;);
        <BR>
        
        <BR>should be
        <BR>
        
        <BR>
        template&lt;class F, Allocator A&gt;
        <BR>
        requires CopyConstructible&lt;F&gt; &amp;&amp;
        Callable&lt;F, ArgTypes...&gt;
        <BR>
        &amp;&amp; Convertible&lt;Callable&lt;F,
        ArgTypes...&gt;::result_type, R&gt;
        <BR>
        function(allocator_arg_t, const A&amp;, F);
        <BR>
        template&lt;class F, Allocator A&gt;
        <BR>
        requires CopyConstructible&lt;F&gt; &amp;&amp;
        Callable&lt;F, ArgTypes...&gt;
        <BR>
        &amp;&amp; Convertible&lt;Callable&lt;F,
        ArgTypes...&gt;::result_type, R&gt;
        <BR>
        function(allocator_arg_t, const A&amp;, F&amp;&amp;);
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1024">1024</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP40">JP 40</A></TD>
<TD valign="top">
20.6.16.2
&#160;
  </TD>
<TD valign="top">
        Thougn it's "Allocator Aloc" at other places, it's
        "Allocator A" only std::function constructor template
        parameter.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR><BR>
        template&lt;class F, Allocator A&gt;
        function(allocator_arg_t, const A&amp;, F);
        <BR><BR>
        template&lt;class F, Allocator A&gt;
        function(allocator_arg_t, const A&amp;, F&amp;&amp;);
        <BR><BR>
        
        <BR><BR>should be
        <BR><BR>
        
        <BR><BR>
        template&lt;class F, Allocator <u>Alloc</u>&gt;
        function(allocator_arg_t, const <u>Alloc</u> &amp;, F);
        <BR><BR>
        template&lt;class F, Allocator <u>Alloc</u>&gt;
        function(allocator_arg_t, const <u>Alloc</u> &amp;,
        F&amp;&amp;);
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP41">JP 41</A></TD>
<TD valign="top">
20.6.16.2
&#160;
  </TD>
<TD valign="top">
        There are no requires corresponding to R and Args of
        UsesAllocator.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR><BR>
        template &lt;class R, class... Args&gt;
        <BR>
        concept_map UsesAllocator&lt;function&lt;R(Args...)&gt;,
        Alloc&gt; {
        <BR>
        typedef Alloc allocator_type;
        <BR>}
        <BR>
        
        <BR>should be
        <BR>
        
        <BR>
        template &lt;<u>Returnable</u> R,
        <u>CopyConstructible</u>... Args&gt;
        <BR>
        concept_map UsesAllocator&lt;function&lt;R(Args...)&gt;,
        Alloc&gt; {
        <BR>
        typedef Alloc allocator_type;
        <BR>}
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>This change would be redundant because function&lt;&gt; is already sufficiently 
    constrained. No actions necessary.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP42">JP 42</A></TD>
<TD valign="top">
20.6.16.2
&#160;
  </TD>
<TD valign="top">
        The requires
        are wrong.
        <BR><BR>R
        require Returnable, and ArgTypes requires CopyConstructible
        by a definition of function, then it's a mistake to
        designate followings by MoveConstructible.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR>
        
        <BR>
        template &lt;MoveConstructible R, MoveConstructible...
        ArgTypes&gt;
        <BR>
        bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;,
        nullptr_t);
        <BR>
        template &lt;MoveConstructible R, MoveConstructible...
        ArgTypes&gt;
        <BR>
        bool operator==(nullptr_t, const
        function&lt;R(ArgTypes...)&gt;&amp;);
        <BR>
        template &lt;MoveConstructible R, MoveConstructible...
        ArgTypes&gt;
        <BR>
        bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;,
        nullptr_t);
        <BR>
        template &lt;MoveConstructible R, MoveConstructible...
        ArgTypes&gt;
        <BR>
        bool operator!=(nullptr_t, const
        function&lt;R(ArgTypes...)&gt;&amp;);
        <BR>
        template &lt;MoveConstructible R, MoveConstructible...
        ArgTypes&gt;
        <BR>
        void swap(function&lt;R(ArgTypes...)&gt;&amp;,
        function&lt;R(ArgTypes...)&gt;&amp;);
        <BR>
        
        <BR>should be
        <BR>
        
        <BR>
        template &lt;<u>Returnable</u> R,
        <u>CopyConstructible</u>... ArgTypes&gt;
        <BR>
        bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;,
        nullptr_t);
        <BR>
        template &lt;<u>Returnable</u> R,
        <u>CopyConstructible</u>... ArgTypes&gt;
        <BR>
        bool operator==(nullptr_t, const
        function&lt;R(ArgTypes...)&gt;&amp;);
        <BR>
        template &lt;<u>Returnable</u> R,
        <u>CopyConstructible</u>... ArgTypes&gt;
        <BR>
        bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;,
        nullptr_t);
        <BR>
        template &lt;<u>Returnable</u> R,
        <u>CopyConstructible</u>... ArgTypes&gt;
        <BR>
        bool operator!=(nullptr_t, const
        function&lt;R(ArgTypes...)&gt;&amp;);
        <BR>
        template &lt;<u>Returnable</u> R,
        <u>CopyConstructible</u>... ArgTypes&gt;
        <BR>void
        swap(function&lt;R(ArgTypes...)&gt;&amp;,
        function&lt;R(ArgTypes...)&gt;&amp;);
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK208">UK 208</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/338">
     [338]
    </A></TD>
<TD valign="top">
20.6.17

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        std::hash should
        be implemented for much more of the standard library. In
        particular for pair, tuple and all the standard containers.
&#160;
  </TD>
<TD valign="top">
        .
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#978">978</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK209">UK 209</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/111">
     [111]
    </A></TD>
<TD valign="top">
20.7
&#160;
  </TD>
<TD valign="top">
        Smart pointers cannot be used in
        constrained templates
&#160;
  </TD>
<TD valign="top">
        Provide
        constraints for smart pointers
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1026">1026</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK213">UK 213</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/357">
     [357]
    </A></TD>
<TD valign="top">
20.7.6
&#160;
  </TD>
<TD valign="top">
        std::allocator
        should be constrained to simplify its use on constrained
        contexts. This library component models allocation from
        free store via the new operator so choose constraints to
        match. The Allocator concept allows for a wider variety of
        allocators that users may choose to supply if their
        allocation model does not require operator new, without
        impacting the requirements of this template.
&#160;
  </TD>
<TD valign="top">
        The primary allocator template should be
        constrained to require ObjectType&lt;T&gt; and
        FreeStoreAllocatable&lt;T&gt;. Further operations to be
        constrained as required.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1027">1027</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK214">UK 214</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/125">
     [125]
    </A></TD>
<TD valign="top">
20.7.8
&#160;
  </TD>
<TD valign="top">
        raw_storage_iterator needs constraining as an iterator
        adaptor to be safely used in constrained templates
&#160;
  </TD>
<TD valign="top">
        Constrain the raw_storage_iterator template
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1028">1028</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK210">UK 210</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/124">
     [124]
    </A></TD>
<TD valign="top">
20.7.11
&#160;
  </TD>
<TD valign="top">
        Specialized algorithms for memory
        managenment need requirements to be easily usable in
        constrained templates
&#160;
  </TD>
<TD valign="top">
        Provide
        constraints for all algorithms in 20.7.11
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1029">1029</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE20">DE 20</A></TD>
<TD valign="top">
20.7.12
&#160;
  </TD>
<TD valign="top">
        DE-20 The section heading and the first sentence use the
        term "template function", which is undefined.
&#160;
  </TD>
<TD valign="top">
        Replace
        "template function" by "function template".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
Section reference should be 20.6.12 instead of 20.7.12.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US72">US 72</A></TD>
<TD valign="top">
20.7.12
&#160;
  </TD>
<TD valign="top">
        bind should support move-only functors and bound arguments.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#817">817</A>&#160;
  </TD>
<TD valign="top">
Section reference should be 20.6.12.1.3 instead of 20.7.12.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE21">DE 21</A></TD>
<TD valign="top">
20.7.12.1.3
&#160;
  </TD>
<TD valign="top">
        DE-21 The specification for bind claims twice that "the
        values and types for the bound arguments v1, v2, ..., vN
        are determined as specified below". No such specification
        appears to exist.
&#160;
  </TD>
<TD valign="top">
        Add the missing specification in the same section, or
        add a cross-reference indicating the section where the
        specification appears.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#817">817</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
Section reference should be 20.6.12.1.3 instead of 20.7.12.1.3.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK211">UK 211</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/428">
     [428]
    </A></TD>
<TD valign="top">
20.7.12.2.3

    &#182;
    
11
&#160;
  </TD>
<TD valign="top">
        The nullptr_t
        type was introduced to resolve the null pointer literal
        problem. It should be used for the assignemnt operator, as
        with the constructor and elsewhere through the library.
&#160;
  </TD>
<TD valign="top">
        Change signature here and in the synopsis
        to: unique_ptr&amp; operator=(nullptr_t); Strike the
        sentance an note before the Effects clause.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1021">1021</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
Section reference should be 20.6.12.2.3 instead of 20.7.12.2.3.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK212">UK 212</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/270">
     [270]
    </A></TD>
<TD valign="top">
20.7.13.7
&#160;
  </TD>
<TD valign="top">
        The
        pointer-safety API is nothing to do with smart pointers, so
        does not belong in 20.7.13. In fact it is a set of language
        support features are really belongs in clause 18, with the
        contents declared in a header that deals with
        language-support of memory management.
&#160;
  </TD>
<TD valign="top">
        Move this specification to 18.5. Move the
        declarations into the header &lt;new&gt;.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Section reference should be 20.6.13.7 instead of 20.7.13.7.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE22">DE 22</A></TD>
<TD valign="top">
20.7.16.2
&#160;
  </TD>
<TD valign="top">
        DE-22 The conditions for deriving from
        std::unary_function and std::binary_function are unclear:
        The condition would also be satisfied if ArgTypes were
        std::vector&lt;T1&gt;, because it (arguably) "contains" T1.
&#160;
  </TD>
<TD valign="top">
        Consider stating the conditions in normative prose
        instead of in comments in the class definition. Use
        "consists of" instead of "contains". Consider using "if and
        only if" instead of "iff".
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1023">1023</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
Section reference should be 20.6.16.2 instead of 20.7.16.2.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US73">US 73</A></TD>
<TD valign="top">
20.7.18
&#160;
  </TD>
<TD valign="top">
        The
        std::reference_closure template is redundant with
        std::function and should be removed.
        <BR><BR>
        <BR><BR>
        std::reference_closure is a premature optimization that
        provides a limited subset of the functionality of
        std::function intended to improve performance in a narrow
        use case. However, the &#8220;parallel application
        performance&#8221; benchmark used to motivate the inclusion
        of std::reference_closure was flawed in several ways:
        <ol start="3">
          <li>
            <BR><BR>it failed to
            enable a common optimization in std::function
            (implemented by all vendors), exacting a large and
            unrealistic penalty for copying std::function
            instances, and</li>
          <li>
            <BR><BR>it failed to
            account for parallel scheduler overhead or
            realistically-sized work units, both of which would
            dominate the costs measured by the benchmark in any
            realistic application.</li>
          </ol>
&#160;
  </TD>
<TD valign="top">
        Remove 20.7.18
        [func.referenceclosure].
        <BR><BR>
        <BR><BR>Remove 5.1.1 paragraph 12.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#750">750</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
Section reference should be 20.6.18 instead of 20.7.18.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2845.html">
     N2845</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US74.1">US 74.1</A></TD>
<TD valign="top">
20.8
&#160;
  </TD>
<TD valign="top">
        Scoped
        allocators represent a poor trade-off for standardization,
        since (1) scoped-allocator--aware containers can be
        implemented outside the C++ standard library but used with
        its algorithms, (2) scoped allocators only benefit a tiny
        proportion of the C++ community (since few C++ programmers
        even use today&#8217;s allocators), and (3) all C++ users,
        especially the vast majority of the C++ community that
        won&#8217;t ever use scoped allocators are forced to cope
        with the interface complexity introduced by scoped
        allocators. In essence, the larger community will suffer to
        support a very small subset of the community who can
        already implement their own data structures outside of the
        standard library. Therefore, scoped allocators should be
        removed from the working paper.
        <BR><BR>Some evidence of
        the complexity introduced by scoped allocators:
        <BR><BR>20.3.3, 20.5:
        large increase in the number of pair and tuple constructors
        <BR><BR>23: confusing
        &#8220;AllocatableElement&#8221; requirements throughout.
&#160;
  </TD>
<TD valign="top">
        Remove support
        for scoped allocators from the working paper. This includes
        at least the following changes:
        <BR><BR>
        <BR><BR>Remove 20.8.3
        [allocator.element.concepts]
        <BR><BR>
        <BR><BR>Remove 20.8.7
        [allocator.adaptor]
        <BR><BR>
        <BR><BR>Remove 20.8.10
        [construct.element]
        <BR><BR>
        <BR><BR>In Clause 23:
        replace requirements naming the AllocatableElement concept
        with requirements naming CopyConstructible,
        MoveConstructible, DefaultConstructible, or Constructible,
        as appropriate.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1075">1075</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>Scoped allocators have been revised significantly. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US74.2">US 74.2</A></TD>
<TD valign="top">
20.8.2.2

    &#182;
    
(a) synopsis (b) after &#182; 14
&#160;
  </TD>
<TD valign="top">
        A concept name is twice misspelled.
&#160;
  </TD>
<TD valign="top">
        Change &#8220;Hasconstructor&#8221; to
        &#8220;HasConstructor&#8221; (twice).
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
(The text in question is in 20.7.2.2, not 20.8.2.2.)
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US75">US 75</A></TD>
<TD valign="top">
20.8.2.2
&#160;
  </TD>
<TD valign="top">
        Allocator concepts are incomplete
&#160;
  </TD>
<TD valign="top">
        See paper:
        http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
     N2840</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP43">JP 43</A></TD>
<TD valign="top">
20.8.3
&#160;
  </TD>
<TD valign="top">
        Typo.
        <BR><BR>
        "alloc" should be "Alloc"
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR><BR>
        
        <BR><BR>
        auto concept UsesAllocator&lt;typename T, typename
        Alloc&gt; {
        <BR><BR>
        requires Allocator&lt;alloc&gt;;
        <BR><BR>
        typename allocator_type = T::allocator_type;
        <BR><BR>
        
        <BR><BR>
        should be
        <BR><BR>
        <BR><BR>
        auto concept UsesAllocator&lt;typename T, typename
        Alloc&gt; {
        <BR><BR>
        requires Allocator&lt;<u>Alloc</u>&gt;;
        <BR><BR>typename
        allocator_type = T::allocator_type;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK215">UK 215</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/356">
     [356]
    </A></TD>
<TD valign="top">
20.8.3.3

    &#182;
    
6,8
&#160;
  </TD>
<TD valign="top">
        Extra pair of
        {}, presumably some formatting code gone awry :
        duration&amp; operator-{-}();
&#160;
  </TD>
<TD valign="top">
        Remove the {} or fix formatting
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US77">US 77</A></TD>
<TD valign="top">
20.8.4
&#160;
  </TD>
<TD valign="top">
        Allocator-specific move and copy behavior for containers
        (N2525) complicates a little-used and already-complicated
        portion of the standard library (allocators), and breaks
        the conceptual model of move-constructor and
        move-assignment operations on standard containers being
        efficient operations. The extensions for allocator-specific
        move and copy behavior should be removed from the working
        paper.
        <BR><BR>With the
        introduction of rvalue references, we are teaching
        programmers that moving from a standard container (e.g., a
        vector&lt;string&gt;) is an efficient, constant-time
        operation. The introduction of N2525 removed that
        guarantee; depending on the behavior of four different
        traits (20.8.4), the complexity of copy and move operations
        can be constant or linear time. This level of customization
        greatly increases the complexity of standard containers,
        and benefits only a tiny fraction of the C++ community.
&#160;
  </TD>
<TD valign="top">
        Remove 20.8.4.
        <BR><BR>
        <BR><BR>Remove 20.8.5.
        <BR><BR>
        <BR><BR>Remove all references to the facilities in
        20.8.4 and 20.8.5 from clause 23.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1166">1166</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US78">US 78</A></TD>
<TD valign="top">
20.8.12,
        20.8.13.2
&#160;
  </TD>
<TD valign="top">
        There is presently no way to
        convert directly from a <font size="2" style="font-size: 11pt"><code>shared_ptr</code> to a
        <code>unique_ptr</code>.</font>
&#160;
  </TD>
<TD valign="top">
        Add
        an interface that performs the conversion. See the
        attached, Issues with the C++ Standard" paper under Chapter
        20, "Conversion from <font size="2" style="font-size: 11pt"><code>shared_ptr</code> to
        <code>unique_ptr".</code></font>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1031">1031</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>There are non-trivial design issues which would need to be implemented and tested in the field for usability prior to standardization. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US79">US 79</A></TD>
<TD valign="top">
20.8.12.2.1
&#160;
  </TD>
<TD valign="top">
        [unique.ptr.single.ctor]/5 no longer requires for D not to
        be a pointer type. This restriction needs to be put
        back in. Otherwise we have a run time failure that
        could have been caught at compile time:
        <BR><BR>
        
        <BR><BR>
        unique_ptr&lt;int, void(*)(void*)&gt;
        p(malloc(sizeof(int))); // should not compile
        <BR><BR>
        
        <BR><BR>
        unique_ptr&lt;int, void(*)(void*)&gt;
        p(malloc(sizeof(int)), free); // ok
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#932">932</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP44">JP 44</A></TD>
<TD valign="top">
20.8.13.6
&#160;
  </TD>
<TD valign="top">
        The
        1st parameter p and 2nd parameter v is now
        shared_ptr&lt;T&gt; *.
        <BR><BR>It
        should be shared_ptr&lt;T&gt;&amp;, or if these are
        shared_ptr&lt;T&gt;* then add the "p shall not be a null
        pointer" at the requires.
&#160;
  </TD>
<TD valign="top">
        Change shared_ptr&lt;T&gt;&amp; or add the "p shall not be
        a null pionter" at the requires.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1030">1030</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
Section reference should be 20.7.13.6 instead of 20.8.13.6.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP45">JP 45</A></TD>
<TD valign="top">
20.9
&#160;
  </TD>
<TD valign="top">
        Rep, Period, Clock and Duration don't correspond to
        concept.
        <BR><BR>
        template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
        class duration;
        <BR><BR>template
        &lt;class Clock, class Duration = typename
        Clock::duration&gt; class time_point;
&#160;
  </TD>
<TD valign="top">
        Make concept for Rep, Period, Clock and Duration, and fix
        20.9 and wait_until and wait_for's template parameter at
        30.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1032">1032</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US80">US 80</A></TD>
<TD valign="top">
20.9.2.1

    &#182;
    
Heading
&#160;
  </TD>
<TD valign="top">
        The section heading does not describe the contents.
&#160;
  </TD>
<TD valign="top">
        Change the
        heading &#8220;<span lang="en-US">is_floating_point</span>&#8221; to
        &#8220;<span lang="en-US">treat_as_floating_point</span>&#8221;. Optionally
        adjust the section&#8217;s label similarly.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Section reference should be 20.8.2.1 instead of 20.9.2.1.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US81">US 81</A></TD>
<TD valign="top">
20.9.3
&#160;
  </TD>
<TD valign="top">
        chrono::duration is missing the modulous operator for both
        member and non-member arithmetic. This operator is useful
        for finding the position of a duration within a bounded
        time frame. Having it be built in to duration is safer than
        requiring the client to extract and operate directly on the
        duration&#8217;s representation as the latter will not
        enforce the correct units of the operation.
        <BR>
        
        <BR>Ex:
        <BR>
        
        <BR>
        milliseconds ms(...);
        <BR>
        microseconds us(...);
        <BR>
        
        <BR>ms
        % us; // microseconds
        <BR>us
        % ms; // microseconds
        <BR>ms
        % 5; // milliseconds
        <BR>5 %
        ms; // does not compile
&#160;
  </TD>
<TD valign="top">
        Add:
        <BR>
        <BR>
        template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
        <BR>
        class duration {
        <BR>
        public:
        <BR>...
        <BR>duration&amp;
        operator%(const rep&amp;);
        <BR>duration&amp;
        operator%(const duration&amp;);
        <BR>..
        <BR>};
        <BR>
        <BR>template
        &lt;class Rep1, class Period,
        <BR>class Rep2&gt;
        <BR>
        duration&lt;typename common_type&lt;
        <BR>Rep1,
        Rep2&gt;::type, Period&gt;
        <BR>operator%(const
        duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
        <BR>
        <BR>template
        &lt;class Rep1, class Period1,
        <BR>class Rep2,
        class Period2&gt;
        <BR>typename
        common_type&lt;duration&lt;Rep1, Period1&gt;,
        duration&lt;Rep2, Period2&gt;&gt;::type
        <BR>operator%(const
        duration&lt;Rep1, Period1&gt;&amp; lhs, const
        duration&lt;Rep2, Period2&gt;&amp; rhs);
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#934">934</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US82">US 82</A></TD>
<TD valign="top">
20.9.5.3

    &#182;
    
after &#182; 1
&#160;
  </TD>
<TD valign="top">
        The code synopsis has a minor alignment error.
&#160;
  </TD>
<TD valign="top">
        Align &#8220;rep&#8221; with the other symbols defined
        in this synopsis.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK216">UK 216</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/282">
     [282]
    </A></TD>
<TD valign="top">
21
&#160;
  </TD>
<TD valign="top">
        All the containers use concepts for their
        iterator usage, exect for basic_string. This needs fixing.
&#160;
  </TD>
<TD valign="top">
        Use concepts for iterator template
        parameters throughout the chapter.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1081">1081</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP46">JP 46</A></TD>
<TD valign="top">
21.2, 21.3
&#160;
  </TD>
<TD valign="top">
        The
        basic_string does not use concept.
&#160;
  </TD>
<TD valign="top">
        The
        "class Alloc" is changed to "Allocator Alloc".
        <BR><BR>The
        "class InputIterator" is changed to "InputIterator Iter".
        <BR><BR>
        
        <BR>//
        21.3, basic_string:
        <BR>
        template&lt;class charT, class traits =
        char_traits&lt;charT&gt;,
        <BR>
        <u>Allocator</u> Alloc = allocator&lt;charT&gt; &gt;
        <BR>
        class basic_string;
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;
        <BR>
        operator+(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        <BR>
        operator+(basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        <BR>
        operator+(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        <BR>
        operator+(basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        lhs,
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;
        <BR>
        operator+(const charT* lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        <BR>
        operator+(const charT* lhs,
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;
        <BR>
        operator+(charT lhs, const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        <BR>
        operator+(charT lhs,
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;
        <BR>
        operator+(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const charT* rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        <BR>
        operator+(basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        lhs,
        <BR>
        const charT* rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;
        <BR>
        operator+(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        charT rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        <BR>
        operator+(basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;&amp;
        lhs, charT rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator==(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator==(const charT* lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator==(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const charT* rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator!=(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator!=(const charT* lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator!=(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const charT* rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator&lt; (const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator&lt; (const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const charT* rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator&lt; (const charT* lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator&gt; (const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator&gt; (const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const charT* rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator&gt; (const charT* lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator&lt;=(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator&lt;=(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const charT* rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator&lt;=(const charT* lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator&gt;=(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator&gt;=(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; lhs,
        <BR>
        const charT* rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        bool operator&gt;=(const charT* lhs,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        rhs);
        <BR>
        
        <BR>//
        21.3.8.8: swap
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        void swap(basic_string&lt;charT,traits,Alloc&gt;&amp; lhs,
        <BR>
        basic_string&lt;charT,traits,Alloc&gt;&amp; rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        void swap(basic_string&lt;charT,traits,Alloc&gt;&amp;&amp;
        lhs,
        <BR>
        basic_string&lt;charT,traits,Alloc&gt;&amp; rhs);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        void swap(basic_string&lt;charT,traits,Alloc&gt;&amp; lhs,
        <BR>
        basic_string&lt;charT,traits,Alloc&gt;&amp;&amp; rhs);
        <BR>
        
        <BR>//
        21.3.8.9: inserters and extractors
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_istream&lt;charT,traits&gt;&amp;
        <BR>
        operator&gt;&gt;(basic_istream&lt;charT,traits&gt;&amp;&amp;
        is,
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; str);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_ostream&lt;charT, traits&gt;&amp;
        <BR>
        operator&lt;&lt;(basic_ostream&lt;charT,
        traits&gt;&amp;&amp; os,
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        str);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_istream&lt;charT,traits&gt;&amp;
        <BR>
        getline(basic_istream&lt;charT,traits&gt;&amp;&amp; is,
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; str,
        <BR>
        charT delim);
        <BR>
        
        <BR>
        template&lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc</u>&gt;
        <BR>
        basic_istream&lt;charT,traits&gt;&amp;
        <BR>
        getline(basic_istream&lt;charT,traits&gt;&amp;&amp; is,
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; str);
        <BR>
        
        <BR>
        
        <BR>//
        21.3 Class template basic_string
        <BR>
        namespace std {
        <BR>
        template&lt;class charT, class traits =
        char_traits&lt;charT&gt;,
        <BR>
        <u>Allocator Alloc</u> = allocator&lt;charT&gt; &gt;
        <BR>
        class basic_string {
        <BR>
        public:
        <BR>//
        types:
        <BR>
        typedef traits traits_type;
        <BR>
        typedef typename traits::char_type value_type;
        <BR>
        typedef <u>Alloc</u> allocator_type;
        <BR>
        typedef typename <u>Alloc</u>::size_type size_type;
        <BR>
        typedef typename <u>Alloc</u>::difference_type
        difference_type;
        <BR>
        typedef typename <u>Alloc</u>::reference reference;
        <BR>
        typedef typename <u>Alloc</u>::const_reference
        const_reference;
        <BR>
        typedef typename <u>Alloc</u>::pointer pointer;
        <BR>
        typedef typename <u>Alloc</u>::const_pointer const_pointer;
        <BR>
        typedef implementation-defined iterator; // See 23.1
        <BR>
        typedef implementation-defined const_iterator; // See 23.1
        <BR>
        typedef std::reverse_iterator&lt;iterator&gt;
        reverse_iterator;
        <BR>
        typedef std::reverse_iterator&lt;const_iterator&gt;
        const_reverse_iterator;
        <BR>
        static const size_type npos = -1;
        <BR>
        
        <BR>//
        21.3.2 construct/copy/destroy:
        <BR>
        explicit basic_string(const <u>Alloc</u>&amp; a =
        <u>Alloc</u>());
        <BR>
        basic_string(const basic_string&amp; str);
        <BR>
        basic_string(basic_string&amp;&amp; str);
        <BR>
        basic_string(const basic_string&amp; str, size_type pos,
        size_type n = npos,
        <BR>
        const <u>Alloc</u>&amp; a = <u>Alloc</u>());
        <BR>
        basic_string(const charT* s,
        <BR>
        size_type n, const <u>Alloc</u>&amp; a = <u>Alloc</u>());
        <BR>
        basic_string(const charT* s, const <u>Alloc</u>&amp; a =
        <u>Alloc</u>());
        <BR>
        basic_string(size_type n, charT c, const <u>Alloc</u>&amp;
        a = <u>Alloc</u>());
        <BR>
        template&lt;<u>InputIterator</u> <u>Iter</u>&gt;
        <BR>
        basic_string(<u>Iter</u> begin, <u>Iter</u> end,
        <BR>
        const <u>Alloc</u>&amp; a = <u>Alloc</u>());
        <BR>
        basic_string(initializer_list&lt;charT&gt;, const
        <u>Alloc</u>&amp; = <u>Alloc</u>());
        <BR>
        basic_string(const basic_string&amp;, const
        <u>Alloc</u>&amp;);
        <BR>
        basic_string(basic_string&amp;&amp;, const
        <u>Alloc</u>&amp;);
        <BR>
        ~basic_string();
        <BR>
        basic_string&amp; operator=(const basic_string&amp; str);
        <BR>
        basic_string&amp; operator=(basic_string&amp;&amp; str);
        <BR>
        basic_string&amp; operator=(const charT* s);
        <BR>
        basic_string&amp; operator=(charT c);
        <BR>
        basic_string&amp; operator=(initializer_list&lt;charT&gt;);
        <BR>
        
        <BR>//
        21.3.3 iterators:
        <BR>...
        <BR>
        
        <BR>//
        21.3.4 capacity:
        <BR>...
        <BR>
        
        <BR>//
        21.3.5 element access:
        <BR>...
        <BR>
        
        <BR>//
        21.3.6 modifiers:
        <BR>...
        <BR>
        
        <BR>
        basic_string&amp; append(const basic_string&amp; str);
        <BR>
        basic_string&amp; append(const basic_string&amp; str,
        size_type pos,
        <BR>
        size_type n);
        <BR>
        basic_string&amp; append(const charT* s, size_type n);
        <BR>
        basic_string&amp; append(const charT* s);
        <BR>
        basic_string&amp; append(size_type n, charT c);
        <BR>
        template&lt;<u>InputIterator</u> <u>Iter</u>&gt;
        <BR>
        basic_string&amp; append(<u>Iter</u> first, <u>Iter</u>
        last);
        <BR>
        basic_string&amp; append(initializer_list&lt;charT&gt;);
        <BR>
        void push_back(charT c);
        <BR>
        
        <BR>
        basic_string&amp; assign(const basic_string&amp; str);
        <BR>
        basic_string&amp; assign(basic_string&amp;&amp; str);
        <BR>
        basic_string&amp; assign(const basic_string&amp; str,
        size_type pos,
        <BR>
        size_type n);
        <BR>
        basic_string&amp; assign(const charT* s, size_type n);
        <BR>
        basic_string&amp; assign(const charT* s);
        <BR>
        basic_string&amp; assign(size_type n, charT c);
        <BR>
        template&lt;<u>InputIterator</u> <u>Iter</u>&gt;
        <BR>
        basic_string&amp; assign(<u>Iter</u> first, <u>Iter</u>
        last);
        <BR>
        basic_string&amp; assign(initializer_list&lt;charT&gt;);
        <BR>
        
        <BR>
        basic_string&amp; insert(size_type pos1, const
        basic_string&amp; str);
        <BR>
        basic_string&amp; insert(size_type pos1, const
        basic_string&amp; str,
        <BR>
        size_type pos2, size_type n);
        <BR>
        basic_string&amp; insert(size_type pos, const charT* s,
        size_type n);
        <BR>
        basic_string&amp; insert(size_type pos, const charT* s);
        <BR>
        basic_string&amp; insert(size_type pos, size_type n, charT
        c);
        <BR>
        iterator insert(const_iterator p, charT c);
        <BR>
        void insert(const_iterator p, size_type n, charT c);
        <BR>
        template&lt;<u>InputIterator</u> <u>Iter</u>&gt;
        <BR>
        void insert(const_iterator p, <u>Iter</u> first,
        <u>Iter</u> last);
        <BR>
        void insert(const_iterator p,
        initializer_list&lt;charT&gt;);
        <BR>
        
        <BR>...
        <BR>
        basic_string&amp; replace(size_type pos1, size_type n1,
        <BR>
        const basic_string&amp; str);
        <BR>
        basic_string&amp; replace(size_type pos1, size_type n1,
        <BR>
        const basic_string&amp; str,
        <BR>
        size_type pos2, size_type n2);
        <BR>
        basic_string&amp; replace(size_type pos, size_type n1,
        const charT* s,
        <BR>
        size_type n2);
        <BR>
        basic_string&amp; replace(size_type pos, size_type n1,
        const charT* s);
        <BR>
        basic_string&amp; replace(size_type pos, size_type n1,
        size_type n2,
        <BR>
        charT c);
        <BR>
        basic_string&amp; replace(iterator i1, iterator i2,
        <BR>
        const basic_string&amp; str);
        <BR>
        basic_string&amp; replace(iterator i1, iterator i2, const
        charT* s,
        <BR>
        size_type n);
        <BR>
        basic_string&amp; replace(iterator i1, iterator i2, const
        charT* s);
        <BR>
        basic_string&amp; replace(iterator i1, iterator i2,
        <BR>
        size_type n, charT c);
        <BR>
        template&lt;<u>InputIterator</u> <u>Iter</u>&gt;
        <BR>
        basic_string&amp; replace(iterator i1, iterator i2,
        <BR>
        <u>Iter</u> j1, <u>Iter</u> j2);
        <BR>
        basic_string&amp; replace(iterator, iterator,
        initializer_list&lt;charT&gt;);
        <BR>
        
        <BR>...
        <BR>
        
        <BR>//
        21.3.7 string operations:
        <BR>...
        <BR>
        
        <BR>
        template &lt;class charT, class traits, <u>Allocator</u>
        <u>Alloc&gt;</u>
        <BR>
        struct constructible_with_allocator_suffix&lt;
        <BR>
        basic_string&lt;charT, traits, <u>Alloc</u>&gt; &gt; :
        true_type { };
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1081">1081</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP47">JP 47</A></TD>
<TD valign="top">
21.3
&#160;
  </TD>
<TD valign="top">
        Typo. Missing &#8221;&gt;&#8221;
        <BR><BR>
        template &lt;class charT, class traits, Allocator Alloc
        <BR><BR>
        
        <BR><BR>
        should be
        <BR><BR>
        
        <BR><BR>
        template &lt;class charT, class traits, Allocator Alloc&gt;
&#160;
  </TD>
<TD valign="top">
        Correct typo.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP48">JP 48</A></TD>
<TD valign="top">
21.3
&#160;
  </TD>
<TD valign="top">
        char_traits does not use concept.
        <BR><BR>For
        example, create CharTraits concept and change as follows:
        <BR><BR>
        
        <BR><BR>
        template&lt;class charT, <u>CharTraits</u> traits =
        char_traits&lt;charT&gt;,
        <BR><BR>
        class Allocator = allocator&lt;charT&gt; &gt;
        <BR><BR>class
        basic_string {
&#160;
  </TD>
<TD valign="top">
        Add
        a concept for char_traits.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1081">1081</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK217">UK 217</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/340">
     [340]
    </A></TD>
<TD valign="top">
21.3
&#160;
  </TD>
<TD valign="top">
        basic_string refers to
        constructible_with_allocator_suffix, which I thought was
        removed?
&#160;
  </TD>
<TD valign="top">
        Remove the
        lines: template &lt;class charT, class traits, class Alloc
        struct constructible_with_allocator_suffix&lt;
        basic_string&lt;charT, traits, Alloc&gt; &gt; : true_type {
        };
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK218">UK 218</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/228">
     [228]
    </A></TD>
<TD valign="top">
21.3.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        The identity
        "&amp;*(s.begin() + n) == &amp;*s.begin() + n" relies on
        operator&amp; doing the "right thing", which (AFAICS) there
        is no requirement for. See my comment under clauses
        "23.2.1, 23.2.6" (p1 in both cases) - this is the same
        issue, but I've created a separate comment for basic_string
        because it is in a different chapter.
&#160;
  </TD>
<TD valign="top">
        See my recommendations for "23.2.1,
        23.2.6".
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1170">1170</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK219">UK 219</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/342">
     [342]
    </A></TD>
<TD valign="top">
21.3.6.6
        [string.replace]

    &#182;
    
11
&#160;
  </TD>
<TD valign="top">
        Effects refers to "whose first begin() - i1
        elements" However i1 is greater than begin()...
&#160;
  </TD>
<TD valign="top">
        Effects refers to "whose first i1 - begin()
        elements"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK220">UK 220</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/339">
     [339]
    </A></TD>
<TD valign="top">
21.3.8.9
&#160;
  </TD>
<TD valign="top">
        The
        operator&lt;&lt; for basic_string takes the output stream
        by r-value reference. This is different from the same
        operator for error_code (19.4.2.6), bitset (20.2.6.3),
        shared_ptr (20.7.13.2.8), complex (26.3.6) and sub_match
        (28.4)
&#160;
  </TD>
<TD valign="top">
        Use the same reference type for the all the
        library types. This should be the r-value reference. There
        are other places in the standard where TR1, and new
        classes, did not receive an 'R-value' update.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#825">825</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
N2844 changed the rvalue reference binding rules. That paper includes generic templates operator&lt;&lt; and operator&gt;&gt; that adapt rvalue streams. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR33">FR 33</A></TD>
<TD valign="top">
22.1.1
[locale]

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        ios_base::iostate err = 0;
        <BR><BR>
        <BR><BR>iostate is a bitmask type and
        so could be an enumeration. Probably using
        goodbit is the solution.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP49">JP 49</A></TD>
<TD valign="top">
22.1.3.2.2
&#160;
  </TD>
<TD valign="top">
        codecvt does not use concept. For example, create
        CodeConvert concept and change as follows.
        <BR><BR>
        template&lt;<u>CodeConvert</u> Codecvt, class Elem =
        wchar_t&gt; class wstring_convert {
&#160;
  </TD>
<TD valign="top">
        Add
        a concept for codecvt.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1082">1082</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP50">JP 50</A></TD>
<TD valign="top">
22.1.3.2.2
&#160;
  </TD>
<TD valign="top">
        Add
        custom allocator parameter to wstring_convert, since we
        cannot allocate memory for strings from a custom allocator.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR>
        template&lt;class Codecvt, class Elem = wchar_t&gt; class
        wstring_convert {
        <BR>
        public:
        <BR>
        typedef std::basic_string&lt;char&gt; byte_string;
        <BR>
        typedef std::basic_string&lt;Elem&gt; wide_string;
        <BR>
        
        <BR>should be
        <BR>
        
        <BR>
        template&lt;class Codecvt, class Elem = wchar_t<u>,</u>
        <BR>
        <u>Allocator WideAllocator = allocator&lt;Elem&gt;,</u>
        <BR>
        <u>Allocator ByteAllocator = allocator&lt;char&gt;</u>&gt;
        <BR>
        class wstring_convert {
        <BR>
        public:
        <BR>
        typedef std::basic_string&lt;char,
        <u>char_traits&lt;char&gt;, ByteAllocator</u>&gt;
        byte_string;
        <BR>typedef
        std::basic_string&lt;Elem, <u>char_traits&lt;Elem&gt;,
        WideAllocator</u>&gt; wide_string;
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#991">991</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI4">FI 4</A></TD>
<TD valign="top">
22.2.1.4.1
        22.2.1.4.2
&#160;
  </TD>
<TD valign="top">
        <tt>to_end and to_limit are both used. Only one is
        needed.</tt>
&#160;
  </TD>
<TD valign="top">
        Change to_limit to to_end.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI5">FI 5</A></TD>
<TD valign="top">
22.2.1.4.2

    &#182;
    
#3
&#160;
  </TD>
<TD valign="top">
        <tt>[ Note: As
        a result of operations on state, it can return ok or
        partial and set next == from and to_next != to. &#8212;end
        note ]</tt>
        
        
        <BR><BR><tt>"next"
        should be "from_next."</tt>
        <BR><BR><tt>Also, the
        sentence applies to all the examples, including do_in and
        do_out.</tt>
        <BR><BR><tt>Reasoning: When reading one element of multibyte
        source data such as UTF-8, it is possible that from_next is
        incremented, to_next is unaltered, state is altered and
        return value is partial.
        When reading one element of wide character data, the output
        can be several multibyte characters, so it is possible that
        from_next is unaltered, to_next is advanced, state is
        altered and return value is partial.</tt>
&#160;
  </TD>
<TD valign="top">
        <tt>[ Note: As a result of operations on state, do_in
        and do_out can return</tt>
        <tt>ok or partial and set from_next == from and/or to_next
        != to. &#8212;end</tt>
        <tt>note ]</tt>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI6">FI 6</A></TD>
<TD valign="top">
22.2.1.5
        <BR><BR>See also
22.2.1.4
(1,2,3)
&#160;
  </TD>
<TD valign="top">
        <tt>codecvt_byname is only specified to work with locale
        names. There is no built-in means to find a codecvt with a
        character set's name. A locale and a character set are not
        the same. If the user has data which is encoded in a
        certain character set and she wants to create a codecvt
        which can convert from that character set to another one,
        she must iterate through locales to find one, or use
        external means (iconv, ICU's uconv). Specifying a locale
        with the character set is not a suitable solution, since
        there is no built-in mapping from character sets to
        locales. It is only possible to inquire the character set
        once the locale is known.</tt>
&#160;
  </TD>
<TD valign="top">
        <tt>There should be a built-in means to find a codecvt
        with a pair of character set names.</tt>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>There is interest (Martin Sebor, POSIX folks) in solving this problem, but 
    addressing it is controversial because it's probably too late in the process 
    for what looks like a new feature.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI7">FI 7</A></TD>
<TD valign="top">
22.2.1.4

    &#182;
    
1,2,3
&#160;
  </TD>
<TD valign="top">
        The word
        "codeset" is used, whereas the word "character set" is used
        elsewhere in the text. The words are intended to convey the
        same concept, so only one should be used (or always both
        together).
&#160;
  </TD>
<TD valign="top">
        Change "codeset" to "character set."
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP51">JP 51</A></TD>
<TD valign="top">
22.2.5.1.1

    &#182;
    
7<sup>th</sup> <font size="2" style="font-size: 11pt">para, 1<sup>st</sup>
        line</font>
&#160;
  </TD>
<TD valign="top">
        A
        parameter `end&#8217; should be `fmtend&#8217;.
        get() function had two `end&#8217; parameters at N2321.
        <BR><BR>
        iter_type get (iter_type s, iter_type end, ios_base&amp; f,
        ios_base::iostate&amp; err, tm* t, const char_type* fmt,
        const char_type *end) const;
        <BR><BR>The function
        prototype of get() has been corrected at N2800, but a
        Requires statement still refers `end&#8217; parameter.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR><BR>
        Requires: [fmt,end) shall be a valid range.
        <BR>
        
        <BR>
        should be
        <BR>
        
        <BR>
        Requires: [fmt,fmtend) shall be a valid range.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP52">JP 52</A></TD>
<TD valign="top">
22.2.5.1,
        22.2.5.2,
        22.2.6.1
&#160;
  </TD>
<TD valign="top">
        InputIterator does not use concept.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR>
        
        <BR>
        22.2.5.1
        <BR>
        
        <BR>
        template &lt;class charT, class InputIterator =
        istreambuf_iterator&lt;charT&gt; &gt;
        <BR>
        class time_get : public locale::facet, public time_base {
        <BR>
        public:
        <BR>
        typedef charT char_type;
        <BR>
        typedef InputIterator iter_type;
        <BR>
        
        <BR>
        should be
        <BR>
        
        <BR>
        template &lt;class charT, <u>InputIterator InputIter</u> =
        istreambuf_iterator&lt;charT&gt; &gt;
        <BR>
        class time_get : public locale::facet, public time_base {
        <BR>
        public:
        <BR>
        typedef charT char_type;
        <BR>
        typedef <u>InputIter</u> iter_type;
        <BR>
        
        <BR>
        
        <BR>
        22.2.5.2
        <BR>
        
        <BR>
        template &lt;class charT, class InputIterator =
        istreambuf_iterator&lt;charT&gt; &gt;
        <BR>
        class time_get_byname : public time_get&lt;charT,
        InputIterator&gt; {
        <BR>
        public:
        <BR>
        typedef time_base::dateorder dateorder;
        <BR>
        typedef InputIterator iter_type;
        <BR>
        
        <BR>
        should be
        <BR>
        
        <BR>
        template &lt;class charT, <u>InputIterator InputIter</u> =
        istreambuf_iterator&lt;charT&gt; &gt;
        <BR>
        class time_get_byname : public time_get&lt;charT,
        InputIter&gt; {
        <BR>
        public:
        <BR>
        typedef time_base::dateorder dateorder;
        <BR>
        typedef <u>InputIter</u> iter_type;
        <BR>
        
        <BR>
        
        <BR>
        22.2.6.1
        <BR>
        
        <BR>
        template &lt;class charT,
        <BR>
        class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
        <BR>
        class money_get : public locale::facet {
        <BR>
        public:
        <BR>
        typedef charT char_type;
        <BR>
        typedef InputIterator iter_type;
        <BR>
        
        <BR>
        should be
        <BR>
        
        <BR>
        template &lt;class charT,
        <BR>
        <u>InputIterator InputIter</u> =
        istreambuf_iterator&lt;charT&gt; &gt;
        <BR>
        class money_get : public locale::facet {
        <BR>
        public:
        <BR>
        typedef charT char_type;
        <BR>
        typedef <u>InputIter</u> iter_type;
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1083">1083</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP53">JP 53</A></TD>
<TD valign="top">
22.2.5.3 ,
        22.2.5.4
&#160;
  </TD>
<TD valign="top">
        OutputIterator does not use concept.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR>
        
        <BR>
        22.2.5.3
        <BR>
        
        <BR>
        template &lt;class charT, class OutputIterator =
        ostreambuf_iterator&lt;charT&gt; &gt;
        <BR>
        class time_put : public locale::facet {
        <BR>
        public:
        <BR>
        typedef charT char_type;
        <BR>
        typedef OutputIterator iter_type;
        <BR>
        
        <BR>
        <span lang="zxx">&#12288;</span>should be
        <BR>
        
        <BR>
        template &lt;class charT, <u>OutputIterator OutputIter</u>
        = ostreambuf_iterator&lt;charT&gt; &gt;
        <BR>
        class time_put : public locale::facet {
        <BR>
        public:
        <BR>
        typedef charT char_type;
        <BR>
        typedef <u>OutputIter</u> iter_type;
        <BR>
        
        <BR>
        
        <BR>
        22.2.5.4
        <BR>
        
        <BR>
        template &lt;class charT, class OutputIterator =
        ostreambuf_iterator&lt;charT&gt; &gt;
        <BR>
        class time_put_byname : public time_put&lt;charT,
        OutputIterator&gt;
        <BR>{
        <BR>
        public:
        <BR>
        typedef charT char_type;
        <BR>
        typedef OutputIterator iter_type;
        <BR>
        
        <BR>
        should be
        <BR>
        
        <BR>
        template &lt;class charT, <u>OutputIterator OutputIter</u>
        = ostreambuf_iterator&lt;charT&gt; &gt;
        <BR>
        class time_put_byname : public time_put&lt;charT,
        OutputIter&gt;
        <BR>{
        <BR>
        public:
        <BR>
        typedef charT char_type;
        <BR>typedef <u>OutputIter</u>
        iter_type;
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1083">1083</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP54">JP 54</A></TD>
<TD valign="top">
23

    &#182;
    
        2<sup>nd</sup> <font size="2" style="font-size: 11pt">para, Table 79</font>
&#160;
  </TD>
<TD valign="top">
        There is not &lt;forward_list&gt; in Table 79.
&#160;
  </TD>
<TD valign="top">
        Add
        &lt;forward_list&gt; between &lt;deque&gt; and
        &lt;list&gt;.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK221">UK 221</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/287">
     [287]
    </A></TD>
<TD valign="top">
23

    &#182;
    
Table 79
&#160;
  </TD>
<TD valign="top">
        The table is missing the new
        &lt;forward_list&gt; header.
&#160;
  </TD>
<TD valign="top">
        Add
        &lt;forward_list&gt; to the table for sequence containers.
        Alternative (technical) solution might be to merge
        &lt;forward_list&gt; into &lt;list&gt;.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK222">UK 222</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/295">
     [295]
    </A></TD>
<TD valign="top">
23
&#160;
  </TD>
<TD valign="top">
        It is not clear
        what purpose the Requirement tables serve in the Containers
        clause. Are they the definition of a library Container? Or
        simply a conventient shorthand to factor common semantics
        into a single place, simplifying the description of each
        subsequent container? This becomes an issue for
        'containers' like array, which does not meet the
        default-construct-to-empty requirement, or forward_list
        which does not support the size operation. Are these
        components no longer containers? Does that mean the
        remaining requirements don't apply? Or are these
        contradictions that need fixing, despite being a clear
        design decision?
&#160;
  </TD>
<TD valign="top">
        Clarify all the tables in 23.1 are there as
        a convenience for documentation, rather than a strict set
        of requirements. Containers should be allowed to relax
        specific requirements if they call attention to them in
        their documentation. The introductory text for array should
        be expanded to mention a default constructed array is not
        empty, and forward_list introduction should mention it does
        not provide the required size operation as it cannot be
        implemented efficiently.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1034">1034</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP55">JP 55</A></TD>
<TD valign="top">
23.1.1

    &#182;
    
        3<sup>rd</sup> <font size="2" style="font-size: 11pt">para, 4<sup>th</sup> line</font>
&#160;
  </TD>
<TD valign="top">
        It
        seems that &#8220;the MinimalAllocator concep&#8221; is the
        typo of &#8220;the MinimalAllocator concept&#8221;.
&#160;
  </TD>
<TD valign="top">
        Change to &#8230; models the MinimalAllocator
        concep<font color="#339966">t</font><font size="2" style="font-size: 11pt">.</font>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK223">UK 223</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/285">
     [285]
    </A></TD>
<TD valign="top">
23.1.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        The library does
        not define the MinimalAllocator or ScopedAllocator
        concepts, these were part of an earlier Allocators proposal
        that was rejected.
&#160;
  </TD>
<TD valign="top">
        Remove the references to MinimalAllocator
        and ScopedAllocator, or add definitions for these concepts
        to clause 20.7.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2900.html
<BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
     N2840</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK224">UK 224</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/298">
     [298]
    </A></TD>
<TD valign="top">
23.1.1

    &#182;
    
8
&#160;
  </TD>
<TD valign="top">
        This paragraph implicitly requires all
        containers in clause 23 to support allocators, which
        std::array does not.
&#160;
  </TD>
<TD valign="top">
        Add an 'unless
        otherwise specified' rider somewhere in p8, or move the
        whole array container from clause 23 [containers] to clause
        20 [utilies] to accompany bitset, pair and tuple.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
     N2840</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK225">UK 225</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/299">
     [299]
    </A></TD>
<TD valign="top">
23.1.1

    &#182;
    
Table 81
&#160;
  </TD>
<TD valign="top">
        Inconsistent
        words used to say the same thing. Table 80 describes
        iterator/const_iterator typedef as returning an "iterator
        type whose value type is T". Table 81 expresses the same
        idea as an "iterator type pointing to T". Express identical
        ideas with the same words to avoid accidentally introducing
        subtlety and confusion
&#160;
  </TD>
<TD valign="top">
        Change return types for
        X::(const)_reverse_iterator to say "iterator type whose
        value type is (const) T".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK226">UK 226</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/336">
     [336]
    </A></TD>
<TD valign="top">
23.1.1

    &#182;
    
10
&#160;
  </TD>
<TD valign="top">
        &lt;array&gt;
        must be added to this list. In particular it doesn't
        satisfy: - no swap() function invalidates any references,
        pointers, or iterators referring to the elements of the
        containers being swapped. and probably doesn't satisfy:
        &#8212; no swap() function throws an exception.
&#160;
  </TD>
<TD valign="top">
        If &lt;array&gt; remains a container, this
        will have to also reference array, which will then have to
        say which of these points it satisfies.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1035">1035</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus for change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK227">UK 227</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/146">
     [146]
    </A></TD>
<TD valign="top">
23.1.1

    &#182;
    
Table 80
&#160;
  </TD>
<TD valign="top">
        The post-condition for a = rv uses the word
        &#8220;construction&#8221; when it means
        &#8220;assignment&#8221;
&#160;
  </TD>
<TD valign="top">
        Replace the word
        &#8220;construction&#8221; with the word
        &#8220;assignment&#8221;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK228">UK 228</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/283">
     [283]
    </A></TD>
<TD valign="top">
23.1.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Line 4 contains
        a spelling mistake in the fragment "MinimalAllocator
        concep."
&#160;
  </TD>
<TD valign="top">
        Replace "concep" with "concept"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK229">UK 229</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/284">
     [284]
    </A></TD>
<TD valign="top">
23.1.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        The fragment "A container may directly call
        constructors" is not technically correct as constructors
        are not callable.
&#160;
  </TD>
<TD valign="top">
        Replace "A
        container may directly call constructors and destructors
        for its stored objects" with something similar to "A
        container may directly construct its stored objects and
        call destructors for its stored objects"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK230">UK 230</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/147">
     [147]
    </A></TD>
<TD valign="top">
23.1.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        &#8220;implementations shall consider the following
        functions to be const&#8221; - what does this mean? I don't
        understand what it means by implementations considering the
        functions to be const &#8211; surely they are either
        declared const or not?
&#160;
  </TD>
<TD valign="top">
        Clarify what is meant and what requirements
        an implementation must satisfy.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>After considerable discussion and 
    consideration, we do not feel this is a defect given the reference to [res.on.data.races].
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP56">JP 56</A></TD>
<TD valign="top">
23.1.3

    &#182;
    
12<sup>th</sup> <font size="2" style="font-size: 11pt">para, Table 84</font>
&#160;
  </TD>
<TD valign="top">
        `array&#8217; is unstated in Table 84 - Optional sequence
        container operations.
&#160;
  </TD>
<TD valign="top">
        Add
        `array&#8217; to Container field for the following
        Expression.
        <BR><BR>a.front()
        <BR><BR>a.back()
        <BR><BR>a[n]
        <BR><BR>a.at(n)
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK231">UK 231</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/300">
     [300]
    </A></TD>
<TD valign="top">
23.1.3

    &#182;
    
9-11
&#160;
  </TD>
<TD valign="top">
        These paragraphs
        are redundant now that Concepts define what it means to be
        an Iterator and guide overload resolution accordingly.
&#160;
  </TD>
<TD valign="top">
        Strike 23.1.3p9-11. Make sure
        std::basic_string has constraints similar to std::vector to
        meet this old guarantee.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1036">1036</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK232">UK 232</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/301">
     [301]
    </A></TD>
<TD valign="top">
23.1.3

    &#182;
    
Table 84
&#160;
  </TD>
<TD valign="top">
        match_results
        may follow the requirements but is not listed a general
        purpose library container.
&#160;
  </TD>
<TD valign="top">
        Remove reference to match_results against
        a[n] operation
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1037">1037</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK233">UK 233</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/302">
     [302]
    </A></TD>
<TD valign="top">
23.1.3

    &#182;
    
Table 84
&#160;
  </TD>
<TD valign="top">
        Add references to the new containers.
&#160;
  </TD>
<TD valign="top">
        Add reference to
        array to the rows for: a.front(), a. back(), a[n] a.at(n).
        Add reference to forward_list to the rows for: a.front(),
        a.emplace_front(args), a.push_front(t), a.push_front(rv),
        a.pop_front(). Add reference to basic_string to the row
        for: a.at(n).
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1038">1038</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK234">UK 234</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/346">
     [346]
    </A></TD>
<TD valign="top">
23.1.3

    &#182;
    
Table 84
&#160;
  </TD>
<TD valign="top">
        Ther reference
        to iterator in semantics for back should also allow for
        const_iterator when called on a const-qualified container.
        This would be ugly to specify in the 03 standard, but is
        quite easy with the addition of auto in this new standard.
&#160;
  </TD>
<TD valign="top">
        Replace iterator with auto in semantics for
        back: { auto tmp = a.end(); --tmp; return *tmp; }
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1039">1039</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK235">UK 235</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/148">
     [148]
    </A></TD>
<TD valign="top">
23.1.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        &#8220;The library provides three basic
        kinds of sequence containers: vector, list, and
        deque&#8221; - text appears to be out of date re addition
        of array and forward_list
&#160;
  </TD>
<TD valign="top">
        Change the text
        to read: &#8220;The library provides five basic kinds of
        sequence containers: array, deque, forward_list, list and
        vector&#8221;.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK236">UK 236</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/150">
     [150]
    </A></TD>
<TD valign="top">
23.1.3

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        [ I've moved (1)
        into a separate comment because I believe it is editorial
        in the simple sense, whereas (2) and (3) are not so
        straight forward ] (2) &#8220;vector is the type of
        sequence container that should be used by default&#8221; --
        As I understand it vector was considered first port of call
        because the things it has in common with the native array
        make programmers (especially those new to the container
        library) feel like they are on familiar territory. However,
        we now have the array container, so I think this should be
        recommended as the first port of call. (3) This paragraph
        is actually giving guidance on the use of the containers
        and should not be normative text
&#160;
  </TD>
<TD valign="top">
        Remove this paragraph
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Reworded the paragraph and its predecessor to reflect five basic
sequence containers.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK237">UK 237</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/334">
     [334]
    </A></TD>
<TD valign="top">
23.1.3

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        vector, list, and deque offer the
        programmer different complexity trade-offs and should be
        used accordingly - this ignores array and forward_list
&#160;
  </TD>
<TD valign="top">
        Modify the text
        to read: "array, deque, forward_list, list and vector offer
        the programmer different complexity trade-offs and should
        be used accordingly"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK238">UK 238</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/347">
     [347]
    </A></TD>
<TD valign="top">
23.1.4

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        Leaving it
        unspecified whether or not iterator and const_iterator are
        the same type is dangerous, as user code may or may not
        violate the One Definition Rule by providing overloads for
        both types. It is probably too late to specify a single
        behaviour, but implementors should document what to expect.
        Observing that problems can be avoided by users restricting
        themselves to using const_iterator, add a note to that
        effect.
&#160;
  </TD>
<TD valign="top">
        Change 'unspecified' to 'implementation
        defined'. Add "[Note: As itererator and const_iterator have
        identical semantics in this case, and iterator is
        convertible to const_iterator, users can avoid violating
        the One Definition Rule by always using const_iterator in
        their function parameter lists -- end note]
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1040">1040</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK239">UK 239</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/447">
     [447]
    </A></TD>
<TD valign="top">
23.1.4

    &#182;
    
85
&#160;
  </TD>
<TD valign="top">
        It is not possible to take a move-only key
        out of an unordered container, such as (multi)set or
        (multi)map, or the new hashed containers.
&#160;
  </TD>
<TD valign="top">
        Add below
        a.erase(q), a.extract(q), with the following notation:
        a.extract(q), Return type pair&lt;key, iterator&gt;
        Extracts the element pointed to by q and erases it from the
        set. Returns a pair containing the value pointed to by q
        and an iterator pointing to the element immediately
        following q prior to the element being erased. If no such
        element exists,returns a.end().
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1041">1041</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK240">UK 240</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/427">
     [427]
    </A></TD>
<TD valign="top">
23.1.6.1

    &#182;
    
12
&#160;
  </TD>
<TD valign="top">
        The axiom
        EmplacePushEquivalence should be asserting the stronger
        contract that emplace and insert return the same iterator
        value, not just iterators that dereference to the same
        value. This is a similar statement that is easier to
        express and should be equivalent - the idea that insert and
        emplace might return iterator values that do not compare
        equal but point to the same element should fail somewhere
        in the iterator concepts. Also, this axiom should be
        renamed to reflect its connection with insert, rather than
        push_front/push_back,
&#160;
  </TD>
<TD valign="top">
        Remove the * to deference the returned
        iterator either side of the == in the
        EmplacePushEquivalence axiom, rename the axiom
        EmplacementInsertionEquivalence : requires
        InsertionContainer&lt;C&gt; &amp;&amp;
        Constructible&lt;value_type, Args...&gt; axiom
        EmplacementInsertionEquivalence(C c, const_iterator
        position, Args... args) { emplace(c, position, args...) ==
        insert(c, position, value_type(args...)); }
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP57">JP 57</A></TD>
<TD valign="top">
23.1.6.3

    &#182;
    
        1<sup>st</sup> <font size="2" style="font-size: 11pt">para, 4<sup>th</sup> line</font>
&#160;
  </TD>
<TD valign="top">
        Typo, duplicated "to"
        <BR><BR>
        "<u>to to</u> model insertion container concepts."
&#160;
  </TD>
<TD valign="top">
        Remove one.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK241">UK 241</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/286">
     [286]
    </A></TD>
<TD valign="top">
23.2.1
&#160;
  </TD>
<TD valign="top">
        std::array does
        not have an allocator, so need to document an exception to
        the requirements of 23.1.1p3
&#160;
  </TD>
<TD valign="top">
        add exception to 23.1.1p3
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top"><BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">
     N2840</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK242">UK 242</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/355">
     [355]
    </A></TD>
<TD valign="top">
23.2.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        std:: qualification no longer needed for
        reverse_iterator.
&#160;
  </TD>
<TD valign="top">
        remove std::
        qualification from std::reverse_iterator&lt;iterator&gt;
        and std::reverse_iterator&lt;const_iterator&gt;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK243">UK 243</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/337">
     [337]
    </A></TD>
<TD valign="top">
23.2.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        Most containers,
        and types in general have 3 swaps: swap(T&amp;, T&amp;)
        swap(T&amp;&amp;, T&amp;) swap(T&amp;, T&amp;&amp;) But
        array only has swap(T&amp;, T&amp;).
&#160;
  </TD>
<TD valign="top">
        add the other two swaps.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>After discussing D2844, it was decided 
    to remove all the r-value-ref <code>swap</code> overloads from containers. 
    Therefore adding them to <code>array</code> has no benefit.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK244">UK 244</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/153">
     [153]
    </A></TD>
<TD valign="top">
23.2.1,
23.2.6

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The validity of
        the expression &amp;a[n] == &amp;a[0] + n is contingent on
        operator&amp; doing the &#8220;right thing&#8221; (as
        captured by the CopyConstructible requirements in table 30
        in C++2003). However this constraint has been lost in the
        Concepts of C++0x. This applies to vector and array (it
        actually applies to string also, but that's a different
        chapter, so I'll file a separate comment there and
        cross-reference).
&#160;
  </TD>
<TD valign="top">
        Define a ContiguousStrorage and apply it to
        vector,array and string. The Concept (supplied by Alisdair
        M) looks like this: Concept&lt; typename C &gt;
        ContiguousStrorage { requires Container&lt;C&gt;; typename
        value_type = C::value_type; value_type * data( C ); axiom
        Contiguous { C c; true = equal_ranges( data( c), data(c) +
        size(c), begin(c)); } };
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1042">1042</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
All concepts-related text has been removed from the draft. The problem was solved by removal of concepts. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK245">UK 245</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/358">
     [358]
    </A></TD>
<TD valign="top">
23.2.3

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The predicate types used in special member
        function of forward_list should be CopyConstructible, as
        per the algorithms of the same name. Note: an alternate
        solution would be to require these callable concepts to be
        CopyConstructible in clause 20, which would simplify the
        library specification in general. See earlier comment for
        details, that would render this one redundant.
&#160;
  </TD>
<TD valign="top">
        Add
        CopyConstructible requirement to the following signatures:
        template &lt;Predicate&lt;auto, T&gt; Pred&gt; requires
        CopyConstructible&lt;Pred&gt; void remove_if(Pred pred);
        template &lt;EquivalenceRelation&lt;auto, T&gt;
        BinaryPredicate&gt; requires
        CopyConstructible&lt;BinaryPredicate&gt; void
        unique(BinaryPredicate binary_pred); template
        &lt;StrictWeakOrder&lt;auto, T&gt; Compare&gt; requires
        CopyConstructible&lt;Compare&gt; void
        merge(forward_list&lt;T,Alloc&gt;&amp;&amp; x, Compare
        comp); template &lt;StrictWeakOrder&lt;auto, T&gt;
        Compare&gt; requires CopyConstructible&lt;Compare&gt; void
        sort(Compare comp);
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>UK245 with additional comments on <a href="#UK200">UK200</a> in clause 20: After further 
    discussion of UK200, we do not think adding constraints to predicates is a 
    good idea. Straw poll on 
    UK245: status quo, 5 pro - 0 con; add copy-constructible, 1 pro - 3 con; no 
    consensus for moving away from the status quo.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP58">JP 58</A></TD>
<TD valign="top">
23.2.3.2

    &#182;
    
        1<sup>st</sup> <font size="2" style="font-size: 11pt">line
        before 1<sup>st</sup> para</font>
&#160;
  </TD>
<TD valign="top">
        Unnecessary "{" exists before a word iterator like
        "{iterator before_begin()".
&#160;
  </TD>
<TD valign="top">
        Remove "{"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP59">JP 59</A></TD>
<TD valign="top">
23.2.4.4
&#160;
  </TD>
<TD valign="top">
        Types of the third and forth parameter of splice() are
        iterator at 23.2.4.4, though types of them are
        const_iterator at 23.2.4. (They are both const_iterator on
        N2350)
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR><BR>
        void splice(const_iterator position,
        list&lt;T,Allocator&gt;&amp;&amp; x, iterator i);
        <BR><BR>
        void splice(const_iterator position,
        list&lt;T,Allocator&gt;&amp;&amp; x,
        <BR><BR>
        iterator first, iterator last);
        <BR><BR>
        
        <BR><BR>
        should be
        <BR><BR>
        
        <BR><BR>
        void splice(const_iterator position,
        list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
        <BR><BR>
        void splice(const_iterator position,
        list&lt;T,Allocator&gt;&amp;&amp; x,
        <BR><BR>const_iterator
        first, const_iterator last);
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US83">US 83</A></TD>
<TD valign="top">
23.2.6.2

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
        "shrink_to_fint" should be "shrink_to_fit".
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK246">UK 246</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/350">
     [350]
    </A></TD>
<TD valign="top">
23.3.2.2
&#160;
  </TD>
<TD valign="top">
        The content of
        this sub-clause is purely trying to describe in words the
        effect of the requires clauses on these operations, now
        that we have Concepts. As such, the desctiption is more
        confusing than the signature itself. The semantic for these
        functions is adequately covered in the requirements tables
        in 23.1.4.
&#160;
  </TD>
<TD valign="top">
        Strike 23.3.2.2 entirely. (but do NOT
        strike these signatures from the class template
        definition!)
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1091">1091</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>This comment was submitted as editorial, but the project editor
has classified it as technical. Solved by removing concepts.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK247">UK 247</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/46">
     [46]
    </A></TD>
<TD valign="top">
24.1
&#160;
  </TD>
<TD valign="top">
        Iterator
        concepts are not extensive enough to merit a whole new
        header, and should be merged into &lt;concpts&gt;. This is
        particularly important for supporting the new for loop
        syntax which requires access to the Range concept. The
        required header to enable this syntax shoud have a simple
        name, like &lt;concepts&gt;, rather than something awkward
        to type like &lt;iterator_concepts&gt;.
&#160;
  </TD>
<TD valign="top">
        Move the concepts of
        &lt;iterator_concepts&gt; into the &lt;concepts&gt; header.
        We take no position on moving the text from Clause 24 to
        Clause 20 though.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>We believe the separate header to have value.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK248">UK 248</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/47">
     [47]
    </A></TD>
<TD valign="top">
24.1

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        The text "so for
        any iterator type there is an iterator value that points
        past the last element of a corresponding container" is
        slightly misleading. Iterators can refer into generalised
        ranges and sequences, not just containers. A broader term
        than 'container' should be used.
&#160;
  </TD>
<TD valign="top">
        Replace the reference to container with a
        more appropriate concept
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK250">UK 250</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/50">
     [50]
    </A></TD>
<TD valign="top">
24.1.1
&#160;
  </TD>
<TD valign="top">
        A default implementation should be supplied
        for the post-increment operator to simplify implementation
        of iterators by users.
&#160;
  </TD>
<TD valign="top">
        Copy the Effects clause into the concept
        description as the default implementation. Assumes a
        default value for postincrement_result
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1084">1084</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK251">UK 251</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/51">
     [51]
    </A></TD>
<TD valign="top">
24.1.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        The
        post-increment operator is dangerous for a general
        InputIterator. The multi-pass guarantees that make it
        meaningful are defined as part of the ForwardIterator
        refinement. Any change will affect only constrained
        templates that have not yet been written, so should not
        break existing user iterators which remain free to add
        these operations. This change will also affect the
        generalised OutputIterator, although there is no percieved
        need for the post-increment operator in this case either.
&#160;
  </TD>
<TD valign="top">
        Move declaration of postincrement operator
        and postincrement_result type from Interator concept to the
        ForwardIterator concept
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1009">1009</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Without concepts we do not feel that input iterator post increment is broken. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK252">UK 252</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/53">
     [53]
    </A></TD>
<TD valign="top">
24.1.2

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        istream_iterator is not a class, but a
        class template
&#160;
  </TD>
<TD valign="top">
        Change 'class' to 'class template' in the
        note.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK253">UK 253</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/54">
     [54]
    </A></TD>
<TD valign="top">
24.1.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        First sentance
        does not make gramatical sense, Seems to be missing the
        words 'if it' by comparison with similar sentance in other
        subsections
&#160;
  </TD>
<TD valign="top">
        Add the words 'if it' : "X satisfies the
        requirements of an output iterator IF IT meets the
        syntactic and semantic requirements"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK254">UK 254</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/55">
     [55]
    </A></TD>
<TD valign="top">
24.1.3

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
        This
        postcondition for pre-increment operator should be written
        as an axiom
&#160;
  </TD>
<TD valign="top">
        Move the postcondition into the concept
        definition as an axiom
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK255">UK 255</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/56">
     [56]
    </A></TD>
<TD valign="top">
24.1.4

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        This
        postcondition for pre-increment operator should be written
        as an axiom
&#160;
  </TD>
<TD valign="top">
        Move the postcondition into the concept
        definition as an axiom
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK256">UK 256</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/57">
     [57]
    </A></TD>
<TD valign="top">
24.1.5

    &#182;
    
3, 4, 5
&#160;
  </TD>
<TD valign="top">
        The relationship between pre- and post-
        decrement should be expressed as an axiom.
&#160;
  </TD>
<TD valign="top">
        Move the text
        specification of pre/post-conditions and behaviour into an
        axiom within the BidirectionalIterator concept
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK257">UK 257</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/58">
     [58]
    </A></TD>
<TD valign="top">
24.1.5
&#160;
  </TD>
<TD valign="top">
        There is a
        reasonable default for postdecrement_result type, which is
        X. X is required to be regular, therefore CopyConstructible
        and a valid ResultType. Together with the next comment this
        simplifies user defined iterator implentations
&#160;
  </TD>
<TD valign="top">
        Add the default : typename
        postincrement_result = X;
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>postdecrement_result is deduced.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK258">UK 258</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/50">
     [50]
    </A></TD>
<TD valign="top">
24.1.5
&#160;
  </TD>
<TD valign="top">
        A default
        implementation should be supplied for the post-decrement
        operator to simplify implementation of iterators by users.
&#160;
  </TD>
<TD valign="top">
        Copy the Effects clause into the concept
        description as the default implementation. Assumes a
        default value for postincrement_result
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1085">1085</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK259">UK 259</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/60">
     [60]
    </A></TD>
<TD valign="top">
24.1.5
&#160;
  </TD>
<TD valign="top">
        postdecrement_result is effectively returning a copy of the
        original iterator value, so should have similar
        constraints, rather than just HasDereference. If Concepts
        do not support this circularity of definition suggest that
        concepts feature may want a little more work
&#160;
  </TD>
<TD valign="top">
        Add the requirement: requires Iterator&lt;
        postdecrement_result &gt;;
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Rejected, unless Alisdair comes back with more motivation.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK260">UK 260</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/61">
     [61]
    </A></TD>
<TD valign="top">
24.1.5

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        The effects clause for post-decrement
        iterator should be available as an axiom and a default
        implementation, where the compiler can make better use of
        it.
&#160;
  </TD>
<TD valign="top">
        Move the Effects
        clause into the BidirectionalIterator concept definition as
        an axiom, and as the default implementation for the
        operation.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK249">UK 249</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/64">
     [64]
    </A></TD>
<TD valign="top">
24.1.6

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        The semantic for
        operator+= should also be provided as a default
        implementation to simplify implementation of user-defined
        iterators
&#160;
  </TD>
<TD valign="top">
        Copy the text from the effects clause into
        the RandomAccessIterator concept as the default
        implementaiton.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Violates complexity requirements.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK261">UK 261</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/62">
     [62]
    </A></TD>
<TD valign="top">
24.1.6
&#160;
  </TD>
<TD valign="top">
        To simplify user
        defined random access iterator types, the
        subscript_reference type should default to reference
&#160;
  </TD>
<TD valign="top">
        typename subscript_reference = reference;
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Subscript reference isn't used.<BR><BR>
In c++std-lib-23104, Daniel Kr&#252;gler commented, &#8220;this
[proposed change] would disable "auto-deduction" of the return
type of any operator[] as described by
[concept.map.assoc]/4+5.&#8221;
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK262">UK 262</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/65">
     [65]
    </A></TD>
<TD valign="top">
24.1.6

    &#182;
    
3, 4
&#160;
  </TD>
<TD valign="top">
        Effects and post-conditions for operator+
        are more useful if expressed as axioms, and supplied as
        default implementations.
&#160;
  </TD>
<TD valign="top">
        Move the effects
        and Postcondition definitions into the RandomAccessIterator
        concept and copy the code in the specification as the
        default implementation of these operations.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top"><BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK263">UK 263</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/66">
     [66]
    </A></TD>
<TD valign="top">
24.1.6

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
        This requirement on operator-= would be
        better expressed as a default implementation in the
        concept, with a matching axiom
&#160;
  </TD>
<TD valign="top">
        Move the
        specification for operator-= from the returns clause into
        an axiom and default implementation within the
        RandomAccessIterator concept
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1010">1010</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK264">UK 264</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/67">
     [67]
    </A></TD>
<TD valign="top">
24.1.6

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        Effects clauses are better expressed as
        axioms where possible.
&#160;
  </TD>
<TD valign="top">
        Move code in
        operator- effects clause into RandomAccessIterator concept
        as both a default implementation and an axiom
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top"><BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK265">UK 265</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/68">
     [68]
    </A></TD>
<TD valign="top">
24.1.6

    &#182;
    
8
&#160;
  </TD>
<TD valign="top">
        This effects
        clause is nonesense. It looks more like an axiom stating
        equivalence, and certainly an effects clause cannot change
        the state of two arguments passed by const reference
&#160;
  </TD>
<TD valign="top">
        Strike the Effects clause
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1079">1079</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK266">UK 266</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/69">
     [69]
    </A></TD>
<TD valign="top">
24.1.6

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
        This sentance should be provided as a
        default definition, along with a matching axiom
&#160;
  </TD>
<TD valign="top">
        Move the Returns
        clause into the spefication for RandomAccessIterator
        operator- as a default implementation. Move the Effects
        clause as the matching axiom.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top"><BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK267">UK 267</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/70">
     [70]
    </A></TD>
<TD valign="top">
24.1.6

    &#182;
    
24.1.6
&#160;
  </TD>
<TD valign="top">
        The code in the
        Requires clause for RandomAccessIterator operator[] would
        be better expressed as an axiom.
&#160;
  </TD>
<TD valign="top">
        Rewrite the Requires clause as an axiom in
        the RandomAccessIterator concept
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK268">UK 268</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/71">
     [71]
    </A></TD>
<TD valign="top">
24.1.6

    &#182;
    
12
&#160;
  </TD>
<TD valign="top">
        This note is
        potentialy confusing as __far enters the syntax as a clear
        language extension, but the note treats it as a regular
        part of the grammar. It might be better expressed using
        attributes in the current wording.
&#160;
  </TD>
<TD valign="top">
        Clean up the note to either avoid using
        language extension, or spell out this is a constraint to
        support extensions.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP60">JP 60</A></TD>
<TD valign="top">
24.1.8

    &#182;
    
1<sup>st</sup> <font size="2" style="font-size: 11pt">para</font>
&#160;
  </TD>
<TD valign="top">
        Capability of an iterator is too much restricted by
        concept.
        <BR>
        
        <BR>
        Concept of std::Range is defined as:
        <BR>
        
        <BR>
        concept Range&lt;typename T&gt; {
        <BR>
        InputIterator iterator;
        <BR>
        iterator begin(T&amp;);
        <BR>
        iterator end(T&amp;);
        <BR>}
        <BR>
        
        <BR>So
        the following code generates an error.
        <BR>
        
        <BR>
        template &lt;std::Range Rng&gt;
        <BR>
        void sort(Rng&amp; r)
        <BR>{
        <BR>
        // error! Rng::iterator does not satisfy requirements of a
        random
        <BR>
        // access iterator.
        <BR>
        std::sort(begin(r), end(r));
        <BR>}
        <BR>
        
        <BR>
        std::vector&lt;int&gt; v; // vector::iterator is a random
        access iterator.
        <BR>
        sort(v);
        <BR>
        
        <BR>
        This is because the concept of an iterator of std::Range is
        InputIterator. For this reason, a random access iterator
        loses its capability when passed to a std::Range parameter.
        <BR>
        
        <BR>To
        be able to work the above code, we need to write as
        follows:
        <BR>
        
        <BR>
        template &lt;std::Range T&gt;
        <BR>
        requires std::RandomAccessIterator&lt;T::iterator&gt;
        &amp;&amp;
        <BR>
        std::ShuffleIterator&lt;T::iterator&gt; &amp;&amp;
        <BR>
        std::LessThanComparable&lt;T::iterator::value_type&gt;
        <BR>
        void sort(T&amp; r)
        <BR>{
        <BR>
        sort(begin(r), end(r));
        <BR>}
        <BR>
        
        <BR>
        std::vector&lt;int&gt; v;
        <BR>
        sort(v);
        <BR>
        
        <BR>It
        needs quiet a few amount of codes like this only to recover
        random access capability from InputIterator concept.
        <BR>
        
        <BR>We
        can write the following valid code with Boost.Range, which
        is implemented with using C++03 SFINAE.
        <BR>
        
        <BR>
        template &lt;class Range&gt;
        <BR>
        void sort(Range&amp; r)
        <BR>{
        <BR>
        std::sort(boost::begin(r), boost::end(r));
        <BR>}
        <BR>
        
        <BR>
        std::vector&lt;int&gt; v;
        <BR>
        sort(v); // OK
        <BR>
        
        <BR>One of the
        motivation to introduce concepts are supporting template
        programming techniques by language directly to eliminate
        hacky techniques such as tag-dispatch, SFINAE and Type
        Traints. But SFINAE will be kept using because it needs
        quite a few amount of codes without using SFAINAE.
&#160;
  </TD>
<TD valign="top">
        Add
        InputRange, OutputRange, ForwardRange, BidirectionalRange
        and RandomAccessRange.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Beyond the scope of the Standard for C++0x because we are not 
supplying range-based algorithms.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK269">UK 269</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/16">
     [16]
    </A></TD>
<TD valign="top">
24.3

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        'decrements for
        negative n' seems to imply a negative number of decrement
        operations, which is odd.
&#160;
  </TD>
<TD valign="top">
        Need simple, clearer wording
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK270">UK 270</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/17">
     [17]
    </A></TD>
<TD valign="top">
24.3

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        The reachability
        constraint in p5 means that a negavite result, implying
        decrements operations in p4, is not possible
&#160;
  </TD>
<TD valign="top">
        Split the two overloads into separate
        descriptions, where reachability is permitted to be in
        either direction for RandomAccessIterator
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#940">940</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK271">UK 271</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/145">
     [145]
    </A></TD>
<TD valign="top">
24.3

    &#182;
    
6,7
&#160;
  </TD>
<TD valign="top">
        next/prev return
        an incremented iterator without changing the value of the
        original iterator. However, even this may invalidate an
        InputIterator. A ForwardIterator is required to guarantee
        the 'multipass' property.
&#160;
  </TD>
<TD valign="top">
        Replace InputIterator constraint with
        FOrwardIterator in next and prev function templates.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1011">1011</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK272">UK 272</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/159">
     [159]
    </A></TD>
<TD valign="top">
24.4
&#160;
  </TD>
<TD valign="top">
        reverse_iterator
        and move_iterator use different formulations for their
        comparison operations. move_iterator merely requires the
        minimal set of operations, &lt; and ==, from its underlying
        iterator and synthesizes all oprations from these two.
        reverse_iterator relies on the undelying iterator to
        support all comparision operations directly. In practice,
        move_iterator can only be implemented this way as it must
        support iterator types that are merely InputIterators, and
        so SemiRegular and not Regular. However, reserse_iterator
        has an existing specification and any change of semantic
        could change behaviour of conforming programs today -
        although an iterator that yields different results for (a
        &gt; b) than (b &lt; a) may fall foul of some semantic
        consistency requirements, even if the syntax is met.
&#160;
  </TD>
<TD valign="top">
        Rephrase the reverse_iterator comparison
        operations using only operators &lt; and ==, as per the
        move_iterator specification.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK274">UK 274</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/119">
     [119]
    </A></TD>
<TD valign="top">
24.4, 24.5
&#160;
  </TD>
<TD valign="top">
        The subclauses
        for standard iterator adaptors could be better organised.
        There are essentially 3 kinds of iterator wrappers
        provided, stream iterators adapt streams and get their own
        subsection. insert iterators adapt containers, and get
        their own subsection but it is inserted into the middle of
        24.4 Predifined iterators. reverse_iterator and
        move_iterator adpat other iterators, but their presentation
        is split by insert iterators
&#160;
  </TD>
<TD valign="top">
        Promote 24.4.2 [insert.iterators] up one
        level to 24.6. Emphasize that insert iterators adapt
        containers Retarget 24.4 [predef.iterators] as iterator
        adapters for iterator templates that wrap other iterators.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK275">UK 275</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/18">
     [18]
    </A></TD>
<TD valign="top">
24.4.1.1
&#160;
  </TD>
<TD valign="top">
        The constructor
        template taking a single Iterator argument will be selected
        for Copy Initialization instead of the non-template
        constructor taking a single Iterator argument selected by
        Direct Initialization.
&#160;
  </TD>
<TD valign="top">
        The reverse_iterator template constructor
        taking a single Iterator argument should be explicit.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Withdrawn by submitter.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK276">UK 276</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/19">
     [19]
    </A></TD>
<TD valign="top">
24.4.1.1
&#160;
  </TD>
<TD valign="top">
        It is odd to
        have a mix of declaration stlyes for operator+ overloads.
        Prefer if either all are member functions, or all are
        'free' functions.
&#160;
  </TD>
<TD valign="top">
        Make the member operators taking a
        difference_type argument non-member operators
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Not editorial, withdrawn by submitter.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK277">UK 277</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/20">
     [20]
    </A></TD>
<TD valign="top">
24.4.1.2.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The default
        constructor default-initializes current, rather than
        value-initializes. This means that when Iterator
        corresponds to a trivial type, the current member is left
        un-initialized, even when the user explictly requests value
        intialization! At this point, it is not safe to perform any
        operations on the reverse_iterator other than assign it a
        new value or destroy it. Note that this does correspond to
        the basic definition of a singular iterator.
&#160;
  </TD>
<TD valign="top">
        i/ Specify value initialization rather than
        default intialization or ii/ specify = default; rather than
        spell out the semantic. This will at least allow users to
        select value initialization and copy the iterator value. or
        iii/ Add a note to the description emphasizing the singular
        nature of a value-initialized reserve iterator.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1012">1012</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK278">UK 278</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/21">
     [21]
    </A></TD>
<TD valign="top">
24.4.1.2.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        There is an
        inconsistency between the constructor taking an iterator
        and the constructor template taking a reverse_iterator
        where one passes by value, and the other by const
        reference. The by-value form is preferred as it allows for
        efficient moving when copy elision fails to kick in.
&#160;
  </TD>
<TD valign="top">
        Change the const reverse_iterator&lt;U&gt;
        &amp; parameter to pass-by-value
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>We don't believe that copy elision is a 
sufficiently high priority for iterator types.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK279">UK 279</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/24">
     [24]
    </A></TD>
<TD valign="top">
24.4.1.2.12,
        24.4.3.2.12
&#160;
  </TD>
<TD valign="top">
        The reason the
        return type became unspecified is LWG issue 386. This
        reasoning no longer applies as there are at least two ways
        to get the right return type with the new language
        facilities added since the previous standard.
&#160;
  </TD>
<TD valign="top">
        Specify the return type using either
        decltype or the Iter concept map
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1051">1051</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Without concepts we can no longer restrict this member in a trivial way.&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK280">UK 280</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/22">
     [22]
    </A></TD>
<TD valign="top">
24.4.1.2.4
&#160;
  </TD>
<TD valign="top">
        The presence of
        the second iterator value is surprising for many readers
        who underestimate the size of a reverse_iterator object.
        Adding the exposition only member that is required by the
        semantic will reduce confusion.
&#160;
  </TD>
<TD valign="top">
        Add reverse_iterator expsoition only member
        tmp as a comment to class declaration, as a private member
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK281">UK 281</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/23">
     [23]
    </A></TD>
<TD valign="top">
24.4.1.2.5
&#160;
  </TD>
<TD valign="top">
        The current
        specification for return value will always be a true
        pointer type, but reverse_iterator supports proxy iterators
        where the pointer type may be some kind of 'smart pointer'
&#160;
  </TD>
<TD valign="top">
        Replace the existing returns specification
        with a copy of the operator* specification that returns
        this-&gt;tmp.operator-&gt;
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1052">1052</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK282">UK 282</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/5">
     [5]
    </A></TD>
<TD valign="top">
24.4.2.1,
        24.4.2.2.2,
        24.4.2.3,
        24.4.2.4.2,
        24.4.2.5,
        24.4.2.6.2

    &#182;
    
n/a
&#160;
  </TD>
<TD valign="top">
        Insert iterators of move-only types will
        move from lvalues
&#160;
  </TD>
<TD valign="top">
        Add an additional constrained overload for
        operator= that requires
        !CopyConstructible&lt;Cont::value_type&gt; and mark it
        =delete.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#901">901</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>Both comment and issue have been resolved by the adoption of N2844 (rvalue references safety fix).
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK283">UK 283</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/156">
     [156]
    </A></TD>
<TD valign="top">
24.4.2.5,
        24.4.2.6.4
&#160;
  </TD>
<TD valign="top">
        postincrement operator overloads
        traditionally return by value - insert_iterator is declared
        as return by reference. The change is harmless in this
        case, but either front/back_insert_iterator should take the
        matching change for consistency, or this function should
        return-by-value
&#160;
  </TD>
<TD valign="top">
        change operator++(int) overload to return
        by value, not reference. Affects both class summary and
        operator definition in p
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>This is compatible with C++03; and we lack a 
consensus for change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP61">JP 61</A></TD>
<TD valign="top">
24.4.3.2.1

    &#182;
    
2<sup>nd</sup> <font size="2" style="font-size: 11pt">para, 1<sup>st</sup>
        line</font>
&#160;
  </TD>
<TD valign="top">
        Typo.
        <BR><BR>
        "intializing" should be "in<u>i</u>tializing"
&#160;
  </TD>
<TD valign="top">
        Add
        "i"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK284">UK 284</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/26">
     [26]
    </A></TD>
<TD valign="top">
24.5
&#160;
  </TD>
<TD valign="top">
        The stream
        iterators need constraining with concepts/requrires
        clauses.
&#160;
  </TD>
<TD valign="top">
        Provide constraints
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1086">1086</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK285">UK 285</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/27">
     [27]
    </A></TD>
<TD valign="top">
24.5.1

    &#182;
    
1,2
&#160;
  </TD>
<TD valign="top">
        Much of the
        content of p1 and the whole of p2 is a redundant
        redefinition of InputIterator. It should be simplified
&#160;
  </TD>
<TD valign="top">
        Strike p2. Simplify p1 and add a
        cross-reference to the definition of InputIterator concept.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK286">UK 286</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/28">
     [28]
    </A></TD>
<TD valign="top">
24.5.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        To the casual
        reader it is not clear if it is intended to be able to
        assign to istream_iterator objects. Specifying the copy
        constructor but relying on the implicit copy-assign
        operator is confusing.
&#160;
  </TD>
<TD valign="top">
        Either provide a similar definition to the
        copy-assign operator as for the copy constructor, or strike
        the copy constructor
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK287">UK 287</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/25">
     [25]
    </A></TD>
<TD valign="top">
24.5.1.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        It is not clear
        what the intial state of an istream_iterator should be. Is
        _value_ initialized by reading the stream, or default/value
        initialized? If it is initialized by reading the stream,
        what happens if the initialization is deferred until first
        dereference, when ideally the iterator value should have
        been that of an end-of-stream iterator which is not safely
        dereferencable?
&#160;
  </TD>
<TD valign="top">
        Specify _value_ is initialized by reading
        the stream, or the iterator takes on the end-of-stream
        value if the stream is empty
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#788">788</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK288">UK 288</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/29">
     [29]
    </A></TD>
<TD valign="top">
24.5.1.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        The provided specification is vacuous,
        offering no useful information.
&#160;
  </TD>
<TD valign="top">
        Either strike
        the specification of the copy constructor, or simply
        replace it with an = default definition.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK289">UK 289</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/30">
     [30]
    </A></TD>
<TD valign="top">
24.5.1.2

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        It is very hard
        to pick up the correct specification for
        istream_iterator::operator== as the complete specification
        requires reading two quite disconnected paragraphs,
        24.5.1p3, and 24.5.1.2p6. Reading just the specifaction of
        the operation itself suggests that end-of-stream iterators
        are indistinguishable from 'valid' stream iterators, which
        is a very dangerous misreading.
&#160;
  </TD>
<TD valign="top">
        Merge 24.5.1p3, equality comparison of
        end-of-stream-iterators, into 24.5.1.2p6, the specification
        of the equality operator for istream_iterator.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK290">UK 290</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/160">
     [160]
    </A></TD>
<TD valign="top">
24.5.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The character
        type of a string delimiter for an ostream_iterator should
        be const charT *, the type of the elements, not char *, a
        narrow character string.
&#160;
  </TD>
<TD valign="top">
        Replace char * with const charT *
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK291">UK 291</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/161">
     [161]
    </A></TD>
<TD valign="top">
24.5.2.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        ostream_iterator
        postincrement operator returns by reference rather than by
        value. This may be a small efficiency gain, but it is
        otherwise unconventional. Prefer return-by-value.
&#160;
  </TD>
<TD valign="top">
        ostream_iterator operator++(int);
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>This is compatible with C++03; and we lack a 
consensus for change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR34">FR 34</A></TD>
<TD valign="top">
24.5.3
        [istreambuf.
        iterator]
&#160;
  </TD>
<TD valign="top">
        There are two public
        sections, and the content of the second one is indented
        with respect to the first. I don't it should be.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK292">UK 292</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/163">
     [163]
    </A></TD>
<TD valign="top">
24.5.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        Prefer the use
        of the new nullptr constant to the zero literal when using
        a null pointer in text.
&#160;
  </TD>
<TD valign="top">
        Change istreambuf_iterator(0) to
        istreambuf_iterator(nullptr)
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK293">UK 293</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/164">
     [164]
    </A></TD>
<TD valign="top">
24.5.3

    &#182;
    
2,3,4
&#160;
  </TD>
<TD valign="top">
        The listed paragraphs redundantly redefine
        an input iterator, and redundancy can be a dangerous thing
        in a specification. Suggest a simpler phrasing below.
&#160;
  </TD>
<TD valign="top">
        2. The result of
        operator*() on an end of stream is undefined. For any other
        iterator value a char_type value is returned. 3. Two end of
        stream iterators are always equal. An end of stream
        iterator is not equal to a non-end of stream iterator. 4.
        As istreambuf_iterator() is an InputIterator but not a
        ForwardIterator, istreambuf_iterators object can be used
        only for one-pass algorithms. It is not possible to assign
        a character via an input iterator.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK294">UK 294</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/166">
     [166]
    </A></TD>
<TD valign="top">
24.5.3.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        Implicit converting constructors can be
        invoked at surprising times, so there should always be a
        good reason for declaring one.
&#160;
  </TD>
<TD valign="top">
        Mark the two
        single-argument constructors take a stream or stream buffer
        as explicit. The proxy constructor should remain implicit.
        explicit
        istreambuf_iterator(basic_istream&lt;charT,traits&gt;&amp;
        s) throw(); explicit
        istreambuf_iterator(basic_streambuf&lt;charT,traits&gt;* s)
        throw();
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK295">UK 295</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/173">
     [173]
    </A></TD>
<TD valign="top">
25
&#160;
  </TD>
<TD valign="top">
        THere is a level
        of redundancy in the library specification for many
        algorithms that can be eliminated with the combination of
        concepts and default parameters for function templates.
        Eliminating redundancy simplified specification and reduces
        the risk of inttroducing accidental inconsistencies.
&#160;
  </TD>
<TD valign="top">
        Adopt n2743, or an update of that paper.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1053">1053</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Too inventive, too late, would really need a paper.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP62">JP 62</A></TD>
<TD valign="top">
25, 25.3.1.5,
        26.3.6.5
&#160;
  </TD>
<TD valign="top">
        The return types of is_sorted_until function and
        is_heap_until function are iterator. But basically, the
        return type of is_xxx function is bool. And the return type
        of lower_bound function and upper_bound is iterator.
        <BR><BR>
        So we think that it is reasonable to change those two
        functions.
&#160;
  </TD>
<TD valign="top">
        Change "is_sorted_until" to "sorted_bound"
        <BR><BR>
        Change "is_heap" to "heap_bound"
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to make the change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK296">UK 296</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/183">
     [183]
    </A></TD>
<TD valign="top">
25.1.8

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The 'Returns' of
        adjacent_find requires only HasEqualTo, or a Predicate.
        Requiring EqualityComparable or EquivalenceRelation seems
        too strong and not useful.
&#160;
  </TD>
<TD valign="top">
        Change EqualityComparable to HasEqualTo and
        EquivalnceRelation to Predicate
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to make the change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK297">UK 297</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/185">
     [185]
    </A></TD>
<TD valign="top">
25.2.11

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        The definition
        of rotate_copy is very complicated. It is equivalent to:
        return copy(first, middle, copy(middle, last, result));
&#160;
  </TD>
<TD valign="top">
        Change 'effects' to, returns, requires,
        complexity to: effects: equivalent to: return copy(first,
        middle, copy(middle, last, result));
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK298">UK 298</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/186">
     [186]
    </A></TD>
<TD valign="top">
25.2.13

    &#182;
    
13
&#160;
  </TD>
<TD valign="top">
        partition_point requires a partitioned
        array
&#160;
  </TD>
<TD valign="top">
        requires: is_partitioned(first, last, pred)
        != false;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK299">UK 299</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/352">
     [352]
    </A></TD>
<TD valign="top">
25.2.2
&#160;
  </TD>
<TD valign="top">
        Should be consistent in style use of
        concepts in template parameter lists. The
        auto-OutputIterator sytle used in std::copy is probably
        preferred.
&#160;
  </TD>
<TD valign="top">
        Change way signature is declared:
        template&lt;InputIterator InIter, OutputIterator&lt;auto,
        RvalueOf&lt;InIter::reference&gt;::type&gt; OutIter&gt;
        OutIter move(InIter first, InIter last, OutIter result);
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK300">UK 300</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/351">
     [351]
    </A></TD>
<TD valign="top">
25.2.3
&#160;
  </TD>
<TD valign="top">
        Since publishing
        the original standard, we have learned that swap is a
        fundamental operation, and several common idioms rely on it
        - especially those related to exception safety. As such it
        belongs in the common &lt;utility&gt; header rather than
        the broader &lt;algorithm&gt; header, and likewise should
        move to clause 20. For backwards compatiblility the
        algorithm header should be required to #include
        &lt;utility&gt;, which would be covered in the resolution
        of LWG issue 343. There are already dependencies in
        &lt;algorithm&gt; on types declared in this header, so this
        comment does not create a new dependency.
&#160;
  </TD>
<TD valign="top">
        Move primary swap template from
        &lt;algorithm&gt; into &lt;utility&gt;. Move 25.2.3 to
        somewhere under 20.2. Require &lt;algorithm&gt; to #include
        &lt;utility&gt; to access pair and provide legacy support
        for finding swap.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK301">UK 301</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/184">
     [184]
    </A></TD>
<TD valign="top">
25.2.5
&#160;
  </TD>
<TD valign="top">
        replace and
        replace_if have the requirement: OutputIterator&lt;Iter,
        Iter::reference&gt; Which implies they need to copy some
        values in the range the algorithm is iterating over. This
        is not however the case, the only thing that happens is
        const T&amp;s might be copied over existing elements (hence
        the OutputIterator&lt;Iter, const T&amp;&gt;
&#160;
  </TD>
<TD valign="top">
        Remove OutputIterator&lt;Iter,
        Iter::reference&gt; from replace and replace_if
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1087">1087</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK302">UK 302</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/187">
     [187]
    </A></TD>
<TD valign="top">
25.3

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
        the concept
        StrictWeakOrder covers the definition of a strict weak
        ordering, described in paragraph 4.
&#160;
  </TD>
<TD valign="top">
        Remove 4, and mention StrictWeakOrder in
        paragraph 1.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There are at least a dozen places in the standard that refer to this
definition of strict weak ordering.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK303">UK 303</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/188">
     [188]
    </A></TD>
<TD valign="top">
25.3

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
        This paragraph just describes
        is_partitioned
&#160;
  </TD>
<TD valign="top">
        6 A sequence
        [start,finish) is partitioned with respect to an expression
        f(e) if is_partitioned(start, finish, e) != false
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The paragraph describes something different. is_partitioned takes a
predicate; "partitioned with respect to an expression" deals with an
expression. While it's possible to wrap an expresion in a predicate,
that would result in a circumlocution in the places where "partitioned
with respect to an expression" is used.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK304">UK 304</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/189">
     [189]
    </A></TD>
<TD valign="top">
25.3.6
&#160;
  </TD>
<TD valign="top">
        The requires
        clauses of push_heap, pop_heap and make_heap are
        inconsistently formatted, dispite being identical
&#160;
  </TD>
<TD valign="top">
        Format them identically.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Seems to be a comment about an earlier version. In N2800 the requires
clauses of push_heap and pop_heap are similar, and are formatted the
same. make_heap has no requires clause.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK305">UK 305</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/335">
     [335]
    </A></TD>
<TD valign="top">
25.3.7

    &#182;
    
1, 9, 17
&#160;
  </TD>
<TD valign="top">
        The negative requirement on IsSameType is a
        hold-over from an earlier draught with a variadic template
        form of min/max algorith. It is no longer necessary.
&#160;
  </TD>
<TD valign="top">
        Strike the !IsSameType&lt;T, Compare&gt;
        constraint on min/max/minmax algorithms
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1013">1013</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US84">US 84</A></TD>
<TD valign="top">
26
&#160;
  </TD>
<TD valign="top">
        Parts of the numerics chapter are not concept enabled.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1140">1140</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR35">FR 35</A></TD>
<TD valign="top">
26.3
        [Complex
numbers]
&#160;
  </TD>
<TD valign="top">
        Instantiations of the class
        template complex&lt;&gt; have to be allowed for integral
        types, to reflect existing practice and ISO standards
        (LIA-III).
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1154">1154</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK306">UK 306</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/113">
     [113]
    </A></TD>
<TD valign="top">
26.4
&#160;
  </TD>
<TD valign="top">
        Random number
        library component cannot be used in constrained templates
&#160;
  </TD>
<TD valign="top">
        Provide constraints for the random number
        library
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#N/A">N/A</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
     N2836</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP63">JP 63</A></TD>
<TD valign="top">
26.4.8.5.1
&#160;
  </TD>
<TD valign="top">
        No
        constructor of discrete_distribution that accepts
        initializer_list.
        <BR><BR>
        discrete_distribution initialize distribution by a given
        range (iterators), but temporary variable of a container or
        an array is needed in the following case.
        <BR><BR>
        
        <BR><BR>int
        ar[] = {1, 2, 3};
        <BR><BR>
        discrete_distribution&lt;&gt; dist(ar, ar+3);
        <BR><BR>
        
        <BR><BR>Other libraries
        also accept initializer_list, so change
        discrete_distribution library to accept initializer_list
        too.
        <BR><BR>
&#160;
  </TD>
<TD valign="top">
        Add
        the following constructer.
        <BR><BR>
        <u>discrete_distribution(initializer_list&lt;result_type&gt;);</u>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#874">874</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">
     N2836</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP64">JP 64</A></TD>
<TD valign="top">
26.5.2
&#160;
  </TD>
<TD valign="top">
        &#8220;valarray&lt;T&gt;&amp; operator+=
        (initializer_list&lt;T&gt;);&#8221; is not defined.
&#160;
  </TD>
<TD valign="top">
        Add
        valarray&lt;T&gt;&amp; operator+=
        (initializer_list&lt;T&gt;);
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1243">1243</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Request has been withdrawn by NB. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK307">UK 307</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/394">
     [394]
    </A></TD>
<TD valign="top">
26.7

    &#182;
    
Footnote 288
&#160;
  </TD>
<TD valign="top">
        The footnote
        refers to TR1, which is not a defined term in this
        standard. Drop the reference to TR1, those templates are a
        regular part of the standard now and how they were
        introduced is no longer relevant.
&#160;
  </TD>
<TD valign="top">
        Drop the reference to TR1.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US85">US 85</A></TD>
<TD valign="top">
27
&#160;
  </TD>
<TD valign="top">
        The
        input/output chapter is not concept enabled.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1141">1141</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK308">UK 308</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/114">
     [114]
    </A></TD>
<TD valign="top">
27
&#160;
  </TD>
<TD valign="top">
        <span lang="en-US">iostreams library cannot be used from
        constrained templates</span>
&#160;
  </TD>
<TD valign="top">
        Provide constraints for the iostreams
        library, clause 27
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1141">1141</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP65">JP 65</A></TD>
<TD valign="top">
27.4.4
&#160;
  </TD>
<TD valign="top">
        Switch from
        &#8220;unspecified-bool-type&#8221; to<span lang="zxx">&#12288;&#8220;</span>explicit operator bool()
        const&#8221;.
&#160;
  </TD>
<TD valign="top">
        Replace "operator <i>unspecified-bool-type</i>() const;"
        with "explicit operator bool() const;"
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1094">1094</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP66">JP 66</A></TD>
<TD valign="top">
27.4.4.3

    &#182;
    
1<sup>st</sup> <font size="2" style="font-size: 11pt">para</font>
&#160;
  </TD>
<TD valign="top">
        Switch from
        &#8220;unspecified-bool-type&#8221; to<span lang="zxx">&#12288;&#8220;</span>explicit operator bool()
        const&#8221;
&#160;
  </TD>
<TD valign="top">
        Replace "operator <i>unspecified-bool-type</i>() const;"
        with "explicit operator bool() const;"
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1094">1094</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR36">FR 36</A></TD>
<TD valign="top">
27.6.1.2.2
[istream.
        formatted.
        arithmetic]

    &#182;
    
1, 2, and 3
&#160;
  </TD>
<TD valign="top">
        iostate err = 0;
        <BR><BR>
        <BR><BR>iostate is a bitmask type and
        so could be an enumeration. Probably using
        <BR><BR>goodbit is the solution.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR37">FR 37</A></TD>
<TD valign="top">
27.6.1.2.2
[istream.
        formatted.
        arithmetic]

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        else if (lval &lt;
        numeric_limits&lt;int&gt;::min()
        <BR><BR>||
        numeric_limits&lt;int&gt;::max() &lt; lval))
        <BR><BR>
        <BR><BR>The parentheses aren't
        balanced.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP67">JP 67</A></TD>
<TD valign="top">
27.7.1
&#160;
  </TD>
<TD valign="top">
        basic_stringbuf dose not use concept.
&#160;
  </TD>
<TD valign="top">
        Replace &#8220;class Allocator&#8221; to &#8220;Allocator
        Alloc&#8221;.
        <BR><BR>
         Correct as follows.
        <BR>
        
        <BR>
        namespace std {
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt;,
        <BR>
        <u>Allocator Alloc</u> = allocator&lt;charT&gt; &gt;
        <BR>
        class basic_stringbuf : public
        basic_streambuf&lt;charT,traits&gt; {
        <BR>
        public:
        <BR>...
        <BR>
        
        <BR>//
        27.7.1.1 Constructors:
        <BR>
        explicit basic_stringbuf(ios_base::openmode which
        <BR>=
        ios_base::in | ios_base::out);
        <BR>
        explicit basic_stringbuf
        <BR>
        (const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        str,
        <BR>
        ios_base::openmode which = ios_base::in | ios_base::out);
        <BR>
        basic_stringbuf(basic_stringbuf&amp;&amp; rhs);
        <BR>
        
        <BR>...
        <BR>
        
        <BR>
        
        <BR>//
        27.7.1.3 Get and set:
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt; str() const;
        <BR>
        void str(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; s);
        <BR>
        
        <BR>...
        <BR>};
        <BR>
        
        <BR>
        template &lt;class charT, class traits, <u>Allocator
        Alloc</u>&gt;
        <BR>
        void swap(basic_stringbuf&lt;charT, traits,
        <u>Alloc</u>&gt;&amp; x,
        <BR>
        basic_stringbuf&lt;charT, traits, <u>Alloc</u>&gt;&amp; y);
        <BR>
        template &lt;class charT, class traits, <u>Allocator
        Alloc</u>&gt;
        <BR>
        void swap(basic_stringbuf&lt;charT, traits,
        <u>Alloc</u>&gt;&amp;&amp; x,
        <BR>
        basic_stringbuf&lt;charT, traits, <u>Alloc</u>&gt;&amp; y);
        <BR>
        template &lt;class charT, class traits, <u>Allocator
        Alloc</u>&gt;
        <BR>
        void swap(basic_stringbuf&lt;charT, traits,
        <u>Alloc</u>&gt;&amp; x,
        <BR>
        basic_stringbuf&lt;charT, traits,
        <u>Alloc</u>&gt;&amp;&amp; y);
        <BR>}
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1141">1141</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP68">JP 68</A></TD>
<TD valign="top">
27.7.2
&#160;
  </TD>
<TD valign="top">
        basic_istringstream dose not use concept.
&#160;
  </TD>
<TD valign="top">
        Replace &#8220;class Allocator&#8221; to &#8220;Allocator
        Alloc&#8221;.
        <BR><BR>
         Correct as follows.
        <BR>
        
        <BR>
        namespace std {
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt;,
        <BR>
        <u>Allocator Alloc</u> = allocator&lt;charT&gt; &gt;
        <BR>
        class basic_istringstream : public
        basic_istream&lt;charT,traits&gt; {
        <BR>
        public:
        <BR>
        typedef charT char_type;
        <BR>
        typedef typename traits::int_type int_type;
        <BR>
        typedef typename traits::pos_type pos_type;
        <BR>
        typedef typename traits::off_type off_type;
        <BR>
        typedef traits traits_type;
        <BR>
        typedef <u>Alloc</u> allocator_type;
        <BR>
        
        <BR>//
        27.7.2.1 Constructors:
        <BR>
        explicit basic_istringstream(ios_base::openmode which =
        ios_base::in);
        <BR>
        explicit basic_istringstream(
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        str,
        <BR>
        ios_base::openmode which = ios_base::in);
        <BR>
        basic_istringstream(basic_istringstream&amp;&amp; rhs);
        <BR>
        
        <BR>//
        27.7.2.2 Assign and swap:
        <BR>
        basic_istringstream&amp;
        operator=(basic_istringstream&amp;&amp; rhs);
        <BR>
        void swap(basic_istringstream&amp;&amp; rhs);
        <BR>
        
        <BR>//
        27.7.2.3 Members:
        <BR>
        basic_stringbuf&lt;charT,traits,<u>Alloc</u>&gt;* rdbuf()
        const;
        <BR>
        
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt; str() const;
        <BR>
        void str(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; s);
        <BR>
        
        <BR>
        private:
        <BR>//
        basic_stringbuf&lt;charT,traits,<u>Alloc</u>&gt; sb;
        exposition only
        <BR>};
        <BR>
        
        <BR>
        template &lt;class charT, class traits, <u>Allocator
        Alloc</u>&gt;
        <BR>
        void swap(basic_istringstream&lt;charT, traits,
        <u>Alloc</u>&gt;&amp; x,
        <BR>
        basic_istringstream&lt;charT, traits, <u>Alloc</u>&gt;&amp;
        y);
        <BR>
        template &lt;class charT, class traits, <u>Allocator
        Alloc</u>&gt;
        <BR>
        void swap(basic_istringstream&lt;charT, traits,
        <u>Alloc</u>&gt;&amp;&amp; x,
        <BR>
        basic_istringstream&lt;charT, traits, <u>Alloc</u>&gt;&amp;
        y);
        <BR>
        template &lt;class charT, class traits, <u>Allocator
        Alloc</u>&gt;
        <BR>
        void swap(basic_istringstream&lt;charT, traits,
        <u>Alloc</u>&gt;&amp; x,
        <BR>
        basic_istringstream&lt;charT, traits,
        <u>Alloc</u>&gt;&amp;&amp; y);
        <BR>}
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1141">1141</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP69">JP 69</A></TD>
<TD valign="top">
27.7.3
&#160;
  </TD>
<TD valign="top">
        basic_ostringstream dose not use concept.
&#160;
  </TD>
<TD valign="top">
        Replace &#8220;class Allocator&#8221; to &#8220;Allocator
        Alloc&#8221;.
        <BR><BR>
         Correct as follows.
        <BR>
        
        <BR>
        namespace std {
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt;,
        <BR>
        <u>Allocator Alloc</u> = allocator&lt;charT&gt; &gt;
        <BR>
        class basic_ostringstream : public
        basic_ostream&lt;charT,traits&gt; {
        <BR>
        public:
        <BR>//
        types:
        <BR>
        typedef charT char_type;
        <BR>
        typedef typename traits::int_type int_type;
        <BR>
        typedef typename traits::pos_type pos_type;
        <BR>
        typedef typename traits::off_type off_type;
        <BR>
        typedef traits traits_type;
        <BR>
        typedef <u>Alloc</u> allocator_type;
        <BR>
        
        <BR>//
        27.7.3.1 Constructors/destructor:
        <BR>
        explicit basic_ostringstream(ios_base::openmode which =
        ios_base::out);
        <BR>
        explicit basic_ostringstream(
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        str,
        <BR>
        ios_base::openmode which = ios_base::out);
        <BR>
        basic_ostringstream(basic_ostringstream&amp;&amp; rhs);
        <BR>
        
        <BR>//
        27.7.3.2 Assign/swap:
        <BR>
        basic_ostringstream&amp;
        operator=(basic_ostringstream&amp;&amp; rhs);
        <BR>
        void swap(basic_ostringstream&amp;&amp; rhs);
        <BR>
        
        <BR>//
        27.7.3.3 Members:
        <BR>
        basic_stringbuf&lt;charT,traits,<u>Alloc</u>&gt;* rdbuf()
        const;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt; str() const;
        <BR>
        void str(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; s);
        <BR>
        private:
        <BR>//
        basic_stringbuf&lt;charT,traits,<u>Alloc</u>&gt; sb;
        exposition only
        <BR>};
        <BR>
        
        <BR>
        template &lt;class charT, class traits, <u>Allocator</u>
        <font size="2" style="font-size: 11pt"><u>Alloc</u>&gt;</font>
        <BR>
        void swap(basic_ostringstream&lt;charT, traits,
        <u>Alloc</u>&gt;&amp; x,
        <BR>
        basic_ostringstream&lt;charT, traits, <u>Alloc</u>&gt;&amp;
        y);
        <BR>
        template &lt;class charT, class traits, <u>Allocator</u>
        <font size="2" style="font-size: 11pt"><u>Alloc</u>&gt;</font>
        <BR>
        void swap(basic_ostringstream&lt;charT, traits,
        <u>Alloc</u>&gt;&amp;&amp; x,
        <BR>
        basic_ostringstream&lt;charT, traits, <u>Alloc</u>&gt;&amp;
        y);
        <BR>
        template &lt;class charT, class traits, <u>Allocator
        Alloc</u>&gt;
        <BR>
        void swap(basic_ostringstream&lt;charT, traits,
        <u>Alloc</u>&gt;&amp; x,
        <BR>
        basic_ostringstream&lt;charT, traits,
        <u>Alloc</u>&gt;&amp;&amp; y);
        <BR>}
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1141">1141</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP71">JP 71</A></TD>
<TD valign="top">
27.7.3
&#160;
  </TD>
<TD valign="top">
        Typo.
        <BR><BR>"template" is missing in
        "class basic_ostringstream" of the title of the chapter.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR><BR>
        27.7.3 Class basic_ostringstream
        <BR><BR>
        
        <BR><BR>
        should be
        <BR><BR>
        
        <BR><BR>27.7.3 Class <u>template</u>
        basic_ostringstream
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP72">JP 72</A></TD>
<TD valign="top">
27.7.4
&#160;
  </TD>
<TD valign="top">
        basic_stringstream dose not use concept.
&#160;
  </TD>
<TD valign="top">
        Replace "class Allocator" to "Allocator Alloc".
        <BR><BR>
         Correct as follows.
        <BR>
        
        <BR>
        namespace std {
        <BR>
        template &lt;class charT, class traits =
        char_traits&lt;charT&gt;,
        <BR>
        <u>Allocator Alloc</u> = allocator&lt;charT&gt; &gt;
        <BR>
        class basic_stringstream
        <BR>:
        public basic_iostream&lt;charT,traits&gt; {
        <BR>
        public:
        <BR>//
        types:
        <BR>
        typedef charT char_type;
        <BR>
        typedef typename traits::int_type int_type;
        <BR>
        typedef typename traits::pos_type pos_type;
        <BR>
        typedef typename traits::off_type off_type;
        <BR>
        typedef traits traits_type;
        <BR>
        typedef <u>Alloc</u> allocator_type;
        <BR>
        
        <BR>//
        constructors/destructor
        <BR>
        explicit basic_stringstream(
        <BR>
        ios_base::openmode which = ios_base::out|ios_base::in);
        <BR>
        explicit basic_stringstream(
        <BR>
        const basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp;
        str,
        <BR>
        ios_base::openmode which = ios_base::out|ios_base::in);
        <BR>
        basic_stringstream(basic_stringstream&amp;&amp; rhs);
        <BR>
        
        <BR>//
        27.7.5.1 Assign/swap:
        <BR>
        void swap(basic_stringstream&amp;&amp; rhs);
        <BR>
        
        <BR>//
        Members:
        <BR>
        basic_stringbuf&lt;charT,traits,<u>Alloc</u>&gt;* rdbuf()
        const;
        <BR>
        basic_string&lt;charT,traits,<u>Alloc</u>&gt; str() const;
        <BR>
        void str(const
        basic_string&lt;charT,traits,<u>Alloc</u>&gt;&amp; str);
        <BR>
        private:
        <BR>//
        basic_stringbuf&lt;charT, traits&gt; sb; exposition only
        <BR>};
        <BR>
        
        <BR>
        template &lt;class charT, class traits, <u>Allocator
        Alloc</u>&gt;
        <BR>
        void swap(basic_stringstream&lt;charT, traits,
        <u>Alloc</u>&gt;&amp; x,
        <BR>
        basic_stringstream&lt;charT, traits, <u>Alloc</u>&gt;&amp;
        y);
        <BR>
        template &lt;class charT, class traits, <u>Allocator</u>
        <font size="2" style="font-size: 11pt"><u>Alloc</u>&gt;</font>
        <BR>
        void swap(basic_stringstream&lt;charT, traits,
        <u>Alloc</u>&gt;&amp;&amp; x,
        <BR>
        basic_stringstream&lt;charT, traits, <u>Alloc</u>&gt;&amp;
        y);
        <BR>
        template &lt;class charT, class traits, <u>Allocator</u>
        <font size="2" style="font-size: 11pt"><u>Alloc</u>&gt;</font>
        <BR>
        void swap(basic_stringstream&lt;charT, traits,
        <u>Alloc</u>&gt;&amp; x,
        <BR>
        basic_stringstream&lt;charT, traits,
        <u>Alloc</u>&gt;&amp;&amp; y);
        <BR>}
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1141">1141</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP73">JP 73</A></TD>
<TD valign="top">
27.8.1.14
&#160;
  </TD>
<TD valign="top">
        It is a problem
        from C++98, fstream cannot appoint a filename of wide
        character string(const wchar_t and const wstring&amp;).
&#160;
  </TD>
<TD valign="top">
        Add
        interface corresponding to wchar_t, char16_t and char32_t.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1150">1150</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>This problem may be solved in TR2 by the filesystem library with a file path class with templated constructor. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US86">US 86</A></TD>
<TD valign="top">
28
&#160;
  </TD>
<TD valign="top">
        The
        regular expressions chapter is not concept enabled.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1142">1142</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK309">UK 309</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/115">
     [115]
    </A></TD>
<TD valign="top">
28
&#160;
  </TD>
<TD valign="top">
        Regular
        expressions cannot be used in constrained templates
&#160;
  </TD>
<TD valign="top">
        Provide constraints for the regular
        expression library, clause 28
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1142">1142</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK310">UK 310</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/281">
     [281]
    </A></TD>
<TD valign="top">
28
&#160;
  </TD>
<TD valign="top">
        The regex chapter uses iterators in the old
        pre-concept style, it should be changed to use concepts
        instead.
&#160;
  </TD>
<TD valign="top">
        Use concepts for iterator template
        arguments throughout.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1142">1142</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK314">UK 314</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/343">
     [343]
    </A></TD>
<TD valign="top">
28.4
&#160;
  </TD>
<TD valign="top">
        The swap
        overloads for regex classes are only supplied for l-value
        references. Other sections of the library (eg 21 strings or
        23 containers) provide two extra overloads taking an
        r-value reference as the first and second argument
        respectively.
&#160;
  </TD>
<TD valign="top">
        Add the missing overloads to 28.4 and the
        corresponding later sections in 28 for each swap function.
        We want to accept AMs paper which proposes a single
        overload with two r-value references
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK315">UK 315</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/344">
     [344]
    </A></TD>
<TD valign="top">
28.4

    &#182;
    
p6
&#160;
  </TD>
<TD valign="top">
        6 Effects:
        string_type str(first, last); return
        use_facet&lt;collate&lt;charT&gt; &gt;(
        getloc()).transform(&amp;*str.begin(), &amp;*str.end()); Is
        it legal to dereference str.end() ?
&#160;
  </TD>
<TD valign="top">
        Reword to effect clause to use legal
        iterator dereferences
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK316">UK 316</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/345">
     [345]
    </A></TD>
<TD valign="top">
28.4 ff
&#160;
  </TD>
<TD valign="top">
        The constructors
        for regex classes do not have an r-value overload.
&#160;
  </TD>
<TD valign="top">
        Add the missing r-value constructors to
        regex classes.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#723">723</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>Updated wording to reflect new "swap rules".
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK317">UK 317</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/278">
     [278]
    </A></TD>
<TD valign="top">
28.8
&#160;
  </TD>
<TD valign="top">
        basic_string has both a constructor and an
        assignment operator that accepts an initializer list,
        basic_regex should have the same.
&#160;
  </TD>
<TD valign="top">
        In the
        basic_regex synopsis, after: basic_regex&amp;
        operator=(const charT* ptr); add: basic_regex&amp;
        operator=(initializer_list&lt;charT&gt; il); And after
        paragraph 20 add: basic_regex&amp;
        operator=(initializer_list&lt;charT&gt; il); Effects:
        returns assign(il.begin(), il.end());
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1014">1014</A>&#160;
  </TD>
<TD valign="top"><BR><BR>The requested constructor was already present. The requested operator= was added.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP74">JP 74</A></TD>
<TD valign="top">
28.8
&#160;
  </TD>
<TD valign="top">
        &#8220;basic_regx &amp; operator=
        (initializer_list&lt;T&gt;);&#8221; is not defined.
&#160;
  </TD>
<TD valign="top">
        Add
        basic_regx &amp; operator= (initializer_list&lt;T&gt;);
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1014">1014</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK318">UK 318</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/279">
     [279]
    </A></TD>
<TD valign="top">
28.8.2

    &#182;
    
para 22
&#160;
  </TD>
<TD valign="top">
        Constructor
        definition should appear with the other constructors not
        after assignment ops.
&#160;
  </TD>
<TD valign="top">
        Move para 22 to just after para 17.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK319">UK 319</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/280">
     [280]
    </A></TD>
<TD valign="top">
28.12.2
&#160;
  </TD>
<TD valign="top">
        It was always expected that
        regex_token_iterator would be constructible from an array
        literal: indeed ideally this is the prefered method of
        initializing such an object. However, the best we could do
        in C++0x was: template &lt;std::size_t N&gt;
        regex_token_iterator(BidirectionalIterator a,
        BidirectionalIterator b, const regex_type&amp; re, const
        int (&amp;submatches)[N], regex_constants::match_flag_type
        m = regex_constants::match_default); Now that we have
        initializer_lists we should use them to remove this
        particular wart.
&#160;
  </TD>
<TD valign="top">
        To the synopsis
        for regex_token_iterator, after template &lt;std::size_t
        N&gt; regex_token_iterator(BidirectionalIterator a,
        BidirectionalIterator b, const regex_type&amp; re, const
        int (&amp;submatches)[N], regex_constants::match_flag_type
        m = regex_constants::match_default); add
        regex_token_iterator(BidirectionalIterator a,
        BidirectionalIterator b, const regex_type&amp; re,
        initializer_list&lt;int&gt; submatches,
        regex_constants::match_flag_type m =
        regex_constants::match_default); In 28.12.2.1 add the
        declaration: regex_token_iterator(BidirectionalIterator a,
        BidirectionalIterator b, const regex_type&amp; re,
        initializer_list&lt;int&gt; submatches,
        regex_constants::match_flag_type m =
        regex_constants::match_default); And to the end of para 3
        add: The forth constructor initializes the member subs to
        hold a copy of the sequence of integer values in the range
        [submatches.begin(), submatches.end()).
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#909">909</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US87">US 87</A></TD>
<TD valign="top">
29
&#160;
  </TD>
<TD valign="top">
        The
        atomics chapter is not concept enabled. The adopted paper,
        N2427, did have those concepts.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1143">1143</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK311">UK 311</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/116">
     [116]
    </A></TD>
<TD valign="top">
29
&#160;
  </TD>
<TD valign="top">
        Atomic types
        cannot be used generically in a constrained template
&#160;
  </TD>
<TD valign="top">
        Provide constraints for the atomics
        library, clause 29
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1143">1143</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK312">UK 312</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/157">
     [157]
    </A></TD>
<TD valign="top">
29
&#160;
  </TD>
<TD valign="top">
        The contents of the &lt;stdatomic.h&gt;
        header are not listed anywhere, and &lt;cstdatomic&gt; is
        listed as a C99 header in chapter 17. If we intend to use
        these for compatibility with a future C standard, we should
        not use them now.
&#160;
  </TD>
<TD valign="top">
        Remove &lt;cstdatomic&gt; from the C99
        headers in table 14. Add a new header &lt;atomic&gt; to the
        headers in table 13. Update chapter 29 to remove reference
        to &lt;stdatomic.h&gt; and replace the use of
        &lt;cstdatomic&gt; with &lt;atomic&gt;. If and when WG14
        adds atomic operations to C we can add corresponding
        headers to table 14 with a TR.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1145">1145</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>Solved by N2992
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP75">JP 75</A></TD>
<TD valign="top">
29
&#160;
  </TD>
<TD valign="top">
        A
        definition of enum or struct is the style of C using
        typedef.
&#160;
  </TD>
<TD valign="top">
        Change to a style of C++.
        <BR><BR>
        Correct as follows.
        <BR>
        
        <BR>
        29.1
        <BR>
        
        <BR>
        namespace std {
        <BR>
        <u>typedef</u> enum memory_order {
        <BR>
        memory_order_relaxed, memory_order_consume,
        memory_order_acquire,
        <BR>
        memory_order_release, memory_order_acq_rel,
        memory_order_seq_cst
        <BR>}
        memory_order;
        <BR>}
        <BR>
        
        <BR>
        should be
        <BR>
        
        <BR>
        namespace std {
        <BR>
        enum memory_order {
        <BR>
        memory_order_relaxed, memory_order_consume,
        memory_order_acquire,
        <BR>
        memory_order_release, memory_order_acq_rel,
        memory_order_seq_cst
        <BR>};
        <BR>}
        <BR>
        
        <BR>
        29.3.1
        <BR>
        
        <BR>
        namespace std {
        <BR>
        <u>typedef</u> struct atomic_bool {
        <BR>...
        <BR>}
        atomic_bool;
        <BR>}
        <BR>
        
        <BR>
        should be
        <BR>
        
        <BR>
        namespace std {
        <BR>
        struct atomic_bool {
        <BR>...
        <BR>};
        <BR>}
        <BR>
        
        <BR>
        namespace std {
        <BR>
        <u>typedef</u> struct atomic_<i>itype</i> {
        <BR>...
        <BR>}
        atomic_<i>itype</i>;
        <BR>}
        <BR>
        
        <BR>
        should be
        <BR>
        
        <BR>
        namespace std {
        <BR>
        struct atomic_<i>itype</i> {
        <BR>...
        <BR>};
        <BR>}
        <BR>
        
        <BR>
        29.3.2
        <BR>
        
        <BR>
        namespace std {
        <BR>
        <u>typedef</u> struct atomic_address {
        <BR>...
        <BR>}
        atomic_address;
        <BR>}
        <BR>
        
        <BR>
        should be
        <BR>
        
        <BR>
        namespace std {
        <BR>
        struct atomic_address {
        <BR>...
        <BR>};
        <BR>}
        <BR>
        
        <BR>
        29.5
        <BR>
        
        <BR>
        namespace std {
        <BR>
        <u>typedef</u> struct atomic_flag {
        <BR>...
        <BR>}
        atomic_flag;
        <BR>}
        <BR>
        
        <BR>
        should be
        <BR>
        
        <BR>
        namespace std {
        <BR>
        struct atomic_flag {
        <BR>...
        <BR>};
        <BR>}
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>We believe the current 
syntax is most appropriate for an interface that is intended to be 
highly compatible with C.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK313">UK 313</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/220">
     [220]
    </A></TD>
<TD valign="top">
29.1
&#160;
  </TD>
<TD valign="top">
        seq_cst fences don't necessarily guarantee
        ordering
        http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#926
&#160;
  </TD>
<TD valign="top">
        Add a new
        paragraph after 29.1 [atomics.order]p5 that says For atomic
        operations A and B on an atomic object M, where A and B
        modify M, if there are memory_order_seq_cst fences X and Y
        such that A is sequenced before X, Y is sequenced before B,
        and X precedes Y in S, then B occurs later than A in the
        modifiction order of M.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#926">926</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US88">US 88</A></TD>
<TD valign="top">
29.2
&#160;
  </TD>
<TD valign="top">
        The "lockfree" facilities do
        not tell the programmer enough.
&#160;
  </TD>
<TD valign="top">
        Expand the "lockfree" facilities. See the attached paper
        "Issues with the C++ Standard" under Chapter 29,
        "atomics.lockfree doesn't tell the programmer enough"
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1146">1146</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US89">US 89</A></TD>
<TD valign="top">
29.3.1

    &#182;
    
Table 122
&#160;
  </TD>
<TD valign="top">
        The
        types in the table "Atomics for standard typedef types"
        should be typedefs, not classes. These semantics are
        necessary for compatibility with C.
&#160;
  </TD>
<TD valign="top">
        Change the classes to
        typedefs.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US90">US 90</A></TD>
<TD valign="top">
29.4
&#160;
  </TD>
<TD valign="top">
        Are atomic functions allowed
        to have non-volatile overloads?
&#160;
  </TD>
<TD valign="top">
        Allow non-volatile overloads. See the attached paper
        "Issues with the C++ Standard, under Chapter 29, "Are
        atomic functions allowed to have non-volatile overloads?"
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#908, 1147">908, 1147</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>Solved by N2992. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US91">US 91</A></TD>
<TD valign="top">
29.4
&#160;
  </TD>
<TD valign="top">
        Whether or not a failed
        compare_exchange is a RMW operation (as used in 1.10
        [intro.multithread]) is unclear.
&#160;
  </TD>
<TD valign="top">
        Make failing compare_exchange operations <font size="2" style="font-size: 11pt"><strong>not</strong> be RMW. See
        the attached paper under "atomic RMW status of failed
        compare_exchange"</font>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1043">1043</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">
     N2925</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US92">US 92</A></TD>
<TD valign="top">
29.4
&#160;
  </TD>
<TD valign="top">
        The effect of
        memory_order_consume with atomic RMW operations is unclear.
&#160;
  </TD>
<TD valign="top">
        Follow the lead of fences [atomics.fences], and promote
        memory_order_consume to memory_order_acquire with RMW
        operations.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>We can not see the issue being suggested by the comment.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP76">JP 76</A></TD>
<TD valign="top">
30
&#160;
  </TD>
<TD valign="top">
        A
        description for "<i>Throws:</i> Nothing." are not unified.
        <BR><BR>At
        the part without throw, "<i>Throws:</i> Nothing." should be
        described.
&#160;
  </TD>
<TD valign="top">
        Add
        "<i>Throws:</i> Nothing." to the following.
        <BR><BR>
        30.2.1.6 , 1<sup>st</sup> <font size="2" style="font-size: 11pt">paragraph</font>
        <BR><BR>
        30.3.3.1 , 4<sup>th</sup> <font size="2" style="font-size: 11pt">paragraph</font>
        <BR><BR>
        30.3.3.2.1 , 6<sup>th</sup> <font size="2" style="font-size: 11pt">paragraph</font>
        <BR><BR>
        30.4.1 , 7<sup>th</sup> <font size="2" style="font-size: 11pt">and 8<sup>th</sup> paragraph</font>
        <BR><BR>30.4.2 ,
        6<sup>th</sup><font size="2" style="font-size: 11pt">,
        7<sup>th</sup>,19<sup>th</sup>,21th and 25<sup>th</sup>
        paragraph</font>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1089">1089</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US93">US 93</A></TD>
<TD valign="top">
30
&#160;
  </TD>
<TD valign="top">
        The
        thread chapter is not concept enabled.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK320">UK 320</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/117">
     [117]
    </A></TD>
<TD valign="top">
30
&#160;
  </TD>
<TD valign="top">
        Threads library cannot be used in
        constrained templates
&#160;
  </TD>
<TD valign="top">
        Provide constraints for the threads
        library, clause 30
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK321">UK 321</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/172">
     [172]
    </A></TD>
<TD valign="top">
30
&#160;
  </TD>
<TD valign="top">
        Throughout this
        clause, the term Requires: is used to introduce compile
        time requirements, which we expect to be replaced with
        concepts and requires in code. Run-time preconditions are
        introduced with the term "Preconditions:" which is not a
        defined part of the library documentation structure
        (17.5.2.4). However, this is exactly the direction that BSI
        would like to see the organisation move, replacing
        Requires: clauses with Preconditions: clasues throught the
        library. See comment against clause 17 for more details.
&#160;
  </TD>
<TD valign="top">
        Decument Preconditions: paragraphs in
        17.5.2.4, and use consistently through rest of the library.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US94">US 94</A></TD>
<TD valign="top">
30.1.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The first sentence of para 1 suggests that no other
        library function is permitted to call operating system or
        low level APIs.
&#160;
  </TD>
<TD valign="top">
        Rewrite para 1
        as: &#8220; <font color="#000000">Some functions described
        in this Clause are specified to throw exceptions of type
        system_error (</font><font color="#0000FF">19.4.5</font>
        <font color="#000000">). Such exceptions shall be thrown if
        a call to an operating system or underlying API results in
        an error that prevents the library function from satisfying
        its postconditions or from returning a meaningful
        value.&#8221;</font>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US95">US 95</A></TD>
<TD valign="top">
30.1.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        &#8220;native_handle_type&#8221; is a typedef, not a
        class member.
&#160;
  </TD>
<TD valign="top">
        Several classes
        described in this Clause have a member native_handle (of
        type native_handle_type) . The
        <BR><BR>
        presence of this member and its semantics is implementation
        defined. [ Note: This member allows implementations to
        provide access to implementation details. The name of the
        member and the type are specified to facilitate portable
        compile-time detection. Actual use of this member or the
        corresponding type is inherently non-portable. &#8212;end
        note ]
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Not a defect. native_handle_type is a typedef, but it is also a member of 
    the classes in question.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US96">US 96</A></TD>
<TD valign="top">
30.1.4

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        There is no definition here for monotonic clock.
&#160;
  </TD>
<TD valign="top">
        Implementations
        should use a <i>monotonic clock</i> to measure time for
        these functions. A monotonic clock measures real time, but
        cannot be set, and is guaranteed to have no negative clock
        jumps.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>There is a good definition. Also, see library issue 1158.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK322">UK 322</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/168">
     [168]
    </A></TD>
<TD valign="top">
30.1.4

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        Not all systms
        can provide a monotonic clock. How are they expected to
        treat a _for function?
&#160;
  </TD>
<TD valign="top">
        Add at least a note explaining the intent
        for systems that do not support a monotonic clock.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1158">1158</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK323">UK 323</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/171">
     [171]
    </A></TD>
<TD valign="top">
30.2.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        The presence of
        a non-explicit variadic template constructor alongside an
        explicit single-argument constructor can lead to behaviour
        that is not intended: the variadic constructor will be
        selected for implicit conversions, defeating the purpose of
        the explicit single-argument constructor. Additionally the
        single-argument constructor is redundant; the variadic
        constructor can provide identical functionality with one
        *fewer* copies if the supplied func is an lvalue.
&#160;
  </TD>
<TD valign="top">
        Mark constructor template &lt;class F,
        class ...Args&gt; thread(F&amp;&amp; f, Args&amp;&amp;...
        args); as explicit and remove the single-argument
        constructor.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#929">929</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK324">UK 324</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/169">
     [169]
    </A></TD>
<TD valign="top">
30.2.1.1
&#160;
  </TD>
<TD valign="top">
        thread::id
        objects should be as useable in hashing containers as they
        are in ordered associative containers.
&#160;
  </TD>
<TD valign="top">
        Add thread::id
        support for std::hash
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#889">889</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Not a defect. See [unord.hash], where std::thread:id is already listed as a 
    required specialization for std::hash().
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP77">JP 77</A></TD>
<TD valign="top">
30.2.1.2
&#160;
  </TD>
<TD valign="top">
        "CopyConstructible" and "MoveConstructible" in
        "<i>Requires:</i> F and each Ti in Args shall be
        CopyConstructible if an lvalue and otherwise
        MoveConstructible." are reflected by interface.
&#160;
  </TD>
<TD valign="top">
        Add
        a concept for constructor of thread.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP78">JP 78</A></TD>
<TD valign="top">
30.2.1.2

    &#182;
    
        4<sup>th</sup> <font size="2" style="font-size: 11pt">para, 1<sup>st</sup> line</font>
&#160;
  </TD>
<TD valign="top">
        In
        "F and each Ti in Args", 'Ti' is not clear.
&#160;
  </TD>
<TD valign="top">
        Replace "Ti" with "args"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US97">US 97</A></TD>
<TD valign="top">
30.2.1.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        detach-on-destruction may result in
        &#8220;escaped&#8221; threads accessing objects with
        bounded lifetime after the end of their lifetime.
&#160;
  </TD>
<TD valign="top">
        See document WG21 N2802=08-0312 written by Hans Boehm.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#Doc">Doc</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
N2802 Alternative 2 was accepted at the Summit meeting.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2802.html">
     N2802</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US98">US 98</A></TD>
<TD valign="top">
30.2.1.3,
        30.2.1.4
&#160;
  </TD>
<TD valign="top">
        The current defined behavior
        for the std::thread destructor is to detach the thread.
        Unfortunately, this behavior exposes programmers to tricky,
        hard-to-diagnose, undefined behavior.
&#160;
  </TD>
<TD valign="top">
        Change destruction behavior to undefined behavior, with a
        note strongly encouraging termination. See the attached
        paper "Issues with the C++ Standard" under Chapter 30,
        "Implicit thread detach is harmful".
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK325">UK 325</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/174">
     [174]
    </A></TD>
<TD valign="top">
30.3.3

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
        We believe constexpr literal values should
        be a more natural expression of empty tag types than extern
        objects as it should improve the compilers ability to
        optimize the empty object away completely.
&#160;
  </TD>
<TD valign="top">
        Replace the
        extern declarations: extern const defer_lock_t defer_lock;
        extern const try_to_lock_t try_to_lock; extern const
        adopt_lock_t adopt_lock; with constexpr values constexpr
        defer_lock_t defer_lock{}; constexpr try_to_lock_t
        try_to_lock{}; constexpr adopt_lock_t adopt_lock{};
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1044">1044</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK326">UK 326</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/176">
     [176]
    </A></TD>
<TD valign="top">
30.3.3.2.1

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
        The precondition
        that the mutex is not owned by this thread offers
        introduces the risk of un-necessary undefined behaviour
        into the program. The only time it matters whether the
        current thread owns the mutex is in the lock operation, and
        that will happen subsequent to construction in this case.
        The lock operation has the identical pre-condition, so
        there is nothing gained by asserting that precondition
        earlier and denying the program the right to get into a
        valid state before calling lock.
&#160;
  </TD>
<TD valign="top">
        Strike 30.3.3.2.1p7
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1045">1045</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK327">UK 327</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/179">
     [179]
    </A></TD>
<TD valign="top">
30.3.3.2.2

    &#182;
    
4, 9, 14, 19
&#160;
  </TD>
<TD valign="top">
        Not clear what
        the specification for error condition
        resource_deadlock_would_occur means. It is perfectly
        possible for this thread to own the mutex without setting
        owns to true on this specific lock object. It is also
        possible for lock operations to succeed even if the thread
        does own the mutex, if the mutex is recursive. Likewise, if
        the mutex is not recursive and the mutex has been locked
        externally, it is not always possible to know that this
        error condition should be raised, depending on the host
        operating system facilities. It is possible that 'i.e.' was
        supposed to be 'e.g.' and that suggests that recursive
        locks are not allowed. That makes sense, as the
        exposition-only member owns is boolean and not a integer to
        count recursive locks.
&#160;
  </TD>
<TD valign="top">
        Add a precondition !owns. Change the 'i.e.'
        in the error condition to be 'e.g.' to allow for this
        condition to propogate deadlock detection by the host OS.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1159">1159</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK328">UK 328</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/182">
     [182]
    </A></TD>
<TD valign="top">
30.3.3.2.2

    &#182;
    
20
&#160;
  </TD>
<TD valign="top">
        There is a missing precondition that owns
        is true, or an if(owns) test is missing from the effect
        clause
&#160;
  </TD>
<TD valign="top">
        Add a
        precondition that owns == true. Add an error condition to
        detect a violation, rather than yield undefined behaviour.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1159">1159</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK329">UK 329</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/203">
     [203]
    </A></TD>
<TD valign="top">
30.5
&#160;
  </TD>
<TD valign="top">
        future, promise and packaged_task provide a
        framework for creating future values, but a simple function
        to tie all three components together is missing. Note that
        we only need a *simple* facility for C++0x. Advanced thread
        pools are to be left for TR2.
&#160;
  </TD>
<TD valign="top">
        Provide a simple
        function along the lines of: template&lt; typename F,
        typename ... Args &gt; requires Callable&lt; F, Args...
        &gt; future&lt; Callable::result_type &gt; async(
        F&amp;&amp; f, Args &amp;&amp; ... ); Semantics are similar
        to creating a thread object with a packaged_task invoking f
        with forward&lt;Args&gt;(args...) but details are left
        unspecified to allow different scheduling and thread
        spawning implementations. It is unspecified whether a task
        submitted to async is run on its own thread or a thread
        previously used for another async task. If a call to async
        succeeds, it shall be safe to wait for it from any thread.
        The state of thread_local variables shall be preserved
        during async calls. No two incomplete async tasks shall see
        the same value of this_thread::get_id(). [Note: this
        effectively forces new tasks to be run on a new thread, or
        a fixed-size pool with no queue. If the library is unable
        to spawn a new thread or there are no free worker threads
        then the async call should fail.]
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1046">1046</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>N2996 (Herb's and Lawrence's paper on Async)
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK330">UK 330</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/424">
     [424]
    </A></TD>
<TD valign="top">
30.5.1
&#160;
  </TD>
<TD valign="top">
        30.5.1 (and then 30.5.7) refer to a
        specialisation of
        constructible_with_allocator_prefix&lt;&gt; However this
        trait is not in the CD, so references to it should be
        removed.
&#160;
  </TD>
<TD valign="top">
        Remove the
        reference to constructible_with_allocator_prefix in 30.5.1
        Remove paragraph 30.5.7
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP79">JP 79</A></TD>
<TD valign="top">
30.5.1
&#160;
  </TD>
<TD valign="top">
        The
        concept of UsesAllocator and Allocator should be used.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR><BR>
        
        <BR><BR>
        template &lt;class R, class Alloc&gt;
        <BR><BR>
        struct uses_allocator&lt;promise&lt;R&gt;, Alloc&gt;;
        <BR><BR>
        template &lt;class R&gt;
        <BR><BR>
        struct
        constructible_with_allocator_prefix&lt;promise&lt;R&gt;
        &gt;;
        <BR><BR>
        
        <BR><BR>
        should be
        <BR><BR>
        
        <BR><BR>
        template&lt;class R, Allocator Alloc&gt;
        <BR><BR>concept_map
        UsesAllocator&lt;promise&lt;R&gt;, Alloc&gt;;
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK331">UK 331</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/192">
     [192]
    </A></TD>
<TD valign="top">
30.5.3
&#160;
  </TD>
<TD valign="top">
        Not clear what
        it means for a public constructor to be 'exposition only'.
        If the intent is purely to support the library calling this
        constructor then it can be made private and accessed
        through friendship. Otherwise it should be documented for
        public consumption.
&#160;
  </TD>
<TD valign="top">
        Declare the constructor as private with a
        note about intended friendship, or remove the
        exposition-only comment and document the semantics.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1160">1160</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>Solved by N2997.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK332">UK 332</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/194">
     [194]
    </A></TD>
<TD valign="top">
30.5.4
&#160;
  </TD>
<TD valign="top">
        It is not clear
        without reference to the original proposal how to use a
        future. In particular, the only way for the user to
        construct a future is via the promise API which is
        documented after the presentation of future. Most library
        clauses feature a small description of their components and
        intended use, it would be most useful in this case.
&#160;
  </TD>
<TD valign="top">
        Provide a small introductory paragraph,
        docuenting intended purpose of the future class template
        and the way futures can only be created via the promise
        API.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK333">UK 333</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/195">
     [195]
    </A></TD>
<TD valign="top">
30.5.4

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
        We expect the complicated 3-signature
        specifcation for future::get() to be simplified to a single
        signature with a requires clause by the application of
        concepts.
&#160;
  </TD>
<TD valign="top">
        Requires fully baked concepts for clause 30
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK334">UK 334</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/196">
     [196]
    </A></TD>
<TD valign="top">
30.5.4

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
        Behaviour of
        get() is undefined if calling get() while not is_ready().
        The intent is that get() is a blocking call, and will wait
        for the future to become ready.
&#160;
  </TD>
<TD valign="top">
        Effects: If is_ready() would return false,
        block on the asynchronous result associated with *this.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1047">1047</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK335">UK 335</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/436">
     [436]
    </A></TD>
<TD valign="top">
30.5.4
&#160;
  </TD>
<TD valign="top">
        std::unique_future is MoveConstructible, so you can
        transfer the association with an asynchronous result from
        one instance to another. However, there is no way to
        determine whether or not an instance has been moved from,
        and therefore whether or not it is safe to wait for it.
        std::promise&lt;int&gt; p; std::unique_future&lt;int&gt;
        uf(p.get_future()); std::unique_future&lt;int&gt;
        uf2(std::move(uf)); uf.wait(); // oops, uf has no result to
        wait for.
&#160;
  </TD>
<TD valign="top">
        Add a "waitable()" function to
        unique_future (and shared_future) akin to
        std::thread::joinable(), which returns true if there is an
        associated result to wait for (whether or not it is ready).
        Then we can say: if(uf.waitable()) uf.wait();
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1048">1048</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>Solved by N2997. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK336">UK 336</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/437">
     [437]
    </A></TD>
<TD valign="top">
30.5.4
&#160;
  </TD>
<TD valign="top">
        It is possible
        to transfer ownership of the asynchronous result from one
        unique_future instance to another via the move-constructor.
        However, it is not possible to transfer it back, and nor is
        it possible to create a default-constructed unique_future
        instance to use as a later move target. This unduly limits
        the use of unique_future in code. Also, the lack of a
        move-assignment operator restricts the use of unique_future
        in containers such as std::vector - vector::insert requires
        move-assignable for example.
&#160;
  </TD>
<TD valign="top">
        Add a default constructor with the
        semantics that it creates a unique_future with no
        associated asynchronous result. Add a move-assignment
        operator which transfers ownership.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1161">1161</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>Solved by N2997. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP80">JP 80</A></TD>
<TD valign="top">
30.5.4,
        30.5.5
&#160;
  </TD>
<TD valign="top">
        Typo, duplicated "&gt;"
        <BR><BR>"class
        Period&gt;&gt;"
&#160;
  </TD>
<TD valign="top">
        Remove one
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK337">UK 337</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/198">
     [198]
    </A></TD>
<TD valign="top">
30.5.5
&#160;
  </TD>
<TD valign="top">
        shared_future
        should support an efficient move constructor that can avoid
        unnecessary manipulation of a reference count, much like
        shared_ptr
&#160;
  </TD>
<TD valign="top">
        Add a move constructor
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1162">1162</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK338">UK 338</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/223">
     [223]
    </A></TD>
<TD valign="top">
30.5.5
&#160;
  </TD>
<TD valign="top">
        shared_future is currently
        CopyConstructible, but not CopyAssignable. This is
        inconsistent with shared_ptr, and will surprise users.
        Users will then write work-arounds to provide this
        behaviour. We should provide it simply and efficiently as
        part of shared_future. Note that since the shared_future
        member functions for accessing the state are all declared
        const, the original usage of an immutable shared_future
        value that can be freely copied by multiple threads can be
        retained by declaring such an instance as "const
        shared_future".
&#160;
  </TD>
<TD valign="top">
        Remove "=delete"
        from the copy-assignment operator of shared_future. Add a
        move-constructor shared_future(shared_future&amp;&amp;
        rhs), and a move-assignment operator shared_future&amp;
        operator=(shared_future&amp;&amp; rhs). The postcondition
        for the copy-assignment operator is that *this has the same
        associated state as rhs. The postcondition for the
        move-constructor and move assignment is that *this has the
        same associated as rhs had before the
        constructor/assignment call and that rhs has no associated
        state.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1163">1163</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>Solved by N2997. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK339">UK 339</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/200">
     [200]
    </A></TD>
<TD valign="top">
30.5.6

    &#182;
    
6, 7
&#160;
  </TD>
<TD valign="top">
        Move assignment is goiing in the wrong
        direction, assigning from *this to the passed rvalue, and
        then returning a reference to an unusable *this
&#160;
  </TD>
<TD valign="top">
        Strike 6. 7
        Postcondition: associated state of *this is the same as the
        associated state of rhs before the call. rhs has no
        associated state.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1049">1049</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK340">UK 340</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/201">
     [201]
    </A></TD>
<TD valign="top">
30.5.6

    &#182;
    
11, 12, 13
&#160;
  </TD>
<TD valign="top">
        There is an
        implied postcondition that the state of the promise is
        transferred into the future leaving the promise with no
        associated state. It should be spelled out.
&#160;
  </TD>
<TD valign="top">
        Postcondition: *this has no associated
        state.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1050">1050</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK341">UK 341</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/122">
     [122]
    </A></TD>
<TD valign="top">
30.5.6
&#160;
  </TD>
<TD valign="top">
        promise::swap accepts its parameter by
        lvalue reference. This is inconsistent with other types
        that provide a swap member function, where those swap
        functions accept an rvalue reference
&#160;
  </TD>
<TD valign="top">
        Change promise::swap to take an rvalue
        reference.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1164">1164</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK342">UK 342</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/123">
     [123]
    </A></TD>
<TD valign="top">
30.5.6
&#160;
  </TD>
<TD valign="top">
        std::promise is
        missing a non-member overload of swap. This is inconsistent
        with other types that provide a swap member function
&#160;
  </TD>
<TD valign="top">
        Add a non-member overload void
        swap(promise&amp;&amp; x,promise&amp;&amp; y){ x.swap(y); }
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1088">1088</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>Solved by N2997.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK343">UK 343</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/439">
     [439]
    </A></TD>
<TD valign="top">
30.5.6

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
        The move constructor of a std::promise
        object does not need to allocate any memory, so the
        move-construct-with-allocator overload of the constructor
        is superfluous.
&#160;
  </TD>
<TD valign="top">
        Remove the
        constructor with the signature template &lt;class
        Allocator&gt; promise(allocator_arg_t, const Allocator&amp;
        a, promise&amp; rhs);
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1165">1165</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP81">JP 81</A></TD>
<TD valign="top">
30.5.8
&#160;
  </TD>
<TD valign="top">
        There are not requirements for F and a concept of Allocator
        dose not use.
&#160;
  </TD>
<TD valign="top">
        Correct as follows.
        <BR>
        
        <BR>
        template &lt;class F&gt;
        <BR>
        explicit packaged_task(F f);
        <BR>
        template &lt;class F, class Allocator&gt;
        <BR>
        explicit packaged_task(allocator_arg_t, const
        Allocator&amp; a, F f);
        <BR>
        template &lt;class F&gt;
        <BR>
        explicit packaged_task(F&amp;&amp; f);
        <BR>
        template &lt;class F, class Allocator&gt;
        <BR>
        explicit packaged_task(allocator_arg_t, const
        Allocator&amp; a, F&amp;&amp; f);
        <BR>
        
        <BR>
        should be
        <BR>
        
        <BR>
        template &lt;class F&gt;
        <BR>
        <u>requires CopyConstructible&lt;F&gt; &amp;&amp;
        Callable&lt;F, ArgTypes...&gt;</u>
        <BR>
        &amp;&amp; Convertible&lt;Callable&lt;F,
        ArgTypes...&gt;::result_type, R&gt;
        <BR>
        explicit packaged_task(F f);
        <BR>
        
        <BR>
        template &lt;class F, <u>Allocator Alloc</u>&gt;
        <BR>
        <u>requires CopyConstructible&lt;F&gt; &amp;&amp;
        Callable&lt;F, ArgTypes...&gt;</u>
        <BR>
        &amp;&amp; Convertible&lt;Callable&lt;F,
        ArgTypes...&gt;::result_type, R&gt;
        <BR>
        explicit packaged_task(allocator_arg_t, const
        <u>Alloc</u>&amp; a, F f);
        <BR>
        
        <BR>
        template &lt;class F&gt;
        <BR>
        <u>requires CopyConstructible&lt;F&gt; &amp;&amp;
        Callable&lt;F, ArgTypes...&gt;</u>
        <BR>
        &amp;&amp; Convertible&lt;Callable&lt;F,
        ArgTypes...&gt;::result_type, R&gt;
        <BR>
        explicit packaged_task(F&amp;&amp; f);
        <BR>
        
        <BR>
        template &lt;class F, <u>Allocator Alloc</u>&gt;
        <BR>
        <u>requires CopyConstructible&lt;F&gt; &amp;&amp;
        Callable&lt;F, ArgTypes...&gt;</u>
        <BR>
        &amp;&amp; Convertible&lt;Callable&lt;F,
        ArgTypes...&gt;::result_type, R&gt;
        <BR>explicit
        packaged_task(allocator_arg_t, const <u>Alloc</u>&amp; a,
        F&amp;&amp; f);
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1139">1139</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
All concepts-related text has been removed from the draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE23">DE 23</A></TD>
<TD valign="top">
Annex B

    &#182;
    
p2
&#160;
  </TD>
<TD valign="top">
        DE-23 Recursive
        use of constexpr functions appears to be permitted. Since
        such functions may be required to be evaluated at
        compile-time, Annex B "implementation quantities" should
        specify a maximum depth of recursion.
&#160;
  </TD>
<TD valign="top">
        In Annex B, specify a recursion depth of 256 or a larger
        value.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#699">699</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE24">DE 24</A></TD>
<TD valign="top">
Annex B

    &#182;
    
p2
&#160;
  </TD>
<TD valign="top">
        DE-24 The
        number of placeholders for "bind" is implementation-defined
        in 20.7.12.1.4, but no minimum is suggested in Annex B.
&#160;
  </TD>
<TD valign="top">
        Add a miminum of 10 placeholders to Annex B.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#922">922</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE25">DE 25</A></TD>
<TD valign="top">
Annex B

    &#182;
    
p2
&#160;
  </TD>
<TD valign="top">
        DE-25
        Specifying a minimum of 17 recursively nested template
        instantiations is too small for practical purposes. The
        limit is too high to effectively limit compiler resource
        usage, see
        http://ubiety.uwaterloo.ca/~tveldhui/papers/2003/turing.pdf
        . The conclusion is that the metric "number of recursively
        nested template instantiations" is inapposite.
&#160;
  </TD>
<TD valign="top">
        Remove the bullet "Recursively nested template
        instantiations [17]".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#831">831</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR38">FR 38</A></TD>
<TD valign="top">
C.2
        [diffs.library]

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
        What is ISO/IEC 1990:9899/DAM
        1? My guess is that's a typo for ISO/IEC
        <BR><BR>9899/Amd.1:1995 which I'd
        have expected to be referenced here (the tables
        <BR><BR>make reference to things
        which were introduced by Amd.1).
&#160;
  </TD>
<TD valign="top">
        One need probably a reference
        to the document which introduce char16_t and
        <BR><BR>char32_t in C (ISO/IEC TR 19769:2004?).
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1155">1155</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="UK344">UK 344</A><BR><A HREF="
      http://cxxpanel.org.uk/ballotcomment/136">
     [136]
    </A></TD>
<TD valign="top">
Appendix D
&#160;
  </TD>
<TD valign="top">
        It is desirable to allow some mechanism to
        support phasing out of deprecated features in the future.
        Allowing compilers to implement a mode where deprecated
        features are not available is a good first step.
&#160;
  </TD>
<TD valign="top">
        Add to the definition of deprecated
        features permission for compilers to maintain a
        conditionally supported mode where deprecated features can
        be disabled, so long as they also default to a mode where
        all deprecated features are supported.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Compiler switches and modes are quality-of-implementation issues and
outside the scope of the Standard.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FR39">FR 39</A></TD>
<TD valign="top">
Index
&#160;
  </TD>
<TD valign="top">
        Some definitions seem not
        indexed (such as <I>trivially copyable</I> or
        <I>sequenced before</I>), indexing
        them would be useful (and marking specially the page -- say
        bold or italic -- which reference to the definition would
        increase the usefulness; having a separate index of all
        definitions is something which could also be considered).
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
</TBODY>
</TABLE>
</BODY>
</HTML>
