<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    C++ FCD Comment Status
   </TITLE>
<STYLE>
    .ID {max-width:4%;}
    .Ref {max-width:6%;}
    .Comment {max-width:30%;}
    .Res {max-width:30%;}
    .Owner {max-width:6%}
    .Disp {max-width:20%}
   </STYLE>
</HEAD>
<BODY>
<TABLE align="right" cellspacing="0" cellpadding="0">
<TR>
<TD align="right">Document number:</TD>
<TD>&#160;N3770</TD>
</TR>
<TR>
<TD align="right">Date:</TD>
<TD>&#160;2013-10-14</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;Alisdair Meredith<BR>
      &#160;<A href="mailto://bdawes@acm.org">lwgchair@gmail.com</A></TD>
</TR>
</TABLE><BR><BR><BR><BR><BR><BR><BR><BR><BR><CENTER>
<H1>
     C++ CD Comment Status
    </H1>
<H2>Rev. 1</H2>
</CENTER>
<P>
    This document summarizes the status of WG21
    following the 2013-09 (Chicago) meting
    in addressing National Body
    comments on Committee Draft document N3690.
    It does not contain the results of the Library Working Group
    deliberations, which have not yet been fully processed.
   </P>
<P>
    In
    total, 85 comments
    were received. To date,
    24
    have been accepted as proposed,
    1
    have been accepted with modifications,
    11
    have been rejected, and
    49
    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">3</TD>
<TD align="center">23</TD>
<TD align="center">1</TD>
<TD align="center">9</TD>
<TD align="center">36</TD>
</TR>
<TR>
<TD><B>LWG</B></TD>
<TD align="center">42</TD>
<TD align="center">0</TD>
<TD align="center">0</TD>
<TD align="center">0</TD>
<TD align="center">42</TD>
</TR>
<TR>
<TD><B>editor</B></TD>
<TD align="center">1</TD>
<TD align="center">1</TD>
<TD align="center">0</TD>
<TD align="center">2</TD>
<TD align="center">4</TD>
</TR>
<TR>
<TD><B>Committee</B></TD>
<TD align="center">3</TD>
<TD align="center">0</TD>
<TD align="center">0</TD>
<TD align="center">0</TD>
<TD align="center">3</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 N3733; the &#8220;Disposition&#8221; field gives the
    response, as well as any explanatory comments provided by the
    responsible party.  The comments have been slightly modified for
    formatting and convenience of reference; any substantive changes
    are unintentional, and N3733 is the definitive repository of the
    content of comments.
   </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="
          #CH1">CH 1</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH2">CH 2</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH3">CH 3</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH4">CH 4</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH5">CH 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#1772">1772</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH6">CH 6</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#1762">1762</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH7">CH 7</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH8">CH 8</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH9">CH 9</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES1">ES 1</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES2">ES 2</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES3">ES 3</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2013-09-28&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3781_digits_separators.pdf">
          N3781</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES4">ES 4</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2013-09-28&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3781_digits_separators.pdf">
          N3781</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES5">ES 5</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2013-09-28&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3781_digits_separators.pdf">
          N3781</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES6">ES 6</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2013-09-28&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3781_digits_separators.pdf">
          N3781</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES7">ES 7</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#1717">1717</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES8">ES 8</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2013-09-28&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3778.html">
          N3778</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES9">ES 9</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES10">ES 10</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2013-09-28&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html">
          N3760</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES11">ES 11</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES12">ES 12</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES13">ES 13</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES14">ES 14</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES15">ES 15</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES16">ES 16</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES17">ES 17</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES18">ES 18</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES19">ES 19</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI1">FI 1</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI2">FI 2</A></TD>
<TD>LWG</TD>
<TD>&#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>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1670">1670</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI5">FI 5</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI6">FI 6</A></TD>
<TD>CWG</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>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI8">FI 8</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI9">FI 9</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI10">FI 10</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI11">FI 11</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI12">FI 12</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI13">FI 13</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2013-09-28&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3760.html">
          N3760</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI14">FI 14</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI15">FI 15</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#1776">1776</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI16">FI 16</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB1">GB 1</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#1759">1759</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB2">GB 2</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#1787">1787</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB3">GB 3</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#1760">1760</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB4">GB 4</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#1786">1786</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB5">GB 5</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB6">GB 6</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB7">GB 7</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB8">GB 8</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB9">GB 9</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB10">GB 10</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB11">GB 11</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB12">GB 12</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #NL1">NL 1</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2013-09-28&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3781_digits_separators.pdf">
          N3781</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US1">US 1</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US2">US 2</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US3">US 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#1441">1441</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US4">US 4</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US5">US 5</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#2075">2075</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US6">US 6</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2013-09-28&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3781_digits_separators.pdf">
          N3781</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US7">US 7</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2013-09-28&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3778.html">
          N3778</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US8">US 8</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2013-09-28&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html">
          N3760</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US9">US 9</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#1768">1768</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US10">US 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#1761">1761</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US11">US 11</A></TD>
<TD>CWG</TD>
<TD>rejected&#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>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US13">US 13</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#1579">1579</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US14">US 14</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US15">US 15</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US16">US 16</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#2118">2118</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US17">US 17</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US18">US 18</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US19">US 19</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#2232">2232</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US20">US 20</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US21">US 21</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US22">US 22</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US23">US 23</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US24">US 24</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US25">US 25</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US26">US 26</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US27">US 27</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US28">US 28</A></TD>
<TD>LWG</TD>
<TD>&#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="
          #CH1">CH 1</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH2">CH 2</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH3">CH 3</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI15">FI 15</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1776">1776</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US3">US 3</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1441">1441</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US4">US 4</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES15">ES 15</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH4">CH 4</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH7">CH 7</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH8">CH 8</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH9">CH 9</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES2">ES 2</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES11">ES 11</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES12">ES 12</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES13">ES 13</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES14">ES 14</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES16">ES 16</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES17">ES 17</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES18">ES 18</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES19">ES 19</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI2">FI 2</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI7">FI 7</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI9">FI 9</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI10">FI 10</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI11">FI 11</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI14">FI 14</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI16">FI 16</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB5">GB 5</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB7">GB 7</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB8">GB 8</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB9">GB 9</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB10">GB 10</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB12">GB 12</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US5">US 5</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#2075">2075</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US14">US 14</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US15">US 15</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US16">US 16</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#2118">2118</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US17">US 17</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US18">US 18</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US19">US 19</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#2232">2232</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US20">US 20</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US21">US 21</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US22">US 22</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US23">US 23</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US24">US 24</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US25">US 25</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US26">US 26</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US27">US 27</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US28">US 28</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
</TR>
</TBODY>
</TABLE>
<HR><A name="RR"></A><H2><U>ALL COMMENTS</U></H2><A NAME="CA1"></A><A NAME="CA2"></A><A NAME="CA3"></A><A NAME="CA4"></A><A NAME="CA5"></A><A NAME="CA6"></A><A NAME="CA7"></A><A NAME="CA8"></A><A NAME="CA9"></A><A NAME="CA10"></A><A NAME="CA11"></A><A NAME="CA12"></A><A NAME="CA13"></A><A NAME="CA14"></A><A NAME="CA15"></A><A NAME="CA16"></A><A NAME="CA17"></A><A NAME="CA18"></A><A NAME="CA19"></A><A NAME="CA20"></A><A NAME="CA21"></A><A NAME="CA22"></A><A NAME="CA23"></A><A NAME="CA24"></A><A NAME="CA25"></A><A NAME="CA26"></A><A NAME="CA27"></A><A NAME="CA28"></A><A NAME="CA29"></A><A NAME="CA30"></A><P>
    The Canadian CD comments are not contained in this document but
    can be found in
    <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3771.pdf">N3771</A>.
   </P>
<TABLE border="1" cellspacing="0" cellpadding="4" frame="box" width="800">
<THEAD>
<TR>
<TH width="4%" align="center" class="ID">ID</TH>
<TH width="6%" align="center" class="Ref">Ref</TH>
<TH width="30%" align="center" class="Comment">Comment</TH>
<TH width="30%" align="center" class="Res">Proposed Resolution</TH>
<TH width="6%" align="center" class="Owner">Owner</TH>
<TH width="4%" align="center" class="Issue">Issue</TH>
<TH width="20%" align="center" class="Disp">Disposition</TH>
</TR>
</THEAD>
<TBODY>
<TR>
<TD valign="top" class="ID"><A NAME="CH1">CH 1</A></TD>
<TD valign="top" class="Ref">
&#160;
  </TD>
<TD valign="top" class="Comment">

The active issues on the issues lists (WG21 N3674, N3682 and
N3687) shall be addressed before the standard becomes final.

&#160;
  </TD>
<TD valign="top" class="Res">


&#160;
  </TD>
<TD valign="top" class="Owner">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="CH2">CH 2</A></TD>
<TD valign="top" class="Ref">
&#160;
  </TD>
<TD valign="top" class="Comment">

C++14 is intended to be a bugfix release with minor new features.

&#160;
  </TD>
<TD valign="top" class="Res">

Remove any new feature if it negatively affects the quality of the standard.

&#160;
  </TD>
<TD valign="top" class="Owner">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="CH3">CH 3</A></TD>
<TD valign="top" class="Ref">
&#160;
  </TD>
<TD valign="top" class="Comment">

C++14 is intended to be a bugfix release with minor new features.

&#160;
  </TD>
<TD valign="top" class="Res">

Introduce no breaking changes for C++14.  This applies
specifically to 30.3.1 (<TT>~thread()</TT>) and 30.6.8
(<TT>~future()</TT> for asyncs).This also applies to
<TT>constexpr</TT> nonconst member functions, but for this
case the CH NB support is not unanimous.

&#160;
  </TD>
<TD valign="top" class="Owner">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES1">ES 1</A></TD>
<TD valign="top" class="Ref">
&#160;
  </TD>
<TD valign="top" class="Comment">

N3674 still includes many unsolved core issues

&#160;
  </TD>
<TD valign="top" class="Res">

Solve all the issues identified in N3674.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES2">ES 2</A></TD>
<TD valign="top" class="Ref">
&#160;
  </TD>
<TD valign="top" class="Comment">

N3687 still includes many unsolved library issues

&#160;
  </TD>
<TD valign="top" class="Res">

Solve all the issues identified in N3687.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="NL1">NL 1</A></TD>
<TD valign="top" class="Ref">
&#160;
  </TD>
<TD valign="top" class="Comment">

Reconsider adding digit separators, for example as proposed in N3661.

&#160;
  </TD>
<TD valign="top" class="Res">


&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3781_digits_separators.pdf">
     N3781</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US14">US 14</A></TD>
<TD valign="top" class="Ref">
(library)
&#160;
  </TD>
<TD valign="top" class="Comment">

Address open LWG Issues

&#160;
  </TD>
<TD valign="top" class="Res">

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" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI14">FI 14</A></TD>
<TD valign="top" class="Ref">
30.6
&#160;
  </TD>
<TD valign="top" class="Comment">

It is unfortunate that futures sometimes block in their
destructor and sometimes don't. There have been
recommendations to move the futures when unsure, and make
sure <TT>get()</TT> is invoked before the
destructor. However, not having a certainly blocking-future
in the standard leads to proliferation of custom solutions
to the same problem. Similarly, the lack of a
certainly-non-blocking future leads to such proliferation.

&#160;
  </TD>
<TD valign="top" class="Res">

It seems more future types should be added to establish
reasonable semantics. Note that we do not support changing
the return type of <TT>std::async</TT> due to these issues -
breaking <TT>std::async</TT> in any way is harmful to users who
already use it for what it was designed, and don't return
the futures from it so that there would be confusion about
the blocking.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US1">US 1</A></TD>
<TD valign="top" class="Ref">
All Clauses
&#160;
  </TD>
<TD valign="top" class="Comment">

In lists of specifications, the use of anonymous bullets
makes it difficult (in correspondence and speech) to refer
to individual list items.  Moreover, the longer the list,
the greater the opportunity to mistake the structure, most
especially in the presence of bullets in sublists.

&#160;
  </TD>
<TD valign="top" class="Res">

In all lists of bulleted items, provide a distinct numbered
or lettered identification in place of each bullet.  Because
paragraphs are already numbered, it seems best to use
letters for top-level list items within paragraphs and then
to use Roman numerals for any sublist items.  (A few parts
of the Standard already do this.)

&#160;
  </TD>
<TD valign="top" class="Owner">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     REJECTED
    <BR><BR>
We believe this is, in principle, a good suggestion, but the scope of
this change makes it more appropriate to explore the options for
enumeration of bullets in the next revision prior to the issuance of
a Committee Draft.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US15">US 15</A></TD>
<TD valign="top" class="Ref">
All Library Clauses
&#160;
  </TD>
<TD valign="top" class="Comment">

Given the adoption of N3655, it is possible to rephrase uses
of the type traits throughout and thus both simplify and
clarify the text.

&#160;
  </TD>
<TD valign="top" class="Res">

Replace each occurrence of the form
<I>cv</I> <TT>typename</TT>&#160;<I>typetrait</I><TT>&lt;...&gt;::type</TT>
or the form <I>cv&#160;typetrait</I><TT>&lt;...&gt;::type</TT>
by <I>cv&#160;typetrait</I><TT>_t&lt;...&gt;</TT>.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US4">US 4</A></TD>
<TD valign="top" class="Ref">
1.9, 1.10
&#160;
  </TD>
<TD valign="top" class="Comment">

Resolve CWG issues 1441, 1466, 1470 on concurrency. (lower priority).

&#160;
  </TD>
<TD valign="top" class="Res">


&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US3">US 3</A></TD>
<TD valign="top" class="Ref">
1.9, 1.10
&#160;
  </TD>
<TD valign="top" class="Comment">

The current standard accidentally and gratuitously restricts
signal handlers much more than was originally
intended. Conforming signal handlers cannot even use local
variables.  They cannot use atomic variables to avoid
undefined behaviour as was originally intended.

&#160;
  </TD>
<TD valign="top" class="Res">

Correct misstatements, and clarify that <TT>atomic&lt;T&gt;</TT>
operations can be used to communicate with signal handlers,
and that objects last modified before a signal handler was
installed can be safely examined in a signal handler,
e.g. by adopting N3633 or a refinement.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1441">1441</A>&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US5">US 5</A></TD>
<TD valign="top" class="Ref">
1.10, 29.4, 29.6.5
&#160;
  </TD>
<TD valign="top" class="Comment">

Resolve LWG issue 2075 on concurency.

&#160;
  </TD>
<TD valign="top" class="Res">


&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#2075">2075</A>&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI1">FI 1</A></TD>
<TD valign="top" class="Ref">
1-16
&#160;
  </TD>
<TD valign="top" class="Comment">

All Core issues with priorities zero or one up to and
including the Core Issues List published in the pre-Chicago
mailing shall be resolved

&#160;
  </TD>
<TD valign="top" class="Res">

As viewed fit by the Core Working Group

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US2">US 2</A></TD>
<TD valign="top" class="Ref">
1-16
&#160;
  </TD>
<TD valign="top" class="Comment">

The active issues identified in WG21 N3539, C++ Standard
Core Language Active Issues, must be addressed and
appropriate action taken.

&#160;
  </TD>
<TD valign="top" class="Res">

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" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US6">US 6</A></TD>
<TD valign="top" class="Ref">
2.14
&#160;
  </TD>
<TD valign="top" class="Comment">

Provide digit separators.

&#160;
  </TD>
<TD valign="top" class="Res">

See N3661.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3781_digits_separators.pdf">
     N3781</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES3">ES 3</A></TD>
<TD valign="top" class="Ref">
2.14.2
&#160;
  </TD>
<TD valign="top" class="Comment">

Reconsider adding digit separators for integer decimal literals.

&#160;
  </TD>
<TD valign="top" class="Res">

Add digit separators for integer decimal literals as
specified in N3661. No counter-example has been presented
for integer octal literals.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3781_digits_separators.pdf">
     N3781</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES4">ES 4</A></TD>
<TD valign="top" class="Ref">
2.14.2
&#160;
  </TD>
<TD valign="top" class="Comment">

Add digit separators for integer binary literals.

&#160;
  </TD>
<TD valign="top" class="Res">

No interaction has been identified with digit separators for
binary literals

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3781_digits_separators.pdf">
     N3781</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES5">ES 5</A></TD>
<TD valign="top" class="Ref">
2.14.2
&#160;
  </TD>
<TD valign="top" class="Comment">

Reconsider adding digit separators for integer octal literals

&#160;
  </TD>
<TD valign="top" class="Res">

Add digit separators for integer octal literals as specified
in N3661. No counter-example has been presented for integer
octal literals.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3781_digits_separators.pdf">
     N3781</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES6">ES 6</A></TD>
<TD valign="top" class="Ref">
2.14.2
&#160;
  </TD>
<TD valign="top" class="Comment">

Reconsider adding digit separator for integer hexadecimal literals

&#160;
  </TD>
<TD valign="top" class="Res">

A different solution can be evaluated for the conflicting
case of digit separators in hexadecimal literals. This case
could be solved by using a different prefix to indicate the
presence of digit separators.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3781_digits_separators.pdf">
     N3781</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES7">ES 7</A></TD>
<TD valign="top" class="Ref">
2.14.2

    &#182;
    
Tab 6
&#160;
  </TD>
<TD valign="top" class="Comment">

Header of last columns says:
Octal or hexadecimal constant
This does not include binary constants

&#160;
  </TD>
<TD valign="top" class="Res">

Modify accordingly table header.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1717">1717</A>&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="GB1">GB 1</A></TD>
<TD valign="top" class="Ref">
2.14.5

    &#182;
    
8
&#160;
  </TD>
<TD valign="top" class="Comment">

The string literal <TT>u8"&#192;"</TT> (that
is, <TT>u8"\u00c0"</TT>) creates a <TT>const char[3]</TT>
initialized by <TT>{ 0xc3, 0x80, 0 }</TT>. However,
<TT>char</TT> is not guaranteed to be able to represent
<TT>0x80</TT>.

&#160;
  </TD>
<TD valign="top" class="Res">

Change type of u8 string literals to <TT>unsigned char</TT>, or
require <TT>signed char</TT> to be able to represent 0x80.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1759">1759</A>&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES8">ES 8</A></TD>
<TD valign="top" class="Ref">
3.7.4
&#160;
  </TD>
<TD valign="top" class="Comment">

Member <TT>operator delete[]</TT> may take a second
parameter indicating the size of the object to be
deallocated. However, global <TT>operator delete[]</TT> does
not support this variant.

&#160;
  </TD>
<TD valign="top" class="Res">

Provide a global <TT>operator delete[]</TT> with an optional
size parameter along the lines of N3663.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3778.html">
     N3778</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="GB2">GB 2</A></TD>
<TD valign="top" class="Ref">
4.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top" class="Comment">

Reconsider resolution of core issue 616.  Under core issue
616, certain lvalue-to-rvalue conversions on uninitialized
objects of type <TT>unsigned char</TT> provide an unspecified value
with defined behavior. That is extremely harmful for
optimizers, since they must distinguish between a specific
unspecified value (which would compare equal to itself,
after being copied into another variable) and a
fully-uninitialized value.

&#160;
  </TD>
<TD valign="top" class="Res">

Further restrict loads of uninitialized <TT>unsigned
char</TT> such that the value can only be stored, and the
result of storing it is to make the destination contain an
indeterminate value.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1787">1787</A>&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES9">ES 9</A></TD>
<TD valign="top" class="Ref">
5.1.2
&#160;
  </TD>
<TD valign="top" class="Comment">

Closure objects are never literal types

&#160;
  </TD>
<TD valign="top" class="Res">

Consider allowing the generation of literal closure objects.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     REJECTED
    <BR><BR>
There was no consensus for the suggested change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="GB3">GB 3</A></TD>
<TD valign="top" class="Ref">
5.1.2

    &#182;
    
11
&#160;
  </TD>
<TD valign="top" class="Comment">

The access of the non-static data member declared for an
<I>init-capture</I> is not specified.

&#160;
  </TD>
<TD valign="top" class="Res">

Make the <I>init-capture</I> field unnamed, like other captures.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1760">1760</A>&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="GB4">GB 4</A></TD>
<TD valign="top" class="Ref">
5.3.4

    &#182;
    
8
&#160;
  </TD>
<TD valign="top" class="Comment">

We are concerned that the change in N3664 may change a small
memory leak into a large one.  Consider
<PRE>
class P {
  int x;
};
class Q {
public:
   Q(){ throw 42; }
private:
   int x[LARGE_NUMBER];
};
{
   P* p1 = new P();
   Q* q1 = new Q(); // bang :-(
   // don't get here
   delete q1;
   delete p1;
}
</PRE>
We fear, if the freedom of N3664 is exercised, that this
code block leaks a memory of size at least <TT>sizeof(P) +
sizeof(Q)</TT>.  The C++11 code would only leak the
allocation for <TT>p1</TT>, of size closer
to <TT>sizeof(P)</TT>.  This could result in programs with
an insignificant memory leak becoming ones with a more
serious leak.

&#160;
  </TD>
<TD valign="top" class="Res">


&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1786">1786</A>&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES10">ES 10</A></TD>
<TD valign="top" class="Ref">
7.6
&#160;
  </TD>
<TD valign="top" class="Comment">

<TT>[[deprecated]]</TT> attribute is missing from the CD.

&#160;
  </TD>
<TD valign="top" class="Res">

Apply N3394 to the CD.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html">
     N3760</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US8">US 8</A></TD>
<TD valign="top" class="Ref">
7.6
&#160;
  </TD>
<TD valign="top" class="Comment">

Paper N3394, "<TT>[[deprecated]]</TT> attribute," was
intended to be included in the CD, but it was
unintentionally omitted due to administrative issues.

&#160;
  </TD>
<TD valign="top" class="Res">

Incorporate the changes from that paper for the final draft.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html">
     N3760</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US10">US 10</A></TD>
<TD valign="top" class="Ref">
8.3.4

    &#182;
    
1
&#160;
  </TD>
<TD valign="top" class="Comment">

The next bullet item appears to the reference the "Size of
an object" limit in Annex B.  However, in many
implementations, object size limits on the stack are quite
different from other object size limits, and the limit is
very dynamic (especially in the presence of recursion).  A
check against an fixed (and arbitrary) limit will only cover
a subset of the size values that are problematic.  In total,
we throw on:
<UL>
<LI>negative values and zero (first bullet)</LI>
<LI>object sizes above the limit</LI>
</UL>
We do not throw for:
<UL>
<LI>object sizes which can be allocated successfully</LI>
<LI>object sizes which cannot be allocated successfully on
the stack, but are less than the object size limit</LI>
</UL>
The second item creates significant unpredictability for
programmers.  Existing VLA implementations for C and C++
lack fully deterministic stack size checks.  Obtaining stack
is fairly difficult in widely deployed environments (both in
terms of availability of the metric and high-performance
access to it).  An exact check against the dynamic limit is
difficult to implement, and would not even cover other
causes of stack overflow.

&#160;
  </TD>
<TD valign="top" class="Res">

Do not check at runtime whether the allocated array would
exceed the implementation-defined limit on object size.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1761">1761</A>&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US9">US 9</A></TD>
<TD valign="top" class="Ref">
8.3.4

    &#182;
    
1
&#160;
  </TD>
<TD valign="top" class="Comment">

The draft currently requires that if a runtime bound
evaluates to 0 at run-time, and exception is thrown.  This
means that correct C99 code that is also well-formed C++14
code, and has worked fine under the widespread VLA
extensions to C++, will fail at runtime; affected code was
encountered immediately after the proposal was implemented
in G++.
A check for negative values makes sense and can be avoided
by the programmer by using an unsigned type for the
expression.  The check against 0 would still be required by
the current draft, and is not required by typical VLA usage
(because the code deals correctly with this boundary case).
It is also surprising because <TT>operator new[]</TT> lacks
such a check.<BR>
This is a VERY CRITICAL ISSUE..

&#160;
  </TD>
<TD valign="top" class="Res">

Allow an array of runtime bound that evaluates to 0 at run-time.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1768">1768</A>&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US11">US 11</A></TD>
<TD valign="top" class="Ref">
8.3.4, etc.
&#160;
  </TD>
<TD valign="top" class="Comment">

Two distinct terms of art, <I>bound</I> and <I>extent</I>,
are now used to denote an array's number of elements. For
both consistency and improved technical accuracy, a single
term of art should be adopted and used throughout the
standard.

&#160;
  </TD>
<TD valign="top" class="Res">

Because <I>extent</I> is the user-visible term used in the
Library's interface, its consistent use would avoid
breaking existing programs.  See the wording proposed in
N3549.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     REJECTED
    <BR><BR>
The term &#8220;bound&#8221; is widely used and understood and provides
a point of compatibility with C for features shared by both languages.
There was no consensus to make this change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="CH4">CH 4</A></TD>
<TD valign="top" class="Ref">
8.3.4,
23.3.4
&#160;
  </TD>
<TD valign="top" class="Comment">

VLAs without <TT>dynarray</TT> is giving wrong direction, and
<TT>dynarray</TT> without full allocator support is just wrong.

&#160;
  </TD>
<TD valign="top" class="Res">

Add full allocator support to <TT>dynarray</TT> or remove
both, <TT>dynarray</TT> and VLAs completely.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="CH5">CH 5</A></TD>
<TD valign="top" class="Ref">
8.4.1

    &#182;
    
8
&#160;
  </TD>
<TD valign="top" class="Comment">

It's unclear from the text that <TT>__func__</TT> is allowed
in non function context lambda expressions, i.e., namespace
level lambda expressions in initializers.

&#160;
  </TD>
<TD valign="top" class="Res">

Specify that <TT>__func__</TT> is allowed in such contexts.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1772">1772</A>&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US12">US 12</A></TD>
<TD valign="top" class="Ref">
12.8

    &#182;
    
31
&#160;
  </TD>
<TD valign="top" class="Comment">

<TT>std::move</TT> inhibits copy elision, and so can be a pessimization

&#160;
  </TD>
<TD valign="top" class="Res">

Ignore calls
to <TT>std::move</TT>, <TT>std::move_if_noexcept</TT>, and
casts to rvalue reference type when determining whether copy
elision is permitted

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     REJECTED
    <BR><BR>
There was no consensus for the suggested change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US13">US 13</A></TD>
<TD valign="top" class="Ref">
12.8

    &#182;
    
32
&#160;
  </TD>
<TD valign="top" class="Comment">

Returning a local variable should always imply move semantics.

&#160;
  </TD>
<TD valign="top" class="Res">

In return statement, when the expression is the name of a
non-volatile automatic object, the expression should be
treated as an rvalue for purposes of overload resolution,
even if it does not have the same cv-unqualified type as the
function return type.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1579">1579</A>&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="CH6">CH 6</A></TD>
<TD valign="top" class="Ref">
13.5.8

    &#182;
    
8
&#160;
  </TD>
<TD valign="top" class="Comment">

<PRE>
float operator ""E(const char*);// OK
</PRE>
should be
<PRE>
float operator ""E(const char*);// OK, but reserved
                                // (17.6.4.3.5) [usrlit.suffix]
</PRE>

&#160;
  </TD>
<TD valign="top" class="Res">

Change the example accordingly.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1762">1762</A>&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI2">FI 2</A></TD>
<TD valign="top" class="Ref">
17-30
&#160;
  </TD>
<TD valign="top" class="Comment">

All Library issues up to and including the Library Issues
List published in the pre-Chicago mailing shall be resolved

&#160;
  </TD>
<TD valign="top" class="Res">

As viewed fit by the Library Working Group

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="GB5">GB 5</A></TD>
<TD valign="top" class="Ref">
20.2.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top" class="Comment">

The wording describes example code including the call of a
move constructor, but there is no requirement stated
that <TT>T</TT> be move constructible.

&#160;
  </TD>
<TD valign="top" class="Res">

We would like to add a new Para 1 before existing paragraph:<BR>
<I>Requires:</I> Type <TT>T</TT> shall
be <TT>MoveConstructible</TT> (Table 20)
and <TT>MoveAssignable</TT> (Table 22).<BR>
However the <TT>MoveAssignable</TT> concept currently does
not cover cases where the source and destination types may
differ.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES11">ES 11</A></TD>
<TD valign="top" class="Ref">
20.4.2.4

    &#182;
    
5-6
&#160;
  </TD>
<TD valign="top" class="Comment">

<TT>forward_as_tuple</TT> is not currently <TT>constexpr</TT>

&#160;
  </TD>
<TD valign="top" class="Res">

Make <TT>forward_as_tuple</TT> <TT>constexpr</TT>.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="CH7">CH 7</A></TD>
<TD valign="top" class="Ref">
20.5.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top" class="Comment">

The example uses the names <TT>index_sequence</TT>
and <TT>make_index_sequence</TT> whereas the following
sections define <TT>integer_sequence</TT>
and <TT>make_integer_sequence</TT>.

&#160;
  </TD>
<TD valign="top" class="Res">

Change the names in the example accordingly.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES12">ES 12</A></TD>
<TD valign="top" class="Ref">
20.6.4
&#160;
  </TD>
<TD valign="top" class="Comment">

Without <TT>operator !=</TT> users need to evaluate
expressions like <TT>!(a==b)</TT> instead of <TT>(a!=b)</TT>

&#160;
  </TD>
<TD valign="top" class="Res">

Add <TT>operator!=</TT>  for <TT>optional&lt;T&gt;</TT>

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US16">US 16</A></TD>
<TD valign="top" class="Ref">
20.9.1.3
&#160;
  </TD>
<TD valign="top" class="Comment">

Resolve LWG issue 2118 on <TT>unique_ptr</TT>.

&#160;
  </TD>
<TD valign="top" class="Res">


&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#2118">2118</A>&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES13">ES 13</A></TD>
<TD valign="top" class="Ref">
20.10.11.2
&#160;
  </TD>
<TD valign="top" class="Comment">

Polymorphic function wrappers do not take move-only callable
types in their constructor.

&#160;
  </TD>
<TD valign="top" class="Res">

Provide a mechanism to pass move-only callable types to
polymorphic function wrappers.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US17">US 17</A></TD>
<TD valign="top" class="Ref">
20.10.11.2
&amp;
30.6.9
&#160;
  </TD>
<TD valign="top" class="Comment">

Provide a way to pass a <TT>packaged_task&lt;T()&gt;</TT> to
a function accepting <TT>function&lt;void()&gt;</TT> or
another type-erasing callable-wrapper.
This is important for concurrency constructs where we need
to pass tasks between threads using queues. These queues
must store a type general enough to represent any task,
which includes a task for filling in a
<TT>future&lt;&gt;</TT>. However, <TT>function&lt;&gt;</TT>
currently doesn't accept move-only types
like <TT>packaged_task&lt;&gt;</TT>, so it's not sufficient
for the value-type of these queues.

&#160;
  </TD>
<TD valign="top" class="Res">

Either change <TT>function&lt;&gt;</TT> to accept move-only callable types, probably by refcounting the callable, or provide a separate class to turn a move-only callable into a copyable
callable.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US18">US 18</A></TD>
<TD valign="top" class="Ref">
20.11.4.3

    &#182;
    
6
&#160;
  </TD>
<TD valign="top" class="Comment">

The trait <TT>is_constructible&lt;T, Args...&gt;</TT> is
defined in terms of a helper
template, <TT>create&lt;&gt;</TT>, that is identical
to <TT>std::declval&lt;&gt;</TT> except for the latter's
<TT>noexcept</TT> clause.

&#160;
  </TD>
<TD valign="top" class="Res">

If the absence of <TT>noexcept</TT> is critical to this
definition, insert a Note of explanation; otherwise, excise
<TT>create&lt;&gt;</TT> and reformulate in terms
of <TT>declval&lt;&gt;</TT> the definition of
<TT>is_constructible</TT>.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US19">US 19</A></TD>
<TD valign="top" class="Ref">
21.2.3
&#160;
  </TD>
<TD valign="top" class="Comment">

Resolve LWG issue 2232

&#160;
  </TD>
<TD valign="top" class="Res">

Proposed Change: Add <TT>constexpr</TT> to <TT>char_traits</TT>
functions. As a second- best option, resolve LWG issue 2013
to allow libraries to do this as an extension.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#2232">2232</A>&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES14">ES 14</A></TD>
<TD valign="top" class="Ref">
21.2.3.1,
21.2.3.2,
21.2.3.3,
21.2.3.4
&#160;
  </TD>
<TD valign="top" class="Comment">

The following functions are not <TT>constexpr</TT>
in <TT>char_traits</TT> specializations
for <TT>char</TT>, <TT>char16_t</TT>, <TT>char32_t</TT>,
and <TT>wchar_t</TT>:
<PRE>
compare()
length()
find()
</PRE>
However, with the addition N3652 a recursive implementation
is not needed. Thus they can be easily and efficiently made
<TT>constexpr</TT>.

&#160;
  </TD>
<TD valign="top" class="Res">

Make those functions <TT>constexpr</TT> for the mentioned specializations.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="GB6">GB 6</A></TD>
<TD valign="top" class="Ref">
22.4.1
&#160;
  </TD>
<TD valign="top" class="Comment">

17.5.2.3 [objects.within.classes] defines the use of
&#8220;exposition only&#8221; in the library:
<BLOCKQUOTE>
The declarations for such member objects and the definitions
of related member types are followed by a comment that ends
with <I>exposition only</I>,
</BLOCKQUOTE>
22.4.1 [category.ctype] has members which are preceded (not
followed) by a comment ending &#8220;exposition only&#8221;.  and
28.12.1 [re.regiter] and 28.12.2 [re.tokiter]

&#160;
  </TD>
<TD valign="top" class="Res">

Reformat to follow 17.25.2.3

&#160;
  </TD>
<TD valign="top" class="Owner">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     REJECTED
    <BR><BR>
The use of &#8220;exposition only&#8221; in [category.ctype] applies to
constants, not members, and the members themselves are explicitly not
exposition-only members.  Therefore, the formatting rules laid out in
[objects.within.classes] do not apply in this case.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="GB7">GB 7</A></TD>
<TD valign="top" class="Ref">
23.2.1

    &#182;
    
4
&#160;
  </TD>
<TD valign="top" class="Comment">

Table 98 refers to <TT>a</TT> and <TT>b</TT> without
defining them. Obviously they are the same as in Tables 96
and 97 but paragraph 23.2.1 / 4 fails to mention Table 98.

&#160;
  </TD>
<TD valign="top" class="Res">

Add Table 98 to the scope of paragraph 23.2.1 / 4:
In Tables 96, 97 and 98, <TT>X</TT> denotes ...

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES15">ES 15</A></TD>
<TD valign="top" class="Ref">
23.2.4

    &#182;
    
8
&#160;
  </TD>
<TD valign="top" class="Comment">

Terminology for table 102 states that <TT>u</TT> denotes an
identifier, yet <TT>u</TT> is not further referred to.

&#160;
  </TD>
<TD valign="top" class="Res">

Delete &#8220;, <TT>u</TT> denotes an identifier.&#8221;

&#160;
  </TD>
<TD valign="top" class="Owner">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES16">ES 16</A></TD>
<TD valign="top" class="Ref">
23.2.4

    &#182;
    
8
&#160;
  </TD>
<TD valign="top" class="Comment">

The condition &#8220;<TT>X::key_compare::is_transparent</TT>
exists&#8221; does not specify that the type be publicly
accessible.

&#160;
  </TD>
<TD valign="top" class="Res">

Consider the public accessibility of
<TT>X::key_compare::is_transparent</TT> and whether its
potential inaccesibility should be banned for a
compliant <TT>key_compare</TT> type.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="GB8">GB 8</A></TD>
<TD valign="top" class="Ref">
23.3.4
&#160;
  </TD>
<TD valign="top" class="Comment">

The current spec for <TT>std::dynarray</TT> is contradictory
and broken, these open issues should be addressed:
<UL>
<LI><A HREF="http://cplusplus.github.io/LWG/lwg-active.html">LWG 2253</A></LI>
<LI><A HREF="http://cplusplus.github.io/LWG/lwg-active.html">LWG 2254</A></LI>
<LI><A HREF="http://cplusplus.github.io/LWG/lwg-active.html">LWG 2255</A></LI>
<LI><A HREF="http://cplusplus.github.io/LWG/lwg-active.html">LWG 2264</A></LI>
</UL>

&#160;
  </TD>
<TD valign="top" class="Res">

See related LWG issues
at <A HREF="http://cplusplus.github.io/LWG/lwg-active.html">http://cplusplus.github.io/LWG/lwg-active.html</A>

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES17">ES 17</A></TD>
<TD valign="top" class="Ref">
23.4.4.5,
23.4.5.4
&#160;
  </TD>
<TD valign="top" class="Comment">

Sections are redundant with general associative container
requirements at 23.2.4, table 102.

&#160;
  </TD>
<TD valign="top" class="Res">

Delete sections.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES18">ES 18</A></TD>
<TD valign="top" class="Ref">
24.4
&#160;
  </TD>
<TD valign="top" class="Comment">

Current standard stream does not provide a mechanism for synchronized I/O

&#160;
  </TD>
<TD valign="top" class="Res">

Provide a simple mechanism for performing synchronized I/O
in multithreaded environments.  See N3678

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US20">US 20</A></TD>
<TD valign="top" class="Ref">
26
&#160;
  </TD>
<TD valign="top" class="Comment">

The Bristol meeting postponed consideration of N3648 because
it was assumed that, if adopted, the proposal could be
issued in some future Technical Specification.  However,
N3648 proposes to merge ISO/IEC 29124 into C++14, and it is
unclear whether this would even be possible in a TS.
Further, such merger is time-sensitive, since ISO/IEC 29124
will be up for review in 2015 and, if merged into C++14, can
be retired (&#8220;withdrawn&#8221;) at that time.

&#160;
  </TD>
<TD valign="top" class="Res">

Review and adopt for C++14 the proposal in N3648 (or in a
successor document, if any).

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="CH8">CH 8</A></TD>
<TD valign="top" class="Ref">
26.4
&#160;
  </TD>
<TD valign="top" class="Comment">

Specify user-defined literals for standard complex types.

&#160;
  </TD>
<TD valign="top" class="Res">

Accept ISO/IEC JTC1 SC22 WG21 N3660 with the modification to
use <TT>operator""if</TT> for complex.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US22">US 22</A></TD>
<TD valign="top" class="Ref">
27.4.1

    &#182;
    
4
&#160;
  </TD>
<TD valign="top" class="Comment">

Enable standard stream synchronization.

&#160;
  </TD>
<TD valign="top" class="Res">

See N3535, N3665, N3678

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="GB9">GB 9</A></TD>
<TD valign="top" class="Ref">
27.9.2

    &#182;
    
Tab 134
&#160;
  </TD>
<TD valign="top" class="Comment">

C11 no longer defines the dangerous <TT>gets()</TT>
function. Even if we still refer to C99, which includes
<TT>gets()</TT>, it would be preferable to
strike <TT>std::gets()</TT> from <TT>&lt;cstdio&gt;</TT>

&#160;
  </TD>
<TD valign="top" class="Res">

<UL>
<LI>Remove gets from Table 134 and Table 153.</LI>
<LI>Add a note to [c.files] saying the C function <TT>gets()</TT> is
not part of C++ </LI>
<LI>Add the removal of <TT>gets</TT> to Annex C.3.</LI>
</UL>

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="GB10">GB 10</A></TD>
<TD valign="top" class="Ref">
28.7

    &#182;
    
12
&#160;
  </TD>
<TD valign="top" class="Comment">

The current wording is totally broken. Even if the whole
proposed resolution
at <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#2018</A>
isn't accepted the &#8220;bitwise or&#8221; part must be fixed.

&#160;
  </TD>
<TD valign="top" class="Res">

Accept the proposed resolution.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="GB11">GB 11</A></TD>
<TD valign="top" class="Ref">
28.12

    &#182;
    
1, 2
&#160;
  </TD>
<TD valign="top" class="Comment">

17.5.2.3 [objects.within.classes] defines the use of
&#8220;exposition only&#8221; in the library:
<BLOCKQUOTE>
The declarations for such member objects and the definitions
of related member types are followed by a comment that ends
with <I>exposition only</I>,
</BLOCKQUOTE>
28.12.1 [re.regiter] and 28.12.2 [re.tokiter] have members
which are preceded (not followed) by a comment ending
&#8220;exposition only&#8221;.

&#160;
  </TD>
<TD valign="top" class="Res">

Reformat to follow 17.25.2.3

&#160;
  </TD>
<TD valign="top" class="Owner">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US23">US 23</A></TD>
<TD valign="top" class="Ref">
29
&#160;
  </TD>
<TD valign="top" class="Comment">

Resolve LWG issues 2130, 2138, 2159, 2165 on atomics.

&#160;
  </TD>
<TD valign="top" class="Res">


&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US27">US 27</A></TD>
<TD valign="top" class="Ref">
30
&#160;
  </TD>
<TD valign="top" class="Comment">

Resolve LWG issues 2080, 2097, 2100, 2104, 2120, 2135, 2142,
2185, 2186, 2190 on threads.

&#160;
  </TD>
<TD valign="top" class="Res">


&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US28">US 28</A></TD>
<TD valign="top" class="Ref">
30
&#160;
  </TD>
<TD valign="top" class="Comment">

Resolve LWG issues 2095, 2098, 2140, 2202 on threads. (lower priority)

&#160;
  </TD>
<TD valign="top" class="Res">


&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="ES19">ES 19</A></TD>
<TD valign="top" class="Ref">
30.3.1.3
&#160;
  </TD>
<TD valign="top" class="Comment">

<TT>std::thread</TT> destructor calls <TT>terminate()</TT>
if the thread has not been joined. Changing this behaviour
is unacceptable for existing code.

&#160;
  </TD>
<TD valign="top" class="Res">

A different compatible class or wrapper should be provided
to support RAII pattern and joining on destruction.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US25">US 25</A></TD>
<TD valign="top" class="Ref">
30.3.1.3
&#160;
  </TD>
<TD valign="top" class="Comment">

(Small defect) It is a defect that the <TT>thread</TT> destructor
calls <TT>terminate()</TT> if the thread has not been joined. Thread
is an RAII type and if the user is required to explicitly
call <TT>.join()</TT> or similar in all cases if it has not been
called already, this should be done automatically.

&#160;
  </TD>
<TD valign="top" class="Res">

A resolution along the lines of that proposed in paper
WG21/N3636 or similar would be acceptable.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US24">US 24</A></TD>
<TD valign="top" class="Ref">
30.6
&#160;
  </TD>
<TD valign="top" class="Comment">
(Severe defect) Like iterators, futures are essential
vocabulary types whose major benefit is to permit
composability between various providers (containers, async
launchers) and consumers (algorithms, async consumers). To
be usable as such, they must work predictably.
It is a serious defect that <TT>~future</TT>
and <TT>~shared_future</TT> might block unpredictably,
depending only on whether the provider was launched
with <TT>std::async</TT>. In all cases in the standard
except where the provider is launched
with <TT>std::async</TT>, <TT>~future</TT> does not block;
if it is launched with <TT>std::async</TT>, it may
block.
We understand there are desirable reasons to block (such as
to achieve structured resource lifetime control) and not
block (such as to achieve responsive nonblocking
concurrency), but this decision should be up to each
consumer of a given future to select explicitly, not baked
inscrutably into an unpredictably dual-mode single future
object whose consumer cannot select the appropriate behavior
and furthermore the current workarounds to do so are
effectively unusable.
Futures may or may not block in their destructor, depending
on how they were created.  Many clients must rely on one
behavior or the other, making it impossible to use futures
as the general communication mechanism they would like to
be.

&#160;
  </TD>
<TD valign="top" class="Res">

A resolution along the lines of that proposed in paper
WG21/N3637 or similar would be acceptable.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="GB12">GB 12</A></TD>
<TD valign="top" class="Ref">
30.6.6

    &#182;
    
9
&#160;
  </TD>
<TD valign="top" class="Comment">

Make it explicit that <TT>~future</TT> and
<TT>~shared_future</TT> may block if the future originates
from <TT>std::async</TT>.

&#160;
  </TD>
<TD valign="top" class="Res">

Add notes to 30.6.6p9, 30.6.6p10, 30.6.7p11, 30.6.7p12 and
30.6.7p14 after the &#8220;releases any shared state&#8221;
part of the effects saying
<BLOCKQUOTE>
[<I>Note:</I> If this is
the last reference to the shared state from a call
to <TT>std::async</TT> with a policy
of <TT>std::launch::async</TT>, then this will wait for the
async task to complete (30.6.8p5) &#8212;<I>end
note</I>]
</BLOCKQUOTE>
Add a note to the first bullet of 30.6.4p5:
<BLOCKQUOTE>
[<I>Note:</I> this may cause the function that released the shared
state to block if this is the last reference to the shared
state from a call to <TT>std::async</TT> with a policy of
<TT>std::launch::async</TT> (30.6.8p5) &#8212;<I>end
note</I>]
</BLOCKQUOTE>

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US26">US 26</A></TD>
<TD valign="top" class="Ref">
30.6.8
&#160;
  </TD>
<TD valign="top" class="Comment">

Deprecate <TT>std::async</TT> due to the inability to
reconcile the blocking semantics of the destructor of the
returned values with the growing expected semantics
of <TT>std::future</TT>'s destruction. The problems of this
inconsistency are outlined in N3630, but the solutions there
didn't work. Another solution was proposed in N3637 which
also did not satisfy people. Thus, we request to simply
deprecate the problematic feature without changing any
behavior in the library, and pave a path forward with new
functionality that addresses these concerns.

&#160;
  </TD>
<TD valign="top" class="Res">

Mark <TT>std::async</TT> as deprecated to help discourage
its use and to reconcile the necessity of advising
programmers to never pass or return the <TT>std::future</TT>
received from <TT>std::async</TT> across an interface
boundary.
Change either 3.6.6p9 to specify that
the <TT>std::future</TT> destructor does not block except
when the value is one returned by the
deprecated <TT>std::async</TT> function (or change 3.6.4p5
to specify the equivalent in terms of the shared state).

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI15">FI 15</A></TD>
<TD valign="top" class="Ref">
3.8

    &#182;
    
7
&#160;
  </TD>
<TD valign="top" class="Comment">

See <A HREF="https://groups.google.com/a/isocpp.org/d/msg/std-proposals/93ebFsxCjvQ/myxPG6o_9pkJ">https://groups.google.com/a/isocpp.org/d/msg/std-proposals/93ebFsxCjvQ/myxPG6o_9pkJ</A><BR>

It seems that the restrictions of class types with reference
members potentially cause a very hard implementation
problem. It's palatable to re-fetch pointers and references,
but how does one refresh a named reference to storage that
was destroyed and re-initialized with placement new?
In Ivchenkov's example, is it sufficient to destroy the
<TT>storage_</TT> union and re-initialize the whole union,
instead of just its <TT>value</TT> member?

&#160;
  </TD>
<TD valign="top" class="Res">

Clarify what poor programmers need to do if they want to
destroy+placement-new-initialize an object of class type,
avoiding problems with reference members.  Alternatively,
consider the solutions presented by Ivchenkov. Our
preference leans towards the direction of solutions 5 and 6.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1776">1776</A>&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI6">FI 6</A></TD>
<TD valign="top" class="Ref">
12.1

    &#182;
    
8
&#160;
  </TD>
<TD valign="top" class="Comment">

In a function returning <TT>void</TT>, <TT>return E;</TT>
where <TT>E</TT> is of type <TT>void</TT> is permitted.  In
contrast, for constructors and destructors, this is not
allowed, which is an arbitrary restriction for a corner
case.

&#160;
  </TD>
<TD valign="top" class="Res">

Remove the prohibition for <TT>return E;</TT>
where <TT>E</TT> is of type <TT>void</TT> in constructors
and destructors.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     REJECTED
    <BR><BR>
There was no consensus for the suggested change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="CH9">CH 9</A></TD>
<TD valign="top" class="Ref">
D.7
&#160;
  </TD>
<TD valign="top" class="Comment">

<TT>strstream</TT> is dangerous to use and the interface
does not fulfill current library requirements.

&#160;
  </TD>
<TD valign="top" class="Res">

Delete D.7 from the standard.<BR>
The CH NB is aware that this proposed change conflicts with
the comment to not introduce any breaking changes. So the CH
NB support for this comment is not unanimous.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI13">FI 13</A></TD>
<TD valign="top" class="Ref">
7.6.1
&#160;
  </TD>
<TD valign="top" class="Comment">

It seems that a <TT>[deprecated]</TT> attribute fell between
the cracks in the EWG-&gt;CWG workflow.

&#160;
  </TD>
<TD valign="top" class="Res">

Flush the pipeline and add the <TT>[deprecated]</TT>
attribute as proposed in N3394.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/N3760.html">
     N3760</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI3">FI 3</A></TD>
<TD valign="top" class="Ref">
7.1.6.4

    &#182;
    
6
&#160;
  </TD>
<TD valign="top" class="Comment">

As proposed in N3681, an <TT>auto</TT> specifier should not
result in an <TT>initializer_list</TT> when used with a
<I>braced-init-list</I>.

&#160;
  </TD>
<TD valign="top" class="Res">

Adopt the solution proposed in N3681, make <TT>auto</TT> not
deduce an <TT>initializer_list</TT> from
a <I>braced-init-list</I> of a single element,
make <TT>auto</TT> with a <I>braced-init-list</I> of
multiple elements ill-formed

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     REJECTED
    <BR><BR>
There was no consensus for the suggested change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI4">FI 4</A></TD>
<TD valign="top" class="Ref">
7.1.6.4

    &#182;
    
2
&#160;
  </TD>
<TD valign="top" class="Comment">

Function return type deduction also covers conversion
functions, that is <TT>operator auto</TT>. This is
undesirable, because the whole point of a conversion
function is to have an explicit (not implicitly deduced)
return type.  Also, only a single <TT>operator auto</TT>
conversion function can exist in a class, limiting its
utility.

&#160;
  </TD>
<TD valign="top" class="Res">

Exclude conversion functions from return type
deduction. Strike <I>conversion-function-id</I> from
paragraph 2.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1670">1670</A>&#160;
  </TD>
<TD valign="top" class="Disp">
     REJECTED
    <BR><BR>
There was no consensus for the suggested change.  The corresponding
core language issue, 1670, remains open to clarify the handling or
reconsider the decision in a future revision of the Standard.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI5">FI 5</A></TD>
<TD valign="top" class="Ref">
7.1.6.4

    &#182;
    
2
&#160;
  </TD>
<TD valign="top" class="Comment">

Function return type deduction avoids the need to repeat the
function body to specify the return type in function
templates, e.g. the <TT>-&gt; decltype(x1+x2)</TT> below is
redundant:
<PRE>
 template&lt;class T&gt;
 auto f(T x1, T x2) -&gt; decltype(x1+x2) { return x1+x2; }
</PRE>
However, that syntax does not cover exception specifications, again necessitating to repeat the function body:
<PRE>
 template&lt;class T&gt;
 auto f(T x1, T x2) noexcept(noexcept(x1+x2)) { return x1+x2; }
</PRE>
The specification machinery is readily available with core
issue 1351, and the concerns about instantiating definitions
to determine properties of the declaration have already been
addressed with the introduction of function return type
deduction.

&#160;
  </TD>
<TD valign="top" class="Res">

Reconsider <TT>noexcept(auto)</TT>, or extend the meaning
of <TT>auto</TT> return types to cause exception
specification deduction, or find another syntactic means to
express deduction of exception specifications.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     REJECTED
    <BR><BR>
There was no consensus for the suggested change at this time, but there
was interest in exploring the possibility for a future revision.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI8">FI 8</A></TD>
<TD valign="top" class="Ref">
5.1.2
&#160;
  </TD>
<TD valign="top" class="Comment">

A closure object is not of a literal type, the function call
operator of a closure object type is not
ever <TT>constexpr</TT>. These restrictions mean that
lambdas cannot be used in constant expression. It seems
unfortunate that lambdas and constant expressions do not
work together. One of the benefits of relaxing the
restrictions of constant expressions was that that
relaxation allows writing template code that can
be <TT>constexpr</TT> but is not sub-optimal at run-time and
vice versa. It would seem reasonable to allow lambdas to be
used in such code.

&#160;
  </TD>
<TD valign="top" class="Res">

Allow lambdas to be used in constant expressions, if the
captures of the lambda are of literal type, and if the call
operator of the closure object type fulfils the requirements
for a constant expression otherwise.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     REJECTED
    <BR><BR>
There was no consensus for the suggested change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI9">FI 9</A></TD>
<TD valign="top" class="Ref">
20.6.8
&#160;
  </TD>
<TD valign="top" class="Comment">

It is unacceptable that <TT>optional</TT> doesn't have
an <TT>operator!=</TT>.

&#160;
  </TD>
<TD valign="top" class="Res">

Define <TT>operator!=</TT> as the negation of <TT>operator==</TT>

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI10">FI 10</A></TD>
<TD valign="top" class="Ref">
20.6.8
&#160;
  </TD>
<TD valign="top" class="Comment">

It is unacceptable that <TT>optional</TT> doesn't
have <TT>operator&gt;</TT>, <TT>operator&lt;=</TT>
etc. relational operators in addition
to <TT>operator&lt;</TT>.

&#160;
  </TD>
<TD valign="top" class="Res">

Define relational operators as they are defined
for <TT>tuple</TT> and containers. In addition, adopt FI 7
to add a specialization of <TT>std::less</TT>
for <TT>optional&lt;T*&gt;</TT>.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI7">FI 7</A></TD>
<TD valign="top" class="Ref">
20.3.3, 20.4.2.9, 23.2.1, 10.10.5
&#160;
  </TD>
<TD valign="top" class="Comment">

<TT>std::less</TT> is specialized for pointer types so that
it yields a total ordering. It seems that utility classes
and containers in the library fail to establish the same
total ordering, so eg. <TT>tuple&lt;T*&gt;</TT>
or <TT>pair&lt;T*, U*&gt;</TT> or <TT>vector&lt;T*&gt;</TT>
will not have a guaranteed total ordering, since there's
no <TT>std::less</TT> specialization for them and the
default <TT>std::less</TT> will invoke
<TT>operator&lt;</TT> which will use
the <TT>operator&lt;</TT> of the underlying type, hence
failing to establish a total ordering.

&#160;
  </TD>
<TD valign="top" class="Res">

Specialize <TT>std::less</TT>
for <TT>pair</TT>, <TT>tuple</TT>, <TT>optional</TT> and
containers for pointer types.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI16">FI 16</A></TD>
<TD valign="top" class="Ref">
18.6

    &#182;
    
1
&#160;
  </TD>
<TD valign="top" class="Comment">

According to N3396, &#8220;In this example, not only is an
implementation of C++11 not required to allocate
properly-aligned memory for the array, for practical
purposes it is very nearly required to do the allocation
incorrectly; in any event, it is certainly required to
perform the allocation by a process that does not take the
specified alignment value into account.&#8221; This
represents a hole in the support for alignment in the
language, which really needs to be filled.

&#160;
  </TD>
<TD valign="top" class="Res">

Adopt the solution in N3396.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI12">FI 12</A></TD>
<TD valign="top" class="Ref">
14.5.6.2
&#160;
  </TD>
<TD valign="top" class="Comment">

In [c++std-ext-14217], Andrew Sutton writes:<BR>
If I have two functions:
<PRE>
template&lt;typename... Args&gt; void f() { }      // #1
template&lt;typename T, typename U&gt; void f() { } // #2
</PRE>
Should overload resolution be able to distinguish these? What I want is this:
<PRE>
f&lt;int, int&gt;() // Calls #2
f&lt;char&gt;() // Calls #1
f&lt;int, char, float&gt;() // Calls #1
</PRE>
What I get is, &#8220;no matching function&#8221; (using an
older revision of GCC-4.8). I haven't thoroughly searched
the standard for an answer, but I suspect the answer will
also be &#8220;no&#8221;.
If those are template parameters reflect function
parameters, then the overloads can be distinguished.
<PRE>
template&lt;typename... Args&gt; void f(Args...);
template&lt;typename T, typename U&gt; void f(T, U);
</PRE>
It seems like this fact could be extended to non-deduced
arguments as well. Just curious.
The question/proposal would seemingly allow metaprogramming
techniques that, in conjunction with <TT>decltype</TT>, allow
extracting types from packs without having to resort to
traits-like classes with nested typedefs.

&#160;
  </TD>
<TD valign="top" class="Res">

Make non-deduced function templates with pack arguments less
viable than function templates without packs, that is,
partially order currently equal/ambiguous candidates so that
a pack is a worse match than no pack.

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     REJECTED
    <BR><BR>
There was no consensus for a change in this revision of the Standard,
but the idea is not ruled out for a future revision.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="FI11">FI 11</A></TD>
<TD valign="top" class="Ref">
30.3.1.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top" class="Comment">

It is most unfortunate that there is no RAII thread type in
the standard. The lack of it leads to proliferation of
custom solutions.

&#160;
  </TD>
<TD valign="top" class="Res">

We do not support modifying <TT>~thread</TT> to join; it has shipped
in C++11, and people rely on the <TT>terminate()</TT> in it. It would
be better to introduce a <TT>thread_guard</TT> that joins the
underlying thread automatically upon destruction of the
guard.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US7">US 7</A></TD>
<TD valign="top" class="Ref">
3.7, 5.3, 12.5, 17.6, 18.6, Annex C
&#160;
  </TD>
<TD valign="top" class="Comment">

Enable sized deallocation.

&#160;
  </TD>
<TD valign="top" class="Res">

See N3663

&#160;
  </TD>
<TD valign="top" class="Owner">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3778.html">
     N3778</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top" class="ID"><A NAME="US21">US 21</A></TD>
<TD valign="top" class="Ref">
26.5, Annex D, etc.
&#160;
  </TD>
<TD valign="top" class="Comment">

The Bristol meeting postponed consideration of N3647 because
it was assumed that, if adopted, the proposal could be
issued in some future Technical Specification.  However,
N3647 proposes some deprecations, and it is unclear what it
would mean to issue any deprecation in TS form.

&#160;
  </TD>
<TD valign="top" class="Res">

Review and adopt for C++14 at least the deprecations
proposed by N3647 (or by a successor document, if any).
Preferably adopt the entire document, as its proposals are
intertwined.

&#160;
  </TD>
<TD valign="top" class="Owner">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top" class="Disp">&#160;
  </TD>
</TR>
</TBODY>
</TABLE>
</BODY>
</HTML>
